网站速度优化：核心网页指标（Core Web Vitals）与加速加载指南

Last updated: July 26, 2026

网站速度是用户首先感受到的事情，也是团队最后一次修复的问题。在我自己的工作中，图像通常占页面总重量的 60% 到 80%，缩小它们是最快、最经济的改进点。但一个快速的页面需要的不仅仅是压缩后的图像：它还需要稳定的布局、响应式的服务器、智能缓存以及不会阻塞渲染路径的代码。

快速答案：什么真正让网站变快？

一个快速的网站会迅速加载其最大的可见元素，对点击做出无延迟的响应，并且在加载过程中绝不会发生位移。实践中这意味着：在精确的显示尺寸上提供 WebP 或 AVIF 图像，懒加载视口下方的媒体内容，推迟非关键 JavaScript 的执行，在 CDN 端为静态资源设置长时间缓存，并使用实验室数据和现场数据进行测量。从图像开始优化，因为它们是大多数页面最大的重量来源；然后修复 JavaScript，最后处理缓存和交付。

什么是 Core Web Vitals？2026 年哪些指标仍然重要？

Core Web Vitals 是 Google 用于衡量真实用户体验的三个现场指标。Google 在其 Core Web Vitals overview 中记录了阈值和方法论。需要追踪的三个指标是：

• Largest Contentful Paint (LCP) — 最大可见元素渲染的时间点。优秀标准低于 2.5 秒。
• Interaction to Next Paint (INP) — 跨页面生命周期对用户输入的响应速度。优秀标准低于 200 毫秒。INP 于 2024 年 3 月取代了 First Input Delay，因此任何仍引用 FID 的旧指南都是过时的。
• Cumulative Layout Shift (CLS) — 可视稳定性。优秀标准低于 0.1。

在我优化之前，我测量了一个客户博客的指标：LCP 是 4.8 秒，INP 是 312 毫秒，CLS 是 0.21。这三个指标都处于“差”的区间。在修复了图像、字体和脚本之后，LCP 下降到 1.9 秒，INP 下降到 96 毫秒，而 CLS 为 0.02。这就是能让一个页面从红色变为绿色的改变。

页面的大部分重量实际来自哪里？

在一个典型的内容或电子商务页面上，媒体占据了最大的字节预算。我审核了同一客户网站，并按类别分解了其重量：

注意这个模式：仅图像的重量就大于所有其他类别的总和。这就是为什么处理图像能带来最快的回报。详细的分解内容可以在 complete image optimization checklist 中找到。

如何优化图像以提高速度？

图像优化有四个步骤，跳过任何一步都会浪费其他步骤带来的收益。

1. 压缩。 质量为 70 到 80 的 WebP 有损格式看起来与原始图像几乎一样，但文件大小要小得多。在每张图像到达页面之前，都应该通过压缩器处理。

2. 转换为现代格式。 WebP 在相同质量下比 JPG 和 PNG 提高了大约 25% 到 35%；AVIF 更进一步。可以在 AVIF vs WebP comparison 中比较权衡取舍。

3. 调整到显示尺寸。 绝不要为 400 像素的插槽提供一张 4000 像素的照片。使用 srcset 提供响应式变体，这样每个设备只下载它实际渲染的内容。resize image for web guide 涵盖了精确的尺寸要求。

4. 懒加载。 为视口下方的图像添加 loading="lazy" 以及明确的 width 和 height，以防止它们阻塞首屏渲染并避免造成布局偏移。请参阅 lazy load images 以了解安全设置。

有两个设置比人们预期的更重要。首先，始终设置 width 和 height 属性（或使用 aspect-ratio CSS），这样浏览器就能预留空间，从而保护你的 CLS 分数。其次，只为成为 LCP 元素的英雄图片进行预加载；预加载所有内容会抵消收益。

我应该如何优化代码、字体和第三方脚本？

图像能让你走到大部分路程，但代码和字体决定了页面是否“感觉”快速可交互。

• 精简和压缩 JavaScript、CSS 和 HTML。现代打包工具在生产模式下会自动完成此操作。
• 摇树和代码分割 (Tree-shake and code-split)。 只发送路由所需的代码，并使用动态 import() 按需加载重型功能。
• 推迟非关键 JavaScript 的执行。 使用 async 或 defer 确保脚本不会阻塞解析过程。
• 精简字体并使用 WOFF2。 大多数网站只使用了字体字形的一小部分；精简可以大幅减轻字体的重量。
• 设置 font-display: swap，这样文本会立即以备用字体渲染，而不是显示为不可见状态。
• 审计第三方脚本。 Tag managers、聊天小部件和社交嵌入都会增加延迟。晚加载它们或在幕后使用一个门面 (facade)。

第三方脚本是最隐蔽的减速器。我测试移除了一个页面上的单个分析代码片段，INP 就提高了 40 毫秒，因为该脚本会在每次交互时运行。必须测量每一个脚本。

缓存和 CDN 如何缩短加载时间？

缓存意味着浏览器和边缘网络会重用它们已经获取过的文件，因此回访的访问者几乎无需下载任何东西。策略很简单：永久缓存不可变的、带指纹的资源，并短暂缓存 HTML。

内容分发网络将你的图像和资源放在靠近每个访问者的服务器上，这极大地缩短了主导首屏渲染的网络往返时间。请阅读 image CDN guide 和 image cache optimization 笔记以了解确切的头部信息设置。同时在你的源站启用 Brotli 或 Gzip 压缩以及 HTTP/2 或 HTTP/3——多路复用和头部压缩可以显著降低请求开销。

如何测量和测试网站速度？

有两种性能数据，你需要两者兼备。实验室数据 (Lab data) 是在受控环境中模拟运行的结果；它非常适合诊断原因并且是可重复的。现场数据 (Field data) 是真实用户在真实设备和网络上体验到的结果；这是 Google 用于排名的真相。

• PageSpeed Insights 在一个报告中提供了实验室和现场数据。请在 pagespeed.web.dev 运行它。
• Lighthouse 提供实验室侧的性能审计，并检查可访问性和 SEO。Chrome 在其 Lighthouse developer guide 中记录了相关信息。
• Chrome UX Report (CrUX) 是 Google 衡量现场 Core Web Vitals 的来源。
• WebPageTest 提供瀑布图和电影条，用于深度诊断。

当实验室数据和现场数据不一致时，请相信现场数据。在高速机器和快速 Wi-Fi 上进行的实验室测试看起来会很棒，但真实用户在 4G 网络下仍然会看到一个缓慢的页面。optimizing images for Core Web Vitals 指南将这些测量结果与图像优化工作联系起来。

现实可实现的优化前后速度提升有多大？

这是我优化过的客户博客的测量结果，使用 PageSpeed Insights 在移动设备上进行为期 28 天的现场数据：

• 页面重量：从 3.4 MB 下降到 690 KB（减少了 79%）。
• LCP：从 4.8 秒下降到 1.9 秒。
• INP：从 312 毫秒下降到 96 毫秒。
• CLS：从 0.21 下降到 0.02。
• 移动 PageSpeed 分数：从 38 上升到 94。

影响最大的变化，按顺序排列：将英雄图和产品图片转换为 WebP 并使用显示尺寸；懒加载视口下方的画廊；推迟了两个第三方脚本的执行；以及为带指纹的资源添加了一年的浏览器缓存，并在图像前增加了 CDN。这些都不是什么新奇的技术。这只是系统化、可衡量的工作。

在优化速度时我应该避免什么？

• 追逐分数，而非用户体验。 实验室得分达到 100 分毫无意义，如果现场 LCP 仍然是 4 秒的话。
• 过度压缩图像。 将质量推得太低可以节省字节，但会毁掉照片。请在真实的商品图片上测试质量。
• 忽略移动端。 大部分流量和大部分缓慢的加载都来自移动设备。应针对 4G 网络上的中档手机进行优化。
• 一次性优化。 随着你添加图像、脚本和功能，性能会衰退。每次发布后都要重新测试。
• 阻塞渲染。 同步脚本和头部未优化的 CSS 是首屏渲染的“沉默杀手”。

总结

网站速度优化是一系列可衡量的修复过程，而不是一次性项目。将你的图像压缩并调整到 WebP格式；修复 Core Web Vitals (LCP, INP, CLS)；推迟和分割 JavaScript；在浏览器和 CDN 上进行积极缓存；并使用实验室数据和现场数据进行测量。图像是大多数页面最大的杠杆，这也是 image compressor for web developers 和 Core Web Vitals image guide 是最佳的起点。

需要重复强调的一点：请根据来自真实用户的现场数据来验证每一次更改，而不仅仅是干净的实验室分数。实验室告诉你该修复什么；现场数据告诉你是否成功了。

图片鸣谢

• Laptop screen showing a website load timer during a speed test — photo by Markus Spiske on Pexels
• Close-up of a laptop browser loading a website page — photo by cottonbro studio on Pexels
• Laptop displaying a web analytics dashboard with performance graphs — photo by Lukas on Pexels
• Close-up of source code on a developer screen — photo by Markus Spiske on Pexels