Web性能优化：让用户感觉快比真的快更重要

亚马逊曾公开一个数据：网站加载时间每增加 100 毫秒，销售额就下降 1%。谷歌也公布过类似的数据：搜索结果页面加载时间从 0.4 秒增加到 0.9 秒，搜索量减少了 20%。

在互联网世界，速度就是金钱。

但"快"是一个主观感受。一个页面在技术上可能加载很快，但用户却觉得慢。另一个页面加载时间稍长，但用户觉得流畅。这种感知上的差异来自性能优化的一个核心原则：让用户感觉快，比真的快更重要。

Core Web Vitals：Google 的性能标尺

Google 在 2020 年提出了 Core Web Vitals，定义了三个核心的用户体验指标。

LCP（Largest Contentful Paint）衡量的是"主要内容何时可见"。用户打开一个页面，最大的图片或者文字块何时渲染完成。理想的 LCP 应该在 2.5 秒以内。

FID（First Input Delay）衡量的是"页面何时可交互"。用户第一次点击按钮或链接时，页面需要多久才能响应。理想的 FID 应该在 100 毫秒以内。后来 Google 用 INP（Interaction to Next Paint）替代了 FID，衡量所有交互的响应速度。

CLS（Cumulative Layout Shift）衡量的是"页面是否稳定"。页面加载过程中，元素是否会发生意外的位移。比如你正要点击一个按钮，突然一个广告加载出来把按钮推走了。理想的 CLS 应该小于 0.1。

这三个指标直接影响 SEO 排名。Google 明确表示，Core Web Vitals 是搜索排名的因素之一。所以性能优化不只是用户体验问题，也是商业问题。

加载优化：让资源更快到达

页面加载慢的根本原因是资源太多、太大、太远。

减少资源数量是最有效的优化。每个 JavaScript 文件、CSS 文件、图片都需要一次 HTTP 请求。HTTP/2 的多路复用减少了请求的开销，但资源解析和执行的时间仍然存在。合并文件、使用 CSS Sprites、内联关键资源，都是减少请求数量的方法。

减小资源体积同样重要。JavaScript 和 CSS 的 minification（去除空白和注释）可以把文件大小减少 30% 到 50%。图片压缩（WebP、AVIF 格式）可以在保持视觉质量的前提下大幅减小文件大小。Brotli 压缩比 Gzip 压缩率更高，现代浏览器都支持。

让资源离用户更近是第三个策略。CDN 把静态资源缓存到全球各地的节点，用户从最近的节点获取资源，延迟大幅降低。对于全球化的产品来说，CDN 是必需品。

渲染优化：让用户更快看到内容

资源到达浏览器后，还需要解析和渲染。渲染优化的目标是让用户尽快看到有意义的内容。

关键渲染路径优化是核心。浏览器需要先构建 DOM 树和 CSSOM 树，然后合并成渲染树，最后绘制到屏幕上。阻塞渲染的资源（比如同步加载的 CSS 和 JavaScript）会延迟首次渲染的时间。

把关键 CSS 内联到 HTML 中，可以避免额外的 CSS 文件请求阻塞渲染。非关键的 CSS 可以异步加载。JavaScript 标签加上 async 或 defer 属性，避免阻塞 HTML 解析。

服务端渲染（SSR）是另一种策略。在服务端把页面的 HTML 生成好，浏览器收到后直接渲染，不需要等待 JavaScript 下载和执行。用户能更快看到内容，虽然页面可能还不能交互。

静态站点生成（SSG）更适合内容不频繁变化的网站。在构建时就把所有页面生成为静态 HTML，部署到 CDN 上。访问速度极快，因为不需要服务端实时生成。

交互优化：让用户感觉流畅

页面可见之后，还需要保证交互的流畅性。

JavaScript 的执行是交互卡顿的主要原因。长任务（执行时间超过 50 毫秒的 JavaScript 代码）会阻塞主线程，导致用户交互无响应。解决方案是把长任务拆分成小任务，用 requestIdleCallback 或 requestAnimationFrame 在空闲时间执行。

虚拟列表是处理长列表的常用技术。一个有一万条数据的列表，不需要渲染所有 DOM 元素。只渲染可见区域的元素，滚动时动态替换。这样无论列表多长，DOM 元素的数量始终是有限的。

防抖和节流是处理高频事件的技术。用户输入搜索关键词时，不需要每次按键都发请求，防抖可以在用户停止输入一段时间后再发请求。滚动事件不需要每一帧都处理，节流可以限制处理频率。

预测性加载：提前准备好

最极致的性能优化是：在用户需要之前就把资源准备好。

prefetch 提示浏览器在空闲时间预先加载用户可能访问的下一个页面的资源。preload 提示浏览器立即加载当前页面关键的资源。preconnect 提前建立到第三方域名的连接。

更智能的方式是基于用户行为预测。如果数据显示 80% 的用户在看完首页后会点"产品"页面，那可以在首页加载完成后预加载"产品"页面的资源。当用户真正点击时，页面几乎是瞬间加载的。

但预测性加载需要谨慎使用。预加载消耗用户的带宽和电量，如果预测不准，就是浪费。移动端用户可能对流量消耗敏感。

度量与持续优化

性能优化不是一次性的工作，而是持续的过程。

建立性能监控体系是第一步。使用 Real User Monitoring（RUM）收集真实用户的性能数据，而不是只依赖实验室数据。不同的用户、不同的设备、不同的网络条件下，性能表现可能差异巨大。

设置性能预算是一种有效的管理方式。比如规定 JavaScript 总大小不超过 200KB，LCP 不超过 2.5 秒，CLS 不超过 0.1。当性能指标超过预算时，CI/CD 流水线自动失败，阻止性能退化上线。

性能优化最大的敌人是"逐步退化"。每次添加一个新功能、引入一个新依赖，性能可能只下降一点点。但日积月累，这些微小的退化会叠加成显著的性能问题。性能预算和持续监控是防止这种退化的有效手段。

我的判断

Web 性能优化是投入产出比最高的工程投资之一。它直接提升用户体验、转化率、SEO 排名，而且大部分优化措施不需要改变业务逻辑，只是技术层面的调整。

对于新项目，从一开始就建立性能预算和监控体系。不要等到性能问题严重了才开始优化，那时候优化的成本会高得多。

对于已有项目，先做 RUM 数据分析，找到性能瓶颈在哪里。80% 的性能问题通常出在 20% 的资源上。针对性地优化这些瓶颈，效果最显著。

性能优化的终极目标不是让页面加载快，而是让用户感觉流畅。这两者有时候是矛盾的。一个加载时间稍长但交互流畅的页面，可能比一个加载快但交互卡顿的页面体验更好。关注用户感知，而不只是技术指标。