首屏加载性能以用户首次看到内容的时间为准，核心指标是FCP和LCP；需用PerformanceObserver早期监听paint条目获取startTime，结合navigation和resource timing分析瓶颈，辅以白屏时间与DOM可交互时间评估可用性。
首屏加载性能不是看“页面全 loaded”，而是看用户第一次看到内容的时间。Performance API 提供了多个直接或间接反映首屏体验的指标，关键在于选对时机、读准字段、结合上下文判断。
优先监听 FCP 和 LCP 这两个核心渲染指标
FCP（First Contentful Paint）代表浏览器首次渲染任何文本、图像、非空白 canvas 或 SVG 的时间；LCP（Largest Contentful Paint）反映首屏最大块内容（如大图、标题区块）绘制完成的时间——这两个是衡量首屏感知速度最贴近用户的真实指标。
- 用 PerformanceObserver 主动监听，避免错过：在页面早期（如 <head> 中）注册 observer，监听
'paint'类型条目 - 只取
entry.name === 'first-contentful-paint'或'largest-contentful-paint'的条目，entry.startTime即为相对于 navigationStart 的毫秒值 - 不要等
window.onload再读——那时 FCP 早已发生，数据虽存在但已失去诊断价值
用 navigation 条目定位首屏瓶颈阶段
调用 performance.getEntriesByType('navigation')[0] 获取本次导航的完整时序，重点计算以下差值：
-
TTFB（Time to First Byte）：
nav.responseStart - nav.requestStart，超过 800ms 说明服务端或 CDN 响应慢 -
HTML 解析耗时：
nav.domInteractive - nav.domLoading，异常高需检查 HTML 体积或同步脚本阻塞 -
DOM 构建+同步 JS 执行：
nav.domContentLoadedEventEnd - nav.responseEnd，>300ms 可能存在未拆分的大型 inline 脚本 -
首屏资源拖尾：
nav.loadEventEnd - nav.domContentLoadedEventEnd，偏高说明图片、字体或 iframe 加载慢，需结合 resource 条目验证
注意：nav.type === 'back_forward' 时 responseStart 可能为 0，TTFB 计算应跳过。
结合 resource timing 看首屏关键资源
首屏内容依赖哪些资源？用 performance.getEntriesByType('resource') 过滤出首屏图片、CSS、关键 JS 的条目：
- 关注
startTime（发起请求）、responseStart（首字节到达）、responseEnd（响应完成） - 若某张首屏图的
responseEnd - responseStart很大，说明网络或服务端传输慢；若duration大但responseEnd小，则可能是浏览器解析/解码耗时（如未压缩大图） - 对关键资源使用
rel="preload"，并检查其transferSize是否合理（过大说明未压缩或格式不佳）
补充测量：白屏时间与 DOM 可交互节点
FCP 是“看到”，但用户还需“可用”。可辅助测量：
-
白屏时间：
performance.now() - performance.getEntriesByType('navigation')[0].startTime，在<body>开头立即执行，反映从导航开始到 JS 开始运行的延迟 -
首屏 DOM 可交互时间：在首屏关键容器元素挂载后（如 Vue
mounted或 ReactuseEffect），调用performance.now()打点，再减去navigationStart - 若该时间远晚于 FCP，说明首屏内容虽已渲染，但交互逻辑尚未就绪——可能是懒加载组件初始化慢或长任务阻塞主线程
