performance api 可量化懒加载延迟，需关注资源获取、脚本执行、dom 插入和首次绘制各阶段耗时，结合 resource timing、user timing 和 long tasks 等 api 全链路监控。
Performance API 能直接量化组件懒加载带来的实际延迟，关键不是“是否用了 lazy”，而是“它多快/多慢地完成了加载与渲染”。重点看资源获取、脚本执行、DOM 插入和首次绘制这几个阶段的时间开销。
监控懒加载资源的完整生命周期
组件懒加载通常涉及动态 import() 加载 JS 模块、按需请求 HTML 模板或图片等资源。用 Resource Timing API 可捕获这些资源的真实耗时：
- 调用
performance.getEntriesByType('resource')获取所有资源条目，过滤出你懒加载模块的 URL（如chunk-abc123.js） - 关注字段：
startTime（开始请求）、responseStart（首字节到达）、responseEnd（响应完成）、duration（总耗时） - 若
responseEnd - responseStart显著偏高，说明网络或服务端响应慢；若duration很大但responseEnd很小，则执行或解析阶段占主导
标记并测量组件初始化关键节点
仅看资源加载不够——JS 下载后还需解析、执行、创建 Shadow DOM 或挂载实例。用 User Timing API 主动打点：
- 在
import('./MyComponent.js')前调用performance.mark('lazy-load-start') - 在组件类构造完成、或
connectedCallback执行完毕后调用performance.mark('lazy-load-ready') - 再用
performance.measure('init-cost', 'lazy-load-start', 'lazy-load-ready')得到从触发到可交互的总耗时 - 配合
performance.getEntriesByName('init-cost')在运行时或上报时提取该值
区分主线程阻塞与异步等待
懒加载本身是异步的，但后续操作可能意外阻塞渲染。借助 Long Tasks API 或 PerformanceObserver 检测长任务：
- 监听
longtask类型条目，查看组件加载后是否触发了 >50ms 的同步 JS 执行（比如大量数据处理、复杂 DOM 构建） - 对比懒加载组件与预加载组件的
first-contentful-paint和largest-contentful-paint时间差，判断它是否拖慢了核心内容呈现 - 如果组件插入后出现 layout thrashing（频繁重排），可结合
performance.getEntriesByType('layout-shift')看是否有意外的 CLS
结合真实用户场景做分层评估
同一组件在不同设备、网络、缓存状态下的延迟成本差异极大：
- 用
navigator.connection.effectiveType区分 4G/3G/Slow 2G，在弱网下重点观察fetchStart → responseEnd阶段 - 检查
performance.getEntriesByType('navigation')[0].type是reload还是back_forward，判断缓存有效性对懒加载的影响 - 对首次访问用户（无 Service Worker 缓存）单独统计，这类用户最易暴露真实加载成本
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
