快速网页图片优化终极清单：从格式选择到CDN设置，掌握所有关键步骤

上次更新时间：June 28, 2026. 在每次发布前重新运行此清单以获得一致的结果。

图像优化是一个序列过程，而非单一步骤。如果跳过任何一个阶段，结果要么是加载缓慢，要么是模糊不清。本清单将按照您实际执行的顺序，详细介绍了每个阶段——格式选择、尺寸调整、压缩、响应式交付、懒加载和 CDN 设置——让您可以在每次发布前运行它，确保图片能够快速加载并保持清晰锐利。

快速答案：完整的图像优化流程包括什么？

一次完整的优化过程意味着选择正确的格式（照片使用 WebP，矢量图使用 SVG，透明度使用 PNG），将其大小调整到显示尺寸，压缩到目标文件大小，提供带有 srcset 的响应式变体，对首屏以下的图片进行懒加载，并从 CDN 提供服务。跳过任何一个阶段都会让性能处于劣势——未压缩的图像会缓慢，尺寸过大的图像会浪费字节，而没有懒加载的图像会延迟初始渲染。请运行整个清单，而不是挑选几个阶段来做。

为什么应该使用清单而非临时优化？

图像优化包含许多小步骤，忘记其中一步就会抵消其他步骤的工作成果。一个清单将一个容易遗忘的多步骤过程，转化为一套可重复、能产生一致结果的例行流程。

• 每个阶段都解决了不同的性能因素。
• 跳过一个阶段就会让该因素没有得到解决。
• 这些阶段足够独立，可以可靠地进行清单检查。

Stage 1: 选择正确的格式

格式是第一个决定，因为它限制了之后的一切。请根据图像内容匹配合适的格式。

• WebP — 在现代浏览器上照片的默认格式。比 JPEG 更小，但质量相同。
• AVIF — 比 WebP 更小，且支持度正在增加。应与 WebP 或 JPEG 作为备用方案一起使用。
• SVG — 用于徽标、图标和矢量图形。无限缩放，文件极小。
• PNG — 用于需要透明度和无损质量的图像。
• JPEG — 当现代格式不受支持时，照片通用的备选方案。

format comparison guide 和 AVIF vs WebP guide 深入介绍了这些权衡取舍。请选择能为内容提供最小文件大小且质量可接受的格式。

Stage 2: 调整到显示尺寸

切勿提供大于其显示尺寸的图片。一张在 600-pixel 区域内显示的 4000-pixel 照片会浪费带宽并减慢页面速度。Resize 到图像将要显示的最大的尺寸，同时考虑到 Retina（2x）屏幕。

在压缩之前进行尺寸调整很重要，因为压缩是基于像素数量工作的——像素越少，压缩后的字节就越少。resize guide 介绍了如何在不损失质量的情况下完成此操作。

Stage 3: 压缩到目标文件大小

尺寸调整后，使用 compress 来减少字节数。目标是最小的文件，且没有可见的质量损失。

• 照片：WebP 或 JPEG，质量设置为 80。
• 带纯色图形：PNG 或无损 WebP。
• 在 100% 缩放下进行测试，确认没有可见的伪影。
• 目标是英雄图片（hero images）低于 200 KB，内容图片低于 100 KB。

compression guide 介绍了相关的技术和质量设置。

Stage 4: 提供响应式变体

不同的屏幕需要不同大小的图像。请使用 srcset 来提供它们，这样每个设备下载的都是正确的文件，而不是“一刀切”的尺寸。

• 为 Retina 屏幕生成 1x、2x 和 3x 的变体。
• 使用 sizes 属性和宽度描述符（如 400w，800w）实现响应式布局。
• 让浏览器自行选择正确的图片文件。
• responsive images guide 介绍了相关的标记方法。

Stage 5: 对首屏以下的图像进行懒加载

首屏以下的图像不应该在用户滚动到它们之前就加载。这可以释放带宽用于初始渲染，并改善 Largest Contentful Paint 指标。

• 为首屏以下的图像添加 loading="lazy" 属性。
• 保留英雄图片（hero image）的即时加载（eager-loaded），以确保 LCP 元素快速加载。
• lazy loading guide 介绍了实现方法。

Stage 6: 从 CDN 提供服务

从内容分发网络（CDN）提供图像服务，可以使其从靠近每个用户的边缘位置加载。CDN 可以减少延迟并卸载源服务器的压力，这对用户地理分布广泛的网站尤为重要——否则，如果用户位于另一个大洲，则必须等待每张图片跨越该距离到达您的源站。CDN guide 介绍了设置方法，包括允许 CDN 即时调整和重新格式化的转换功能；而 Core Web Vitals guide 则将快速图像交付与影响排名的指标联系起来。

CDN 也能够吸收流量高峰。当一个页面爆红或一次活动发送了大量访问者时，边缘缓存会提供图片而不是源站，从而确保网站在原本会压垮单个服务器的负载下仍然保持快速。对于那些网站而言，如果正常运行时间（uptime）与平均加载时间一样重要，这种弹性价值就等同于延迟的降低。

常见的优化错误

即使有了清单，仍有一些错误会反复出现并抵消之前的工作。了解这些错误可以加快验证步骤的速度。

• 先压缩再调整尺寸 — 在将被丢弃的像素上浪费了精力。始终先调整尺寸。
• 对所有设备提供单一尺寸 — 手机下载的是桌面尺寸的文件。请使用 srcset。
• 给英雄图片进行懒加载 — 会延迟 LCP 元素的加载。保持首屏以上的图片即时加载。
• 忘记 width 和 height 属性 — 在图像加载时会导致布局偏移（layout shift）。始终包含它们。
• 用 PNG 处理照片 — 会使文件体积膨胀。对于摄影内容，请使用 WebP 或 JPEG。

验证：优化是否成功了？

运行完清单后，不要凭猜测来验证结果，而要通过测量来确认。工具可以证实图像是否确实加载得很快，只有测量才能知道优化是否奏效——目视检查无法揭示文件大小或加载顺序。请在快速和慢速连接上都运行这些检查，因为在宽带下看起来没问题的优化，在移动数据网络上仍然可能遇到困难。

1. 运行 Google PageSpeed Insights 并检查与图像相关的机会点。
2. 确认 LCP 元素在 2.5 秒内加载。
3. 检查 network tab 以确认每个设备都加载了尺寸正确的图片文件。
4. 验证懒加载的图像是否直到滚动才会出现。

web.dev performance measurement guide 记录了 PageSpeed 如何评分页面，而 Mozilla performance guide 则深入介绍了这些指标。一个通过了这些检查的页面，拥有的是真正快速的图像——而不是仅仅看起来经过优化的图像。对于更广泛的 SEO 背景，image SEO guide 将这些性能提升与搜索排名联系起来。

常见问题解答

一次完整的图像优化流程包括什么？

选择正确的格式、调整到显示尺寸、压缩到目标文件大小、提供带有 srcset 的响应式变体、对首屏以下内容进行懒加载，并在 CDN 进行缓存。跳过任何一个阶段都会让字节或质量处于劣势。清单的存在就是为了不遗漏任何阶段。

为什么应该使用清单而非临时优化？

因为临时优化容易忽略阶段——开发人员可能进行了压缩但忘记了调整尺寸，或者添加了 srcset 但忘记了懒加载。清单确保了整个网站的每张图片都能一致地经过所有阶段。一致性才是推动 Core Web Vitals 实现规模化提升的关键。

最大的图像优化收益是什么？

将尺寸调整到显示尺寸。一张在 6000px 的相机照片，但在 800px 处提供，是大多数网站上最大的浪费。首先进行尺寸调整；其他所有优化都建立在一个正确尺寸的基础之上。

如何提供响应式变体？

为您的断点所需的每个尺寸生成图片，然后使用 srcset 和 sizes 让浏览器根据视口选择正确的图片文件。浏览器只会下载它需要的那个变体，从而节省了小屏幕上的字节数。请参阅 responsive images guide。

我多久重新优化一次图像？

每当您添加新图片时，以及当 Core Web Vitals 下降时审计现有图片集。几年前优化的旧图片可能格式是 JPEG，而现在使用 WebP 会更小。定期审计可以发现格式和压缩上的漂移。

如何审计现有网站的图片？

运行爬虫（Lighthouse 或 Screaming Frog 等工具），列出每张图片的尺寸和维度，然后标记任何超出其显示区域尺寸、本应使用 WebP 但使用了 JPEG 的图片，或缺少 width/height 属性的图片。首先修复最严重的违规项——少数几张巨大的图片通常占用了页面大部分的重量。修复后重新运行审计以确认改进。