Web 性能优化清单（2026 版）：从感知速度到稳定指标

先统一目标：优化“用户体感”

性能不是只看 Lighthouse 分数，而是看用户是否觉得“快、稳、可预期”。

当前可以重点关注三项：

• LCP：最大内容元素渲染速度（页面“看起来完成”的关键）
• INP：交互响应延迟（点击后是否立即有反馈）
• CLS：布局稳定性（内容是否乱跳）

LCP：让主内容更早出现

优先级 1：主图与关键文本

1. 首屏主图使用合适尺寸，避免传原图；
2. 优先加载首屏需要的字体子集；
3. 减少阻塞渲染的同步脚本。

在 Next.js 里，图片与字体通常是收益最高的入口。

优先级 2：服务端输出更完整

对于内容型页面（博客、文档），尽量让首屏结构在服务端就可渲染，减少客户端等待。

INP：交互必须“有即时反馈”

避免主线程长任务

渲染卡顿常常不是网络慢，而是主线程被长任务占满。常见来源：

• 一次性处理过大数据；
• 页面初始挂载时执行过多副作用；
• 不必要的深层重渲染。

拆分与延后

可把非关键逻辑延后到空闲时执行，把复杂计算放到 Web Worker，或者在交互后按需加载。

CLS：页面不抖动

布局偏移会直接破坏阅读体验。实践里要注意：

1. 图片、视频、广告位预留固定尺寸；
2. 异步数据占位骨架与最终布局保持一致；
3. 动画尽量使用 transform、opacity，避免触发布局回流。

一个团队可落地的检查流程

每次上线前，至少做下面 5 件事：

1. 检查首屏关键资源体积（JS/CSS/图片）；
2. 记录关键页面 LCP/INP/CLS；
3. 核查新增第三方脚本是否阻塞渲染；
4. 低端设备上做一次交互压测；
5. 对比上个版本，确认没有明显回退。

常见误区

误区 1：把所有组件都做成客户端组件

这会增加 JS 体积和 hydration 成本。内容展示类组件优先保持服务端渲染。

误区 2：一次性“重构式优化”

性能改造更适合“持续小步快跑”，每次只改一个瓶颈并量化结果。

小结

性能优化的本质是工程习惯：建立指标基线、持续监控、避免回退。只要把这套流程固化到日常发布里，站点会越来越快，而不是“偶尔快一次”。