HTML页面加载性能监控：通过Resource Timing的细粒度拆解

performance.getEntriesByType('resource') 返回空或全0，是因为资源未完成加载、强缓存跳过网络阶段、跨域缺失Timing-Allow-Origin头三重限制；必须用PerformanceObserver配合buffered: true监听动态资源，并在沙箱中声明allow-performance权限。

performance.getEntriesByType('resource') 为什么返回空或全是 0？

直接在 DOMContentLoaded 甚至脚本顶部调用，大概率拿到空数组或一堆 0 字段——这不是 API 坏了，而是时机、缓存和跨域权限三重限制没过。

• 资源必须已完成加载（responseEnd 已触发），load 事件前调用会漏掉大量条目
• 强缓存（from cache）下，浏览器跳过网络阶段，domainLookupStart、connectStart 等全为 0，只保留 startTime 和 duration
• 跨域资源（如 CDN 或第三方脚本）若服务端没返回 Timing-Allow-Origin: *，所有网络阶段字段强制清零，连 redirectStart 都不可信

如何用 PerformanceObserver 捕获动态插入的资源

靠轮询 getEntriesByType 抓不到 JS 动态创建的 <img> 或 fetch() 加载的字体——它们完成时间不确定，且可能发生在 load 之后。

• 必须用 PerformanceObserver 监听 resource 类型，并设 buffered: true，否则历史条目丢失
• initiatorType 不可靠：动态 eval() 或 new Function() 加载的脚本，initiatorType 是 undefined，只能靠 entry.name 匹配域名或路径
• 沙箱环境（如 iframe）需显式加 sandbox="allow-scripts allow-performance"，否则 observer 根本收不到任何 resource 条目

拆解 DNS/TCP/TTFB 时哪些字段组合才可信

别直接算 duration，它只是 responseEnd - startTime，漏掉重定向、DNS、TCP 全部前置环节。真正定位瓶颈得看差值，但前提是字段本身有效。

• domainLookupEnd - domainLookupStart：仅当两者都 > 0 才代表真实 DNS 耗时；若等于 0，说明复用本地缓存或 hosts，不是数据缺失
• connectEnd - connectStart：含 TCP 握手 + TLS 协商；若 secureConnectionStart > 0，可用 connectEnd - secureConnectionStart 单独看 TLS 时间
• responseStart - requestStart 是 TTFB，但若 requestStart === 0，该差值无效，此时退回到 responseStart - startTime 近似估算
• responseEnd - responseStart 是纯下载耗时，结合 transferSize 可判断是否受带宽限制（比如 500KB 资源下载耗时 2s，平均速率仅 250KB/s）

怎么识别“看似成功实则失败”的资源

HTTP 200 不等于资源可用——CDN 返回错误 HTML 页面、JS 文件被截断、CSS 解析失败，这些都不会触发 error 事件，但会拖慢渲染。

立即学习“前端免费学习笔记（深入）”；

• 用 document.addEventListener('error', handler, true) 捕获资源加载失败（注意第三个参数 true 是捕获阶段）
• 靠差集反推：收集页面所有 <script src>、<img src>、<link href> 的 URL，再与 performance.getEntriesByType('resource').map(r => r.name) 做差集，剩余的就是“该加载却没出现”的可疑项
• 但动态插入的资源（如 JS 创建后 append 的 script）不会出现在 HTML 源码里，必须运行时维护一个白名单 URL 集合，再比对 performance entries

跨域资源字段是否可信，永远取决于服务端有没有配 Timing-Allow-Origin；而动态资源是否被捕获，取决于你用的是轮询还是 PerformanceObserver + buffered: true。这两点漏掉任何一个，细粒度分析就失去意义。