为网页优化图片速度：在不牺牲画质的前提下，大幅减少页面加载时间

Last updated: June 28, 2026

图片通常是网页中最重的部分，因此优化它们是你提高页面速度能做的影响最大的单一更改。工作方法很简单：提供正确的尺寸、正确的格式和正确的压缩率，然后延迟加载用户不会立即看到的图片。本指南涵盖了如何在不损失可见画质的情况下减少图片权重和加载时间的具体步骤，以及这些提升如何体现在 Core Web Vitals 中。

快速答案：如何优化图片以提高网页速度？

将每张图片都调整到其实际显示尺寸，转换为 WebP（或带有 AVIF 作为后备格式），将其 compress 到质量 80，并使用 srcset 提供响应式变体，确保每个设备加载正确的尺寸。对视口下方的图片进行懒加载，并通过 CDN 进行交付。这个流程可以将图片权重减少 70% 或更多，且不会损失可见画质，这直接改善了 Largest Contentful Paint 指标和整体页面加载速度。

为什么图片会占据页面的大部分权重？

一个典型的网页在字节计数上大部分是图片。文本量很小，CSS 和 JavaScript 的大小是有限的，但一张未经优化的英雄照片本身可能就有好几个兆字节。以全分辨率和重格式提供图片，默认就会让页面变得沉重。

优化空间巨大，因为默认做法——上传一张相机分辨率的 JPEG——是极其浪费的。一张 5000 像素的照片在显示时只需要 800 像素，这比需要的像素多出六倍，如果用 WebP 可以实现但使用了 JPEG，则增加了更多冗余数据。同时解决这两个问题可以极大地缩小文件体积。

Step 1: Resize to the display dimensions

永远不要提供超过图片实际显示尺寸的像素。将图片 Resize 到最大的显示宽度，并乘以 2 以获得 Retina 清晰度。

• 测量显示槽位，而不是源分辨率。
• 对于 Retina 屏幕乘以 2（对于高密度手机为 3x）。
• 在压缩之前进行调整尺寸——像素越少，压缩后文件越小。
• resize guide 介绍了如何干净地完成这一步骤。

Step 2: Convert to a modern format

格式的选择决定了文件大小的底线。在现代浏览器上，WebP 和 AVIF 比 JPEG 能更好地压缩照片，且不会损失可见画质。

• AVIF — 文件最小，支持度正在增长。应与 WebP 或 JPEG 后备格式一起提供。
• WebP — 实用默认选择，广泛支持，比 JPEG 小得多。
• JPEG — 不受支持浏览器的通用后备格式。
• SVG — 用于 Logo 和图标；无限可扩展且文件极小。

format comparison 和 AVIF vs WebP guide 涵盖了权衡取舍。使用 <picture> 元素首先提供 AVIF，并搭配 WebP 和 JPEG 作为后备格式。

Step 3: Compress to the target quality

在调整尺寸和转换格式之后，再次 compress 以进一步减少字节数。质量 80 是照片的最佳甜点——在这个显示尺寸下，损失是肉眼不可见的。

在 100% 缩放下进行测试，以确认没有可见的伪影。compression guide 涵盖了相关技术。

Step 4: Serve responsive variants and lazy-load

不同的屏幕需要不同的尺寸，而视口下方的图片不需要立即加载。都应该用标记语言来处理。

• 使用 srcset 和宽度描述符，确保每个设备都能获取正确的图片文件。
• 为视口下方的图片添加 loading="lazy" 以延迟加载。
• 保持英雄图（hero image）的即时加载（eager-loaded），以确保 LCP 元素快速加载。
• 始终设置 width 和 height 属性，以防止布局偏移。

responsive images guide 和 lazy loading guide 详细介绍了实现方法。

Image optimization如何影响 Core Web Vitals？

图片优化直接影响 Largest Contentful Paint (LCP) 指标，该指标通常衡量英雄图加载的速度。一个沉重、加载缓慢的英雄图会使 LCP 超过 Google 视为“良好”的 2.5 秒阈值，这既损害了用户体验也损害了搜索排名。Core Web Vitals guide 和 image SEO guide 将这些提升与排名联系起来，而 web.dev LCP documentation 解释了该指标。Mozilla performance guide 涵盖了更广泛的测量图景——优化后运行 PageSpeed Insights 以确认 LCP 是否得到改善。

一个实战示例：优化一张英雄图片

通过一个单一的图片流程，将抽象的步骤具体化。假设你拿到了一张来自相机的、宽度为 5000 像素的 JPEG，它将被用于网站上一个宽度为 1200 像素的英雄槽位。

1. 调整尺寸：从 5000px 调整到 2400px（1200 显示 × 2 用于 Retina）。由于像素数量下降了超过 75%，文件立即缩小。
2. 转换格式：将 JPEG 转换为 WebP。仅格式的改变通常就能在等质量下再减少 25-35%。
3. 压缩：压缩到质量 80。可见损失可以忽略不计，但字节数进一步下降。
4. 提供变体：使用 srcset 提供 1200w 和 2400w 的变体，这样手机就能获取更小的文件。
5. 懒加载：如果它不是 LCP 元素，则进行懒加载；如果是英雄图，则保持即时加载。

一个原始的 6 MB 文件通过这些步骤后，大约会变成 150 KB——这是一个 97% 的减少，且在显示上没有可见画质损失。将这个逻辑推广到包含十几张图片的页面，页面的权重就会崩溃，这就是为什么图片优化是大多数网站最高杠杆效应的速度工作。同样的逻辑适用于每张图片，这也是自动化整个流程能发挥作用的原因。

跨站点的自动化优化

手动优化一张图片很简单；但要手动优化一个不断增长的网站上的所有图片则不然了。可持续的方法是将优化集成到工作流中，使其自动发生，而不是成为一个容易被遗忘的手动步骤。

一个在每次部署时运行 WebP 转换和压缩的 build-step 工具，可以确保没有未经优化的图片到达生产环境。对于基于 CMS 的网站，一个上传优化插件可以在源头捕获图片。而对于布局不可预测的网站，一个实时转换的 CDN 可以处理尺寸问题，无需手动创建变体。正确的自动化取决于技术栈，但原则是相同的——让优化成为默认行为，而不是依赖于某人记得执行它。

衡量结果

没有测量就没有优化。运行完这些步骤后，使用真实的工具来验证提升效果。

1. 运行 Google PageSpeed Insights 并检查图片推荐。
2. 确认 LCP 低于 2.5 秒。
3. 检查网络标签页（network tab）实际提供的文件大小。
4. 在移动连接上进行测试，而不仅仅是宽带。

经过优化并通过这些检查的页面，拥有的是真正快速的图片。这项工作是可重复的——在发布前对每张图片运行相同的步骤，整个网站的速度提升就能保持下来。

常见问题解答

最大的图片速度提升点是什么？

调整到显示尺寸。一张 6000px 的相机照片以 800px 显示，这是最大的浪费。首先调整尺寸，然后压缩——顺序比工具更重要。

我是否应该对所有图片都进行懒加载？

视口下方的所有内容，是的。LCP 英雄图必须即时加载（并预加载）；对其进行懒加载会延迟最大元素，损害 Core Web Vitals。将其余部分懒加载，以免它们与英雄图竞争带宽。

如何衡量图片速度？

PageSpeed Insights 在 28 天的窗口期内收集现场数据（field data），而不是单次实验室测试。实验室工具（Lighthouse）显示的是潜力；现场数据则展示了真实用户体验。CWV 是基于现场数据的评分。

哪个格式对网页最快？

WebP 作为安全的默认选择（比 JPEG 小 25–35%，通用支持），或者 AVIF 用于现代浏览器上的最小文件。通过 <picture> 元素，使用现代格式并搭配 JPEG 后备格式提供。

如何提供响应式图片？

为你的断点所需的尺寸生成每张图片，然后使用 srcset 并附带一个描述显示宽度的 sizes 属性，让浏览器根据视口选择正确的图片文件。浏览器只下载它需要的变体，从而节省了小屏幕的字节数。查看 responsive images guide 获取完整设置。

什么是懒加载？

这是一种浏览器功能，它会延迟加载直到图片接近视口，这样视口下方的图片就不会与英雄图争夺带宽。将 loading="lazy" 添加到视口下方的图片上。LCP 英雄图必须即时加载（不能是 lazy），因为对其进行懒加载会延迟最大元素并损害 Core Web Vitals。