前端常见性能指标有哪些？
简化版
常见前端性能指标包括 FCP、LCP、TTFB、CLS、INP、DOMContentLoaded、Load。FCP 关注首次内容渲染，LCP 关注最大内容渲染，CLS 关注布局偏移，INP 关注交互响应。优化要先测量，再定位瓶颈。
详细版
常见指标：
- TTFB：收到首字节的时间，反映服务端和网络耗时。
- FCP：首次内容绘制，用户第一次看到内容。
- LCP：最大内容绘制，反映主要内容加载速度。
- CLS：累计布局偏移，反映视觉稳定性。
- INP：交互到下一次绘制的延迟，反映交互响应。
- DOMContentLoaded：HTML 解析完成，并等待 defer/module 等规定要先完成的脚本。
- Load：文档及其依赖的图片、样式、脚本等 load 阻塞资源完成，不代表所有异步请求结束。
不同指标对应不同优化方向。比如 LCP 差可能是首屏图片过大、接口慢、JS 阻塞；CLS 差可能是图片未预留尺寸、广告插入导致布局跳动。
完整版教学
一、为什么要看性能指标
性能优化不能只凭感觉。用户说“页面慢”，可能是白屏慢、主内容慢、点击没反应、滚动卡、布局乱跳。
指标的价值是把模糊体验拆成可定位的问题。不同指标对应不同阶段，优化方法也不同。
二、核心指标解释
TTFB 关注从请求开始到收到服务器第一个字节的时间。它受 DNS、连接、服务器处理、CDN 命中影响。
FCP 表示页面第一次绘制文本、图片或非空白内容。它反映用户从白屏到看到东西的速度。
LCP 表示视口内最大内容元素完成渲染的时间，常用于衡量首屏主内容速度。
CLS 衡量页面生命周期中意外布局偏移。图片没有宽高、广告异步插入、字体切换都可能导致 CLS 变差。
INP 衡量用户交互后的响应延迟，更关注真实交互体验。
三、如何定位问题
如果 TTFB 高，优先看服务端响应、缓存、CDN、网络链路。
如果 FCP 或 LCP 高，优先看关键资源大小、阻塞脚本、首屏图片、字体、CSS。
如果 CLS 高，检查图片尺寸、动态插入内容、骨架屏高度、广告位预留。
如果 INP 高，检查长任务、复杂渲染、大量 JS 执行、事件处理过重。
四、面试追问与工程落地
面试官可能问：“怎么做性能优化闭环？”
完整闭环是：采集指标 → 发现问题 → 定位原因 → 制定方案 → 验证收益 → 持续监控。不能只说压缩图片、开启缓存，而要说明它改善的是哪个指标。
工程中可以结合 Lighthouse、Performance 面板、真实用户监控和日志平台，区分实验室数据和真实用户数据。
五、Core Web Vitals 阈值与统计口径
当前核心 Web Vitals 是 LCP、INP、CLS。Google 的“良好”阈值为 LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1，并以真实用户页面访问的第 75 百分位评估；阈值不是“平均值合格”就算合格。
| 指标 | 良好 | 较差 | 衡量维度 |
|---|---|---|---|
| LCP | ≤ 2.5s | > 4.0s | 主要内容加载呈现 |
| INP | ≤ 200ms | > 500ms | 交互响应到下一次绘制 |
| CLS | ≤ 0.1 | > 0.25 | 意外布局偏移 |
假设 100 次访问中，前 75 次 LCP 都不超过 2.4s，但剩余访问很慢，P75 仍为约 2.4s并进入良好区间；若第 75 个值为 3.2s，即使平均值被大量快访问拉低，也不达良好阈值。还应按移动/桌面、地区、网络和页面类型分段，避免总体数字掩盖弱设备用户。
六、指标分解、实验室与真实用户
LCP 可拆成 TTFB、资源加载延迟、资源下载时长和元素渲染延迟。LCP 图片 500ms 就下载完，但主线程又执行 800ms JS，问题在渲染延迟而非图片压缩；INP 则可从输入延迟、事件处理时长和 presentation delay 分解。
LCP ≈ TTFB + 资源发现延迟 + 资源下载 + 元素渲染延迟
交互 → 输入等待 → 事件处理 → 渲染等待 → next paint（INP）Lighthouse 等实验室工具可复现并提供诊断，但一次冷启动模拟不能代表真实用户分布；CrUX/RUM 是现场数据，却需要足够样本并受版本、设备和网络混合影响。闭环应当用现场数据发现问题，用 Performance/Lighthouse 定位，再以现场 P75 验证长期收益。
CLS 不是简单把所有位移相加，而是按布局偏移会话窗口累计分数；用户输入后合理发生的部分位移也有排除规则。工程上仍应给图片/广告预留尺寸、避免在已有内容上方插入内容，并用真实 shift entries 找责任节点。
指标心法：先确认“哪个用户、哪个页面、哪个分位数”的哪个指标差，再分解指标；没有统计口径的优化数字不可比较。
采集时保留诊断上下文
只上报一个 LCP 数字很难定位。RUM 还应携带页面模板、设备类型、网络、应用版本、LCP 元素与导航类型，并做采样和隐私控制；发布前后按相同维度对比，才能区分代码回归与用户结构变化。
new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
report(entry.entryType, entry.startTime)
}
}).observe({ type: 'largest-contentful-paint', buffered: true })生产采集要处理页面隐藏/离开时的最终上报和浏览器支持差异，成熟项目可优先使用维护良好的 Web Vitals 库统一口径。
七、常见误区与追问
- 误区：Core Web Vitals 包括 FCP、TTFB 和 Load。 它们是重要辅助指标，但当前核心三项是 LCP、INP、CLS。
- 误区：平均 LCP 低于 2.5 秒就达到良好标准。 标准看页面访问的 P75，并应区分移动与桌面等维度。
- 误区：LCP 慢一定是最大图片文件太大。 服务端、资源发现、下载和主线程渲染延迟都可能占主导。
- 追问：INP 与旧指标 FID 有何区别？ FID 只看首次交互的输入延迟，INP 观察页面生命周期内多次交互并关注直到下一次绘制的整体响应。
- 追问：实验室数据和现场数据哪个更重要？ 现场数据代表真实体验，实验室数据适合稳定复现与诊断，两者互补。
- 追问：为什么要看 P75 而不是 P99？ P75 是 Core Web Vitals 的统一评估口径，P95/P99 仍可用于内部发现尾部问题。
- 追问：优化后如何避免指标回退？ 建性能预算、版本对比和 RUM 告警，按页面模板持续观察而非只跑一次 Lighthouse。
八、加强记忆
性能指标按“加载、响应、稳定”记当前三项：LCP ≤2.5s、INP ≤200ms、CLS ≤0.1，并看真实访问 P75。FCP、TTFB、长任务等是定位线索，不是核心三项替代品；用 RUM 找问题、实验室工具拆原因、灰度对照验证，再把预算和监控纳入发布流程。