几乎每个前端团队都经历过这样的对话：产品经理说「这个页面打开好慢」，开发说「我本地很快啊」，然后双方各自沉默。问题的根源在于，我们平时说的「快」是一种主观感受，而性能优化真正需要的是一套可测量、可归因、可回归的指标体系。这篇文章不打算罗列一堆优化技巧，而是想聊聊如何把「感觉快」变成「测得出快」——因为只有在能测的基础上，优化才不会变成一场凭直觉的赌博。
一、先把「快」翻译成数字：从 Core Web Vitals 说起
用户对速度的感知其实由三个截然不同的阶段构成，这也是 Core Web Vitals 把指标拆成三块的原因。第一块是加载阶段，对应 LCP（Largest Contentful Paint），衡量页面主体内容何时出现在屏幕上——用户此刻才真正”看见”你的页面。第二块是响应阶段，对应 INP（Interaction to Next Paint），衡量用户点击、输入后界面多久给出视觉反馈。第三块是稳定性，对应 CLS（Cumulative Layout Shift），衡量内容是否在加载过程中乱跳。
这三个指标之所以重要，是因为它们各自对应一类完全不同的失败模式。LCP 差，通常是资源加载链路的问题：图片太大、字体阻塞、服务器响应慢、关键 CSS 被藏在后面。INP 差，往往是 JavaScript 在主线程上跑了太久，用户的点击排队等一个长任务跑完。CLS 差，则多半是图片没写宽高、广告位动态插入、字体替换导致回流。**如果你只有一个「页面加载时间 2.3 秒」这样的数字，你根本无法判断该去优化哪一块。**
我建议团队在接入监控时，不要只上报一个聚合的平均值。平均值是这个世界上最会骗人的统计量之一：一个 P50 是 1.2 秒的页面，P95 可能是 8 秒，而那 5% 的用户恰恰是付费意愿最高、网络环境最复杂的一批人。正确做法是按 P75 甚至 P95 来看，并且按设备类型、网络类型、地域做分桶。你会发现很多”看起来还行”的页面，在低端安卓机上是灾难。这一步不需要任何代码技巧，只需要改变看数字的方式，却往往是收益最大的一步。
二、优化资源瀑布：真正的大头从来不是 JS 压缩
当指标能测出来之后，优化就有了方向。业界有个常见的误区：一提到性能优化就去卷 JS 压缩率、去换打包器、去研究 tree-shaking。这些当然有用，但通常只能带来个位数百分比的提升。真正占据加载时间大头的是关键渲染路径上的阻塞——那些你不加载它就什么都渲染不出来的资源。
第一件事是让图片回到它该有的大小。我在多个项目里做过统计，首屏图片超标的比例高得惊人：一张用手机拍的原图直接上传，5000 像素宽、3MB 大小，最后展示区域只有 400 像素宽。解决方案不是简单地”压缩一下”，而是建立完整的响应式图片链路：用 srcset 和 sizes 让浏览器自己选尺寸，用 AVIF/WebP 做格式降级，用 loading="lazy" 把非首屏图延后。仅仅这一步，我的经验是首屏图片字节数通常能降 60% 到 80%。
第二件事是给资源排优先级。浏览器默认的加载顺序是按文档顺序来的，但真正影响 LCP 的那张主图或那段关键 CSS，可能排在第十几个位置。你需要用 fetchpriority="high" 把它顶到前面，用 preconnect 提前建立第三方域名连接，同时把不影响首屏的脚本加上 defer 或 async。**这里的关键心智是：不是所有资源都同等重要，而浏览器不知道哪个重要，你必须告诉它。**
第三件事是重新审视第三方脚本。一个页面挂上统计、客服、A/B 测试、广告四个 SDK，每个几十到几百 KB，还要发各自的网络请求，加起来轻松超过你自己的全部业务代码。它们的加载和执行往往同步阻塞，而且不受你控制。我的建议是给每个第三方脚本做一次”业绩审查”：它带来了什么价值？能不能延迟到页面交互后再加载？能不能用 requestIdleCallback 或用户触发式加载？砍掉一个不产生价值的 SDK，比把 webpack 配置调优一整周都管用。
三、守住主线程：让页面在用户动手时还能喘气
加载快了不代表体验就好。很多页面首屏渲染只用了 800 毫秒，但用户一滚动就卡顿，一点按钮就没反应——这时候问题已经不在网络层，而在主线程。浏览器只有一个主线程负责执行 JavaScript、计算样式、布局和绘制，任何超过 50 毫秒的任务都会被认为是一次”长任务”，期间用户的所有操作都得排队。
识别长任务最直接的工具是 Performance 面板里的长任务火焰图，但更实用的做法是在监控里采集长任务数据。找到元凶之后，拆解的手段主要有三类。第一类是让出控制权：把一个大循环拆成多个小块，每块之间用 yield 或 setTimeout 让浏览器喘口气，先响应用户的输入。
第二类是把计算搬走：纯计算型的任务——数据加解密、大数组排序、图片处理、复杂格式化——完全可以放进 Web Worker。这一步的心理门槛常被高估，实际上现代打包器对 Worker 的支持已经足够顺手，一个 new Worker(new URL('./worker.js', import.meta.url)) 就能起步。搬走之后主线程只负责拿结果更新界面，流畅度立竿见影。
第三类是减少无效渲染。框架时代最容易被忽视的浪费是过度更新：一个状态变化触发了整棵子树的重新渲染，而实际上只有一个数字变了。虚拟列表、memo 化、状态下移、把高频更新的状态隔离到叶子组件，这些手段的本质都是同一件事——让更新的影响范围与数据的实际影响范围匹配。
最后我想强调回归。性能优化最大的敌人不是难度，而是遗忘。三个月后新来一位同事，随手 import 了一个 400KB 的图表库放在首屏，之前所有努力付之东流。所以指标接入监控、在 CI 里设一个性能预算的硬门槛，让超出预算的提交直接失败，比任何一次性的”性能优化专项”都更持久。
结语
性能优化从来不是一个技巧问题，而是一个认知问题。当你还在用「感觉很快」描述体验时，你能做的只有猜；当你能把体验拆成 LCP、INP、CLS 这样的具体数字，并且按分位数、按设备看分布时，剩下的工作就变成了有明确目标的工程问题。资源层解决的是「多久能看到」，主线程解决的是「能不能用得动」，而监控和预算解决的是「能不能一直快下去」。
这三条线索合起来，其实是一句很朴素的话：不要让用户等你的代码，而要让你的代码等着用户。