必须等load事件后调用performance.getentriesbytype('resource')，跨域资源需服务端返回timing-allow-origin: *且前端加crossorigin属性，缓冲区默认150条需提前扩容，再通过字段相减分析dns、tcp、ttfb、下载等各阶段耗时。
直接用 performance.getEntriesByType('resource') 获取资源加载详情，但必须满足三个前提：资源已加载完成、没走强缓存、跨域资源服务端返回了 Timing-Allow-Origin: * 响应头。
确保能拿到有效数据
很多情况下返回空数组或字段为 0，不是 API 失效，而是时机或配置问题：
- 必须等
window.addEventListener('load', ...)触发后再调用，否则动态插入的资源（比如懒加载图片）还没进入性能缓冲区 - 跨域资源（CDN 图片、外部 JS）需服务端响应头包含
Timing-Allow-Origin: *，否则duration、responseStart全是 0 - 前端请求要显式加
crossorigin属性：<script src="a.js" crossorigin></script>，否则浏览器不收集完整时序 - 默认缓冲区只有 150 条，大页面容易丢数据，提前调用
performance.setResourceTimingBufferSize(500)
拆解单个资源的加载阶段
对目标资源（如关键 JS 或 CSS），取其 PerformanceResourceTiming 实例，通过字段相减得出各环节耗时：
-
DNS 查询：
domainLookupEnd - domainLookupStart，超过 100ms 需检查域名解析慢或跨域过多 -
TCP 连接 + SSL 握手：
connectEnd - connectStart，若 > 300ms，可能是服务端响应慢、未启用 HTTP/2 或证书链过长 -
TTFB（首字节时间）：
responseStart - requestStart，反映后端处理能力，持续高于 500ms 要查服务逻辑或 CDN 配置 -
内容下载：
responseEnd - responseStart，偏高说明网络带宽不足或资源未压缩 -
总耗时：
duration，等于responseEnd - startTime，包含所有阶段，是用户感知最直接的指标
定位慢资源并交叉验证
不要只看单个数字，要结合体积和类型做判断：
- 筛选出
transferSize > 200KB或decodedBodySize > 500KB的资源，它们大概率拖慢首屏 - 对比同类型资源（比如多个 JS）的
duration，找出异常偏高的那个，再查是否未开启 Gzip/Brotli、缓存策略失效或 CDN 节点异常 - 如果某资源
responseEnd - responseStart很小但duration很大，说明瓶颈在解析或执行阶段（如大型 inline 脚本），需配合performance.getEntriesByType('longtask')查主线程阻塞 - 对懒加载模块（如
chunk-abc123.js），用performance.mark()打点起始与就绪时刻，再用measure()计算真实初始化耗时
适配不同导航场景
用户行为会影响资源时序数据的可用性：
- 如果是从缓存回退（
navigation.type === 'back_forward'），部分字段（如responseStart）可能为 0，此时跳过 TTFB 计算 - Service Worker 拦截响应时，
responseStart可能早于fetchStart，需用workerStart等字段辅助判断 - SPA 路由切换后，
getEntriesByType('resource')不会自动更新旧资源，需配合PerformanceObserver监听新资源条目
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
