最可靠的方式是用performance.getentriesbytype获取导航和资源数据并计算关键时间差：导航阶段取'navigation'首个条目，计算ttfb、html解析、dom就绪、页面加载耗时；资源阶段过滤有效resource条目，按initiatortype分类分析瓶颈；运行时用requestidlecallback和requestanimationframe监测主线程压力与fps。
直接用 performance.getEntriesByType 获取导航和资源数据，再结合关键时间差计算各阶段耗时，是最可靠、最贴近真实用户体验的评估方式。
获取导航时序并计算首屏关键阶段
调用 performance.getEntriesByType('navigation') 取第一个条目（[0]），它包含微秒级精度的完整加载时间线。重点看这几个差值：
-
TTFB（首字节时间）：用
nav.responseStart - nav.requestStart，超过 800ms 需排查后端或 CDN -
HTML 解析耗时：用
nav.domInteractive - nav.domLoading，异常高说明 HTML 过大或含阻塞脚本 -
DOM 就绪耗时：用
nav.domContentLoadedEventEnd - nav.responseEnd，> 300ms 建议检查内联脚本是否过大 -
页面完全加载耗时：用
nav.loadEventEnd - nav.startTime，反映用户可交互时间
注意：nav.type === 'back_forward' 时 responseStart 可能为 0，TTFB 应跳过计算。
分析资源加载瓶颈
用 performance.getEntriesByType('resource') 获取所有已加载资源，但需过滤无效数据：
- 只保留
entry.duration > 0的条目，排除强缓存或跨域未配crossorigin的资源 - 按
entry.initiatorType分类（如'script'、'img'、'css'），定位拖慢首屏的资源类型 - 关注
entry.duration和entry.transferSize，识别体积大、加载慢的图片或第三方脚本
动态插入的资源（如懒加载图片）可能不在初始列表中，需在对应操作后再次采集。
验证运行时稳定性
仅看加载指标不够，还需观察页面运行中的实际表现：
- 用
requestIdleCallback测主线程空闲延迟，多次执行若普遍 >50ms，说明 JS 执行压力大 - 用
requestAnimationFrame连续采样帧时间，静止时 FPS 持续 - 用
performance.memory（如支持）查看内存占用，配合频繁 GC 可能提示内存泄漏
这些指标不依赖页面刷新，适合在用户交互后即时诊断卡顿原因。
确保测量时机准确
很多结果为空或不准，本质是调用太早：
- 必须等
document.readyState === 'complete'或监听window.load后再执行 - 不要在空白页（如
about:blank）测试，它无导航上下文 - 避免在 SPA 路由切换前就调用，否则拿不到当前视图的 navigation 条目
- 首次调用返回空时，先查
performance.getEntries()是否有内容，再确认类型名拼写（严格小写'navigation'）
不复杂但容易忽略。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
