最有效方式是用performance.getEntriesByType('resource')筛选关键路径资源，按initiatorType、URL关键字识别核心JS/CSS/主图，结合duration>0和entryType==='resource'过滤，再拆解DNS、TCP、TTFB、传输各阶段耗时，设定阈值告警并用sendBeacon上报。
直接用 performance.getEntriesByType('resource') 获取所有资源条目，再按关键路径筛选、分析耗时与大小，是最有效的方式。重点不是“有没有加载”，而是“关键资源是否及时就位”。
定位关键资源并过滤条目
首屏渲染依赖的资源（如核心 JS、首屏 CSS、主图）必须优先关注。不能只看全部资源列表，要主动识别：
- 通过
initiatorType字段区分类型：'script'、'link'（CSS）、'img'、'fetch'等 - 用
name匹配 URL 关键字，例如/main.chunk.js、/hero-banner.webp - 结合
entryType === 'resource'和duration > 0排除无效或未完成条目
分析各阶段耗时瓶颈
单个资源的 duration 是总耗时，但需拆解才能定位问题：
-
DNS 查询：用
domainLookupEnd - domainLookupStart，>50ms 说明 DNS 配置或缓存不佳 -
TCP 连接：用
connectEnd - connectStart，过高可能受网络或服务端连接池限制 -
TTFB（首字节时间）：用
responseStart - requestStart，反映后端响应能力 -
传输耗时：用
responseEnd - responseStart，结合transferSize判断带宽或压缩效率
识别异常与上报策略
仅记录数据不够，需建立可执行的判断逻辑：
- 对关键资源设置阈值（如 TTFB > 800ms、duration > 3s），触发告警或日志上报
- 用
sendBeacon()异步发送性能数据，避免影响页面卸载 - 对重复访问用户做采样（如 5%），或仅在异常时上报完整条目，降低采集开销
- 若发现某类资源（如字体文件）普遍慢，可结合
decodedBodySize和transferSize判断是否缺少压缩或 CDN 缓存失效
兼容性与执行时机
确保数据不丢失、不误读：
- 脚本必须放在
<head>最顶部执行，否则会错过早期资源请求 - 检查
performance.getEntriesByType是否可用，不可用时降级到performance.timing（仅限基础指标） - Safari 对
transferSize和部分字段支持较晚，需做字段存在性判断，避免undefined计算 - 动态插入的资源（如懒加载图片）需在插入后稍等几毫秒再调用
getEntriesByType，确保条目已注册
