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。这两点漏掉任何一个，细粒度分析就失去意义。
