最快速识别第三方CDN资源缺失Timing-Allow-Origin的方式是检查performance.getEntriesByType("resource")中domainLookupStart、connectStart、secureConnectionStart等网络阶段字段是否全为0或NaN，而startTime、responseEnd、duration正常；若满足跨域且已加载前提，并排除缓存与采集时机干扰，则可确认因缺失Timing-Allow-Origin导致浏览器清零时序数据。
跨域资源加载问题常表现为耗时异常、字段缺失或阶段时间为 0，根源往往不在前端代码本身，而在服务端配置或网络策略。Resource Timing 是唯一能直接暴露这些细节的原生手段，关键在于正确采集、识别和解读数据。
确认是否获取到完整跨域时序数据
跨域资源默认只返回极简字段（name、startTime、duration），其余如 domainLookupStart、connectStart、responseStart 等若全为 0，基本可判定未启用 Timing-Allow-Origin。
- 检查目标资源响应头：用 DevTools 的 Network 面板查看该请求的 Response Headers，确认是否存在 Timing-Allow-Origin: * 或精确域名（如 Timing-Allow-Origin: https://your-site.com）
- 若使用 CDN，需在 CDN 控制台或源站 Nginx/Apache 配置中显式添加该 Header，仅前端设置无效
- 注意：即使加了 Header，若资源重定向多次，中间跳转页也需逐个配置，否则链路中断处的数据仍不可见
识别典型跨域异常模式
字段缺失不是“没数据”，而是浏览器主动屏蔽——它本身就是诊断线索：
- DNS 和 TCP 时间为 0：不一定是缓存，更可能是跨域限制导致无法读取；若同域名资源有值而跨域无值，即可锁定问题来源
- responseStart 为 0 但 responseEnd 有值：说明浏览器收到了响应体，却无法获知首字节时间，TTFB 无法计算，常见于未配 Timing-Allow-Origin 的 HTTPS 资源
- duration 正常但各阶段差值全为 0：典型“黑盒”状态，资源能加载成功，但所有网络环节不可见，优化失去依据
实操建议：用 PerformanceObserver 实时捕获 + 过滤
相比 onload 后一次性调用 performance.getEntriesByType('resource')，Observer 可捕获动态插入、异步加载的跨域资源，尤其适合 SPA 或广告脚本场景：
立即学习“前端免费学习笔记（深入）”；
- 监听 entryType === 'resource'，对每个 entry 检查 entry.name 是否含第三方域名（如 cdn.jsdelivr.net、fonts.googleapis.com）
- 若 entry.domainLookupStart === 0，立即标记为“跨域时序受限”，并上报 URL 和 initiatorType（script / link / img）
- 结合 entry.transferSize 和 entry.encodedBodySize 判断是否被压缩或走缓存，辅助区分是配置问题还是真实网络慢
协同排查：不只是前端的事
Resource Timing 揭示的是“现象”，定位的是“谁该改”：
- 若多个跨域资源都缺失字段，优先推动 CDN 或第三方服务商补全 Timing-Allow-Origin
- 若仅个别资源异常，检查其是否经过代理/网关，这些中间层可能剥离或覆盖原始响应头
- 沙箱环境（如 iframe sandbox）需额外声明 allow-performance 权限，否则 Performance API 被禁用
