前端性能指标速查手册

很多开发者在调整性能时常会有这种困惑：“明明代码写得很快，为什么使用者还是觉得慢？话说回来，”、“Lighthouse 分数很高，但真机反馈一直卡顿？按理说，”这通常是因为你没有建立科学的衡量标准。这份手册将带你理清前端性能的“度量衡”，帮你精准定位性能瓶颈。

一、 一张时间线先理清所有指标的位置

使用者能交互
─────────────────────────────────────────────────────┐
服务器返回 DOM解析完 最大内容出现
所有资源下完 │ │ │ │ │
│ ←── TTFB ──→ │ │ │
│ │ ←─ DCL ─→ │ │
│ ←──── FP / FCP ────→ │ │
│ ←──────── LCP ─────────────────→ │ │
│ ←───────────────── Load ──────────────────→ │ │
│ ←───────────────── TTI ──────────────────→ │ ▼
▼导航开始

理解所有指标的第一件事：它们都用同一把尺子量所以能直接比较、相减。话说回来，

二、 主要指标。按"谁先谁后"排列

1. . TTFB · Time To First Byte

痛点：打开页面后长时间转圈圈，使用者怀疑是服务器挂了还是网络断了。

定义："服务器返回 HTML 第一个字节要多久"

• 至于回答，网络 + 服务端 有没有问题
• 至于包括。DNS 解析、TCP 握手、TLS 协商、服务端处理、HTML 开始返回
• 再看看它发现什么，后端慢、CDN 配错、DNS 查询慢、HTTPS 握手慢

测量方式：

const nav = performance.getEntriesByType;const ttfb = nav.responseStart;// 从导航开始到收到第一个字节

达标线：<200ms 好 / ~600ms 可接受 /> 600ms 要改

2. . FP · First Paint

定义："浏览器第一次往屏幕刷像素"

• 实用意义不大。因为画一个灰色背景也算 FP
• 通常你会忽略它，直接看 FCP

3. . FCP · First Contentful Paint

痛点：白屏时间过长，使用者完全不知道页面是否正在加载，导致直接跳出。不过，

定义："浏览器第一次画出有意义的内容"

• 使用者视角这方面，"白屏结束了"
• 被 Google 官方定义为 Core Web Vital 的"加载"维度之一
• 再看注意。SPA 里 FCP 可能是 index.html 的 loading 骨架而不是应用真正渲染

new PerformanceObserver => { list.getEntries.forEach => { if { console.log;} })，}).observe;

达标线：<0.8s 好 / ~3s 可接受 /> 3s 差

4. . DCL · DOMContentLoaded

定义："HTML 全部解析完 + 所有 defer / module script 执行完"

• 不等图片、样式、iframe
• 对 SPA 意义比传统页面小

nav.domContentLoadedEventEnd;

5. . LCP · Largest Contentful Paint

痛点：页面内容虽然出来了但主要大图或标题迟迟不显示，导致视觉上巨大的“未完成感”。

定义："页面主要视觉区域画完的时刻"

• 时候
• Google 三大 Core Web Vitals 之一，直接影响 SEO
• 会随内容变大而不断更新。直到使用者首次交互才定格
• 比 FCP 更贴近真实使用者体感

new PerformanceObserver => { const entries = list.getEntries;const lcp = entries;// 最终一次上报的才是最终 LCP console.log;}).observe，

6. . Load

定义："HTML 声明的所有资源都下完"

• 不等动态 import、运行时
• 在 SPA 里意义很小。早于应用可用
• 看它的用途的观点是，检查初始 bundle 是否异常

nav.loadEventEnd;

7. . TTI · Time To Interactive

定义："主线程连续空闲秒。可交互"

• 传统但难测量
• 浏览器不直接暴露 —— 需要推断
• 建议用 web-vitals 库测

8. . INP · Interaction to Next Paint

痛点：点击了按钮没反应，使用者觉得页面“点死了”。

定义："使用者每次交互到下一次画面更新的耗时"

• 测可交互性
• 贯穿整个生命周期。不是首屏指标
• 反映主线程是否卡

测量方式：建议用 web-vitals 库，手写复杂

9. . CLS · Cumulative Layout Shift

痛点：加载过程中内容突然跳动，导致使用者点错按钮，极其痛苦。

定义："页面上所有意外的布局偏移积分"

• 图片没写 width/height、字体替换引发 CLS
• 不是时间指标，是一个分数
• 反映视觉稳定性

达标线：<0.1 好 / ~0.25 可接受 /> 0.25 差

10. . TBT · Total Blocking Time

定义："FCP 到 TTI 之间，主线程被阻塞的总时长"

• 长任务 = 单次执行> 50ms 的任务
• 反映加载阶段的 JS 臃肿程度
• Lighthouse 主要指标。但不是 Core Web Vital

三、 如何测 · 四种通用方案

适用优点缺点一次性调试零代码、直观、火焰图详细详细，没法长期监控 一次性评分综合报告实验室环境，不代表真实使用者 长期埋点灵活、零依赖要写代码，边界 case 要自己处理 线上监控规范、跨浏览器、支持 INP/CLS+3KB

方案
Chrome DevTools Performance 面板	Lighthouse	自己 PerformanceObserver	web-vitals 库

推荐的最小 web-vitals 接入

import { onCLS,onFCP,onLCP,onINP,onTTFB } from 'web-vitals';const send = => { 上报到你的监控后端 navigator.sendBeacon);}，onCLS;onFCP，onLCP;onINP，onTTFB;

三行代码覆盖 Core Web Vitals。Google 官方维护，永远比自写的准。

四、 自定义测量：performance.mark / performance.measure

浏览器自动提供的指标只是"公共节点"。你自己关心的节点要自己打标。

// 标一个时间点performance.mark;// 标一段耗时performance.mark;await fetchData;performance.mark;performance.measure;说起来，// 读出来const m = performance.getEntriesByName;话说回来，console.log;其实，

SPA 里最常见的自定义节点：

• app-script-start：JS 开始执行
• app-mounted：框架首屏挂载完
• route-change-start / route-change-end：路由跳转
• api-call-start / api-call-end：接口调用

五、 指标挑选

看这个TTFBFCPLCP自定义 app-mounted markINPCLS自定义 route-change measureResource API

你想知道
服务端/网络慢
白屏多久
使用者觉得"好了"
首屏可用
点击是否卡
页面跳动
路由跳转
接口慢

六、 一句话记住每个指标的灵魂

• TTFB：网络+后端的成绩单
• FCP：白屏结束的那刻
• LCP：使用者觉得"好了"的那刻
• DCL：HTML 骨架完成的那刻
• Load：HTML 声明的资源下完
• TTI：主线程稳定空闲
• INP：每次交互的响应速度
• CLS：页面跳不跳
• TBT：加载阶段 JS 卡不卡

Core Web Vitals 三件套 = LCP + INP + CLS。这三个是 Google 搜索排名会用的，也是线上监控的最小必要集。其他都是辅助，

七、 一条黄金方法建议

不上：用 Chrome DevTools Performance + Lighthouse 足够，不用写埋点。

上线后：接 web-vitals + 自建或对接 APM。监控 Core Web Vitals + 若干自定义 mark 就够。

不要做的事：

• 手写 TTI / CLS / INP 计算
• 在 dev 模式看性能下结论
• 只看平均值

---