Core Web Vitals 三项里，先修哪个
Core Web Vitals 现在是三个指标：LCP（最大内容绘制）、CLS（累积布局偏移）、INP（交互到下次绘制）。
三项都影响体验，但修复成本差别巨大。如果时间有限，顺序应该是 LCP → CLS → INP。
LCP：性价比最高
LCP 衡量的是"主要内容多久出现"。它直接影响用户的第一印象，也最容易优化。
常见原因和修法：
图片太大
一张 2MB 的 banner 图，手机网络下要好几秒。转 WebP、按显示尺寸生成多套、加 srcset，通常能减少 70% 以上的体积。
首屏渲染被阻塞
CSS 和同步 JS 挡在前面。把非关键 CSS 内联、关键 JS 加 defer、字体加 font-display: swap。
服务端响应慢
TTFB 超过 800ms 就要查了。常见是数据库查询没索引、或者用了太多中间件。
我们一个站，光把首图从 1.8MB 压到 220KB，LCP 从 4.2 秒降到 1.9 秒。
CLS：用户最烦，但不难修
CLS 是页面加载过程中元素乱跳。用户正要点按钮，按钮跑了。
原因通常是：图片和 iframe 没写宽高、广告位没预留空间、字体加载后行高变化、动态插入的内容把下面的顶下去。
修法很直接：
- 所有图片写死
width/height或aspect-ratio - 广告和动态模块预留固定高度
- 字体用
font-display: optional或者预加载
这一项基本是"改完就好"，没有太多技巧。
INP：最难，优先级最低
INP 衡量交互响应速度。它差通常意味着 JS 太重：事件处理里有大量同步计算、组件渲染太慢、或者第三方脚本太多。
优化 INP 往往要重构代码：拆分长任务、把计算挪到 Web Worker、减少不必要的重渲染。投入大，见效慢。
除非 INP 明显超标（超过 500ms），否则我建议排在最后。
一个现实的判断
三项全绿当然好，但用户感知最强的其实是 LCP。页面两秒内出内容，用户就觉得快；出不来，后面的指标再好也没意义。
而且 LCP 的优化通常顺带改善其他指标——图片压缩、减少阻塞，对 CLS 和 INP 都有帮助。
别为了指标而指标
见过一个站，为了 CLS 达标，把页面做成完全静态的骨架，内容用 JS 一次性插入。CLS 是 0 了，但 LCP 变差、INP 变差，用户实际体验更糟。
指标是代理，不是目标。先让用户觉得快，指标自然会好看。