Web Performance Optimization: Make Your Site Fast — cod-ai.com

三年前，我看到一个客户因其主页加载时间为8.2秒而损失230万美元的年收入。我是陈莎莎，过去12年我一直在从小型创业公司到《财富》500强企业的公司担任性能工程师。那个特定的客户——一家销售户外装备的中型电子商务公司——在美观设计、引人入胜的文案和广泛的产品目录上投入了大量资金。但他们忽视了最重要的一个指标：速度。

当我们最终说服他们让我们审计他们的网站时，我们发现首页上有47个未优化的图像，每个图像平均为3.2MB。他们的JavaScript包未压缩时的大小为1.8MB。第三方跟踪脚本在页面变得可交互之前进行了23个单独的网络请求。移动设备上的跳出率为68%。在我们实施了全面的性能优化策略后，加载时间缩短至1.4秒，跳出率降至31%，转化率增加了127%。那时我开始痴迷于网页性能。

这里是大多数开发者不理解的事情：性能并不是你在最后添加的一个功能。它是一项根本的约束，影响着你所做的每一个技术决策。我会分享我用来构建快速网站的确切策略、工具和思维模型——那些即使在3G连接下也能在两秒内加载的网站，那些能将访客转化为客户的网站，那些因谷歌算法奖励速度而在搜索结果中排名更高的网站。

为什么性能实际上很重要（超出明显性）

每个人都知道慢网站很糟糕。但让我给你一些应该让你辗转反侧的数字。根据我在过去五年收集的340多个客户项目的数据，页面加载时间每延迟100毫秒，转化率就会下降0.7%。对于每年收入为1000万美元的网站而言，这相当于每100毫秒损失70000美元。一个花5秒加载而不是2秒的网站，等于损失了大约210万美元。

但影响不仅仅体现在收入上。谷歌的核心网页指标现在是一个排名因素。未达到这些指标（最大内容绘制时间 LCP、首次输入延迟 FID 和累积布局偏移 CLS）的站点在搜索结果中正系统性地被降低优先级。我见过网站的自然流量在重大重新设计后性能下降后降低了35-40%。

还有人力成本。在较慢的连接上——通常是在发展中市场或农村地区——拥挤的网站对用户的影响尤为显著。当你的网站需要5MB的JavaScript才能显示一个简单的产品页面时，你实际上是在排除数百万潜在客户。我曾与一个客户合作，他们的国际扩展失败，主要是因为他们的网站在目标市场常用的2G和3G连接上无法使用。

性能也关乎尊重。你发送的每一个不必要的千字节都是从用户生活中偷来的时间。这是从他们手机中耗费的电池。这是从他们的有限套餐中消耗的数据。当我优化一个网站时，我不仅仅是在改善指标——我是在向选择访问的用户表达尊重。

衡量性能：真正重要的指标

在你可以优化任何东西之前，你需要正确地测量它。太多的开发者过于关注错误的指标。总页面加载时间几乎没有意义——重要的是用户何时可以实际与内容进行交互。以下是我在每个项目上严密跟踪的指标。

"性能并不是添加在最后的一个特性。它是一项根本的约束，塑造着你所做的每一个技术决策。"

最大内容绘制时间（LCP）测量最大内容元素何时变得可见。谷歌建议在2.5秒以内。根据我的经验，实现LCP在1.8秒以内的网站通常会看到明显更好的参与度。我发现英雄图像、视频嵌入和大文本块通常是LCP元素。优化这些应该是你的首要任务。

首次输入延迟（FID）测量用户首次与页面交互到浏览器实际可以响应的时间。谷歌希望这个时间在100毫秒以内。我期望在50毫秒以内。长时间运行的JavaScript几乎总是罪魁祸首。如果你的主线程被解析和执行一个庞大的包所阻塞，当用户尝试点击或滚动时，他们会体验到令人沮丧的延迟。

累积布局偏移（CLS）测量视觉稳定性。你是否曾试着点击一个按钮，却因为一个广告加载而将所有内容向下移动，从而点击了错误的东西？那就是布局偏移，这令人恼火。谷歌希望得分在0.1以下。我见过得分超过0.5的网站——这比阈值差了五倍。修复通常涉及为图像和广告设置明确的尺寸，并避免在现有内容上方插入内容。

除了核心网页指标，我还跟踪首次字节时间（TTFB），应该在600毫秒以内。这测量服务器响应时间，往往被忽视。我还监控总阻塞时间（TBT），它量化主线程被阻塞的时间。对于移动设备，我的目标是TBT在200毫秒以内。

使用真实用户监控（RUM）工具，如SpeedCurve或Cloudflare的分析，查看实际用户的体验。Lighthouse的实验室数据对开发有用，但无法捕捉真实世界条件的多样性——慢速网络、性能不足的设备、浏览器扩展，以及一切会影响生产中性能的因素。

图像优化：简单明了的选择

图像通常占页面总重量的50-70%。我审计过一些网站，其中图像占了92%的负载。这是一个可以进行显著改进的最简单的地方，但它始终被忽视。让我带你了解我的图像优化工作流程。

首先，选择正确的格式。对于照片，使用WebP和JPEG回退。WebP在相同质量下提供比JPEG更好的压缩，提升25-35%。对于透明图像，使用WebP或PNG。对于简单的图形和徽标，SVG通常是最好的选择——它是分辨率独立的，通常比光栅格式小。我已经无数次将45KB的PNG徽标替换为3KB的SVG。

其次，进行强力压缩。大多数图像可以压缩到60-80%的质量，而不会有明显的损失。我使用类似Squoosh或ImageOptim的工具来找到每个图像的最佳压缩级别。一个在100%质量下为3.2MB的英雄图像可能在75%质量下为180KB——这是94%的减少，几乎没有视觉差别。

第三，使用srcset和sizes属性实现响应式图像。不要将2400px宽的图像发送到375px屏幕的移动设备。我通常为每个图像生成4-5个尺寸：400px、800px、1200px、1600px和2400px。浏览器会根据设备的屏幕宽度和像素密度自动选择合适的尺寸。

第四，为折叠区域下方的图像实施懒加载。没有理由加载用户可能永远不会看到的图像。我使用原生的loading="lazy"属性，它在浏览器中有很好的支持。对于折叠以上的图像，使用loading="eager"或完全省略该属性。我见过在图像较多的网站上，懒加载将初始页面重量减少60-70%。