前端性能优化的优先级排序：先做哪些最有效

性能优化最大的问题不是「不知道怎么做」，而是「不知道先做什么」。打开一个慢页面，Lighthouse 列出几十条建议，全做要两个月，只做三条要一周——选哪三条？这篇文章给出一个按投入产出比排序的判断框架。

先量化，别猜

优化前必须有一份真实数据。用 Chrome DevTools 的 Performance 面板录一段真实用户操作，或者接入 RUM（真实用户监控）看线上数据。重点看四个指标：

- LCP（最大内容绘制）：首屏主要内容出现的时间，目标 2.5 秒内

- INP（交互到下次绘制）：点击后多久有响应，目标 200ms 内

- CLS（累积布局偏移）：页面元素跳动的程度，目标 0.1 内

- TTFB（首字节时间）：服务器响应速度，目标 800ms 内

哪个指标最差就优化哪个。不要凭感觉——很多时候你以为慢在 JS，实际慢在网络或后端。

第一优先级：消除明显的浪费（ROI 最高）

这类优化往往几个小时就能做完，收益却是数量级的：

1. 压缩和缓存静态资源。开启 gzip/brotli、设置合理的 Cache-Control、给文件名加内容哈希。一个没开压缩的 1MB JS 变成 200KB，比任何代码优化都快。

2. 图片治理。这是最常见的体积黑洞。检查：是否用了 WebP/AVIF、是否按显示尺寸输出（一张 3000px 的图显示在 300px 的容器里）、是否加了 loading="lazy"、首屏图是否设了 fetchpriority。单这一项经常能砍掉 50% 的传输体积。

3. 删掉不用的代码。打开 bundle 分析（webpack-bundle-analyzer / vite 的 visualize），经常能看到：没用的 polyfill、整个 lodash 但只用了 debounce、引入了却没用的组件库、体积 800KB 的 moment 语言包。删掉这些是纯收益。

4. 移除阻塞渲染的资源。首屏不需要的 CSS/JS 加 defer/async，第三方统计脚本改成延迟加载。

第二优先级：缩短关键路径

做完第一类，通常还有明显提升空间，这时看关键渲染路径：

1. 首屏资源预加载。给关键字体、首屏图片、核心 CSS 加 <link rel="preload">，让浏览器提前开始下载。注意别滥用，preload 太多反而互相抢占带宽。

2. 代码分割。路由级别的懒加载是标配，但也要注意粒度——拆得太碎会导致大量小请求，拆得太粗等于没拆。一般按「路由 + 大型第三方库」两个维度拆。

3. 服务端渲染或静态生成。如果首屏完全依赖 JS 渲染，LCP 很难做好。SSR/SSG 能让首屏 HTML 直接带内容。但这是架构级改动，成本高，放在第二优先级而不是第一。

4. CDN 与就近接入。静态资源走 CDN，API 用就近节点。跨地域访问的延迟问题，靠前端优化解决不了。

第三优先级：细粒度优化（ROI 递减区）

做到这里，页面通常已经在「良好」区间了。继续优化需要投入大量精力但收益很小：

- 虚拟列表（长列表才需要）

- 防抖节流调优

- 减少重排重绘（用 transform 代替 top/left）

- Web Worker 分担计算

- 骨架屏与感知性能优化

这些不是不重要，而是应该在真正需要时才做——比如列表确实有上千条、确实有卡顿反馈。

不要做的事

1. 不要在没数据的情况下优化。凭直觉优化经常做无用功，甚至引入 bug。

2. 不要过早优化。代码还没跑起来就想着性能，会牺牲可维护性。

3. 不要优化非关键路径。用户看不到的页面、低频操作的页面，优化收益极低。

4. 不要忽略监控。优化完不留监控，几个月后又会退回去。把性能指标纳入 CI 或定期巡检。

一个实用的执行顺序

如果只能记住一句话：先量数据 → 再砍体积 → 然后缩短关键路径 → 最后才做细粒度调优。

实践中，前两步（压缩缓存 + 图片 + 删无用代码）通常能解决 60%-70% 的性能问题，而它们加起来可能只需要一两天。剩下的才是需要长期投入的部分。

最后提醒：性能是持续工程，不是一次性项目。定个季度目标（比如 LCP 进 2.5s），纳入每次发版的检查项，比搞一次「性能优化专项」有效得多。