文章目录
Web Vitals的主要指标和作用
- LCP（Largest Contentful Paint，最大内容绘制）：衡量首屏主要内容完成渲染的速度，用于评估页面“看起来是否已经加载完成”。
- INP（Interaction to Next Paint，交互到下一次绘制）：衡量用户交互后到界面产生可见反馈的延迟，用于评估页面整体交互流畅度与响应性。
- CLS（Cumulative Layout Shift，累积布局偏移）：衡量页面在加载和使用过程中发生的非预期位移程度，用于评估视觉稳定性和误触风险。
LCP：最大内容绘制
含义：视口内最大可见内容元素完成渲染的时间。常见 LCP 元素是首屏大图、标题块、大段文本或视频海报。
经验阈值（字段 p75）：良好 ≤ 2.5s；需改进 2.5s～4s；差 > 4s（以官方文档为准，会随标准微调）。
如何基于 LCP 做分析
- 在 Chrome DevTools → Performance → Insights 或 Lighthouse 里看 LCP 元素是谁、时间分解（TTFB、资源加载、渲染延迟）。
- 字段数据里看 LCP 元素类型（图片 vs 文本）：图片多就要盯 CDN、格式、优先级；文本多就要盯字体与阻塞 CSS。
典型问题与例子
| 现象 | 例子 |
|---|---|
LCP 是一张 <img>，但很晚才出现 | 轮播首帧用了 loading="lazy"，首屏图被当成懒加载，LCP 拖到滚动或很晚才解码。 |
| LCP 时间很长，瀑布里 CSS/JS 很长 | 全站打包一个巨大 app.js，解析执行完才渲染，LCP 元素排在长任务后面。 |
| 同一页面移动端差、桌面好 | 移动端大图未用合适尺寸，下载 2x 桌面图；或 CPU 节流下解码慢。 |
| TTFB 占比高 | 服务端 SSR 慢、边缘未缓存、数据库查询重，LCP 再优化图片也救不了首字节。 |
调试步骤
- Lighthouse 报告里确认 LCP 元素 与 子部分（TTFB、Load Delay、Load Time、Render Delay）。
- Network 里看该资源是否 优先级过低、是否被大量同域请求阻塞。
- 若 Render Delay 大：Performance 里找 LCP 前的长任务，看是否可拆分、defer、或移出关键路径。
解决方案
- 资源：首屏 LCP 图不用
lazy；用fetchpriority="high"（适用时）；现代格式（AVIF/WebP）、正确width/height、响应式srcset。 - 关键路径：内联关键 CSS 或减小阻塞 CSS；JS 默认
defer/async，减少同步脚本。 - 服务端：优化 TTFB（缓存、SSR 流式、边缘渲染）、HTTP/2 或 3、避免过大的 HTML。
- 字体：
font-display: swap或optional、子集化、预加载真正影响 LCP 的字体（避免过度预加载每一种字重）。
INP：交互到下一次绘制
含义：用户交互（点击、点按、键盘）到浏览器完成下一次绘制的延迟的整体体验指标（取多次交互中的高百分位，如 p98）。FID 已逐步被 INP 取代，因为 FID 只看第一次输入，无法代表整页交互流畅度。
经验阈值（字段）：良好 ≤ 200ms；需改进 200～500ms；差 > 500ms。
如何基于 INP 做分析
- 字段数据里按 页面 / 路由 / 组件 看 INP，找出最差交互（如「加入购物车」「打开抽屉」）。
- Performance 录制：勾选 Web Vitals / 慢交互（依版本），点击问题交互，看主线程在输入到 paint 之间做了什么。
典型问题与例子
| 现象 | 例子 |
|---|---|
| 点击后 UI 很久才更新 | 点击 handler 里 await 了整个报表接口，在 await 返回前没有任何乐观更新，主线程还被别的长任务占满。 |
| 列表里每一项点击都卡 | 每次点击对 5000 行 DOM 全量 querySelector + 重排，或同步排序整个数组并触发大规模重渲染。 |
| 路由切换卡顿 | 切换路由时同步加载巨大 chunk，解析+执行阻塞 paint。 |
| 第三方脚本 | 聊天挂件在每次 scroll 里做重计算，与用户点击抢主线程。 |
调试步骤
- Performance 里找到 Input → Processing → Presentation 链路过长的一段。
- 看是否有 Long Task（>50ms） 紧贴交互；是否大量 Layout / Recalculate Style。
- 对 React/Vue 等：用 Profiler 看是否一次 setState 导致整树提交。
解决方案
- 让反馈尽快出现：乐观 UI、骨架屏、
startTransition（React 18+）把非紧急更新标为低优先级。 - 拆主线程工作：
scheduler、分片、requestIdleCallback（谨慎）、Web Worker 做纯计算。 - 减少布局抖动：读布局属性不要和写样式交替「强制同步布局」；批量 DOM 更新。
- 代码分割：路由级、组件级动态
import()，避免首包把解析时间摊到第一次点击上。 - 第三方：延迟加载、iframe 隔离、减少同步 API 调用。
CLS：累积布局偏移
含义：生命周期内未预期的布局位移分数累加（用户点击产生的预期变化一般不计入，具体以实现与 API 为准）。
经验阈值（字段）：良好 ≤ 0.1；需改进 0.1～0.25；差 > 0.25。
如何基于 CLS 做分析
- DevTools Rendering → Layout Shift Regions 高亮移动区域；Performance 里看 Experience 中的 layout shift 记录。
- 字段里若 CLS 集中在文章页：多为广告/嵌入图；若在商品页：多为图片、字体、异步价格。
典型问题与例子
| 现象 | 例子 |
|---|---|
| 图片无尺寸 | 文章流中 <img> 无 width/height 或宽高比占位，加载完成后把正文整体下推。 |
| Web 字体 swap | font-display: swap 导致字重从回退字体切到 Web 字体时，行宽变化、段落重排。 |
| 动态插入横幅 | Cookie 同意后底部插入 GDPR 条，把固定 footer 顶上去一截。 |
| 无限列表 | 新骨架插入时未预留高度，列表跳动。 |
| 客户端渲染价格 | SSR HTML 里占位高度与 CSR 渲染后真实高度不一致。 |
调试步骤
- 慢网速 + 清空缓存复现，观察 Network 与 Layout Shift Regions。
- 对每个会改变高度的异步块：确认是否有 min-height 或骨架与最终内容同占位。
解决方案方向
- 图片、iframe、广告位：显式宽高或
aspect-ratio+ 背景占位。 - 字体：预留空间（
size-adjust、可变字体）、或减少 swap 带来的行高跳变。 - 动态内容：用 CSS
content-visibility（注意兼容性）、占位 div、避免在现有文本上方插入内容（优先在下方或预留槽位）。 - 动画：优先
transform/opacity，避免触发布局的top/width动画影响文档流。
辅助指标：FCP、TTFB、TBT
FCP（First Contentful Paint）
用途：第一次有像素绘制；差时常与阻塞资源、大字体、白屏时间长有关。
例子：一个全屏同步脚本在 head 里执行 2 秒，FCP 与 LCP 一起推迟。
方向：同 LCP 的关键路径优化，减少阻塞。
TTFB（Time to First Byte）
用途：第一个 HTML 字节到达时间；高则 LCP 上限往往不好。
例子：SSR 每次现查数据库、无 CDN；或重定向链过长。
方向：缓存、边缘、数据库与 API 优化、减少重定向。
TBT（Total Blocking Time）
用途：实验室里主线程被长任务阻塞的总时间，与 INP 相关但不等同。
例子：Lighthouse 显示 TBT 高、但字段 INP 好——可能是实验室 CPU 节流放大了长任务，仍建议降低长任务以覆盖弱性能机型。
方向：拆包、少同步工作、优化第三方。