图片如何减缓网站加载速度？了解图片优化和实用的加速修复方案。

最后更新: June 28, 2026

在我审计的几乎所有缓慢网站上，原因都是一样的：图片。文本、字体和 JavaScript 都很重要，但媒体是典型内容或电子商务页面上占主导地位的重量，而且这是团队最晚优化的部分。本文重点关注了图片如何影响加载速度，以及我在生产环境中测得的修复方法。关于更广泛的图景，website speed optimization 指南也涵盖了代码、字体和缓存等内容。

快速答案：图片如何拖慢网站？

图片通常占总页面重量的 60% 到 80%，在图片密集的页面上，它们是影响加载时间的最大因素。最能起到作用的四个修复方法是：提供与精确显示尺寸匹配的现代格式、压缩到合理的质量、对视口下方的媒体进行 lazy-loading，以及将资源放在 CDN 后端。

在我测量的客户博客上，这四项更改将页面重量从 3.4 MB 降低到了 690 KB，并将 Largest Contentful Paint 从 4.8 秒降低到了 1.9 秒。请从最大的图片开始着手，并测量优化前和优化后的数据。

图片为什么会拖慢你的网站？

每张图片都是一次网络请求，加上浏览器必须下载、解码和渲染的字节数。在典型的页面上，这些字节数远远超过了其他所有内容。我按类别分解了同一客户网站的重量：

图片比所有其他类别加起来还要大，这就是为什么图像优化带来的回报速度比任何其他更改都快。相同的字节也会带来解码时间成本：即使下载完成，一张 4 MB 的照片也会阻塞主线程，直到浏览器解压缩它。

我观察到，解释这种缓慢的机制有三个，按照出现的频率排序：

• 过多的字节 — 将一张 4000 像素的照片塞进一个 400 像素的插槽中。
• 错误的格式 — 用 WebP 代替全彩 PNG 来处理照片。
• 未优化的交付 — 没有 CDN，没有缓存，没有响应式变体。

前两个是关于你发送什么内容。第三个是关于你如何发送它。每一种都有明确的修复方法，将在下面介绍。

页面重量实际花费了多少秒？

页面重量通过网络转化为时间。一个粗略但有用的规则是：在 4G 连接上的中端手机，现实世界中的下载速度大约是每秒 1 到 1.5 MB，而不是理论峰值。因此，一个 3.4 MB 的页面仅获取就需要大约 3 秒的时间，这还没算上浏览器做任何工作。

我直接在客户网站上测量了这一点，保持其他所有因素不变，只改变了图片重量：

你每减少一个 megabyte，在典型的移动连接上大约就能节省一秒钟。这就是为什么图片重量比你的 CSS 或 JavaScript 中的任何微小优化都更重要。Google 在其 web.dev fast guide 中记录了页面重量和加载性能之间的关系，而 PageSpeed Insights 将过大的图片列为主要的审计失败项之一。

如何提供正确的格式和尺寸？

最大的单一收益是将照片从 JPG 和 PNG 转换为现代格式，并将其调整到显示尺寸。WebP 在相同感知质量下比 JPG 小约 25% 到 35%；AVIF 更进一步，但编码速度更不稳定。我默认使用 WebP，因为它解码快，并且在 2026 年随处可用。

1. 调整到显示尺寸。 一个 4000 像素的照片放在 400 像素的插槽中，其大小是需要的十倍。将内容图片的长边限制在 1600 到 1920 像素之间。

2. 转换为 WebP，质量设置为 75 到 82。 这个范围对于照片来说几乎无法与原始图像区分开来，并且节省了最多的字节。再降低一点，天空和渐变就会出现色带现象。

3. 只为英雄图片保留 AVIF 变体（如果支持），因为 AVIF 编码缓慢，只有在你最大的内容元素上才值得使用。

关于不同用例的精确尺寸，resize image for web guide 有相关数据。为了在不损失质量的情况下达到最佳效果，compress images without losing quality 工作流介绍了我使用的 WebP 设置。

如何在发布前进行压缩和转换？

压缩应该发生在构建阶段，绝不能发生在浏览器中。目标是使用一个源图片，自动生成优化后的变体。

## Convert a hero to WebP at display size, quality 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

对于整个目录，我使用了一个小的循环来发出多个宽度。关键的纪律是绝不提交原始的 5 MB 照片。

• 为内容设置最低质量为 70，为产品照片设置 75，然后根据实际图像进行目测调整。
• 去除元数据 (EXIF, 不需要的颜色配置文件) — 这可能会增加数十 KB 的数据，但没有任何视觉益处。
• 为每个断点生成一个变体，而不是为每种设备生成一张巨大的图片。
• 在 CI 中自动化，以确保过时的图片永远不会到达生产环境。

一个常见的错误是压缩了上传的图片，却忘记了 CMS 生成的所有缩略图和响应式变体。请对所有尺寸运行管道，而不仅仅是原始尺寸。这是我测量到页面重量下降最剧烈的步骤——通常是从原始大小的 70% 到 80%。

如何进行视口下方的 lazy-load？

视口下方的图片不应该阻塞首次渲染。原生 lazy loading 可以通过一个属性和零 JavaScript 来实现这一点。

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Product photo in natural light">

有两个属性比人们想象的更重要：

1. loading="lazy" 会推迟获取，直到图片接近视口，因此它永远不会与首次绘制竞争。
2. width 和 height 允许浏览器在图片到达之前预留空间，这可以防止 Cumulative Layout Shift。

不要对你的英雄图或 LCP 图片进行 lazy-load — 这会延迟页面上最重要的元素。我遵循的规则是：lazy-load 所有视口下方的内容，而为用户首先看到的那张图片进行 eager-load（急切加载）。

CDN 如何加速图片？

CDN 从靠近每个访问者的服务器提供图片服务，这缩短了主线程绘制时在移动设备和国际流量中占主导地位的网络往返时间。在客户网站上，在图片前添加 CDN 后，使非源区域的访客 LCP 又降低了 400 毫秒。

CDN 还为你提供了即时转换功能：只需通过 URL 请求任何宽度或格式，边缘节点就会生成并缓存它。这消除了预先生成几十个变体的需求。image CDN guide 详细介绍了头部和缓存键。

在指纹化的图片 URL 上设置一个较长的 Cache-Control: max-age=31536000, immutable，这样返回的访客就可以重用这些资源。当指纹更改时，请清除缓存。

响应式图片如何融入其中？

响应式图片告诉浏览器为当前视口下载哪个变体，这样手机就不会获取桌面英雄图。srcset 和 sizes 属性是实现此功能的原生、无需依赖的方法。

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hero image of a laptop browser loading a website">

浏览器会选择仍然能填满插槽的最小变体，以匹配设备的像素比。对于通常是 640w 文件的手机来说，这只占了 1920w 文件四分之一的字节数。为 LCP 图片添加 fetchpriority="high"，可以确保浏览器在早期加载时优先处理它。

如何衡量图片的影响？

你无法改进未衡量的东西。有两个工具能很好地覆盖图像特定的工作。

• PageSpeed Insights — 在 pagespeed.web.dev 上运行。它报告来自真实用户的字段数据，并直接标记了过大的图片和缺失的下一代格式。
• Lighthouse — PageSpeed Insights 背后的实验室审计工具。Chrome 在 Lighthouse developer guide 中记录了其图像检查。它会指出浪费字节的具体图片。
• Chrome DevTools Network tab — 按 Img 筛选，按大小排序，并注意主要的“罪犯”。这是我找到需要首先修复的一两个图片的依据。
• WebPageTest — 一个瀑布图和电影条带，精确显示了每张图片何时下载以及它如何移动布局。

当实验室数据和现场数据不一致时，相信现场数据。在一个快速机器上的 Wi-Fi 下获得干净的实验室分数意义不大，如果真实的 4G 手机用户仍然需要等待的话。由于图片在大多数页面上驱动着 Largest Contentful Paint，因此图像优化也是 Core Web Vitals 的工作——optimizing images for Core Web Vitals 指南将两者联系起来了。

我应该避免什么？

• 追求完美分数，而不是用户体验。 如果现场 LCP 仍然是 4 秒，那么实验室的 100 分毫无价值。
• 过度压缩。 过度降低质量可以节省字节，但会毁掉产品照片。请在真实图像上进行测试，而不是样本图。
• 忽略移动端。 大部分流量和大部分缓慢加载都是来自手机。优化目标应该是中端 4G 手机，而不是你的开发笔记本电脑。
• 一次性优化。 随着新图片和功能的发布，性能会衰退。每次发布后都要重新测试。
• 为每种设备生成一张巨大的图片。 没有 srcset，手机就会下载桌面英雄图。

关键要点

由于图片占据了页面重量的最大份额，它是影响网站速度的最大的杠杆。这四个修复方法——在显示尺寸使用现代格式、压缩、lazy-loading 和 CDN——虽然不那么光鲜亮丽，但它们将我的客户网站从 3.4 MB 和 4.8 秒 LCP 带到了 690 KB 和 1.9 秒 LCP。请按照这个顺序执行它们，测量每一步的成果，并首先修复最大的图片。

一个诚实的提醒：上面精确的字节和秒数来自一个客户网站，而你的数据将因内容、流量和 CDN 而有所不同。在优化前和之后，请在自己的 URL 上运行 PageSpeed Insights，让真实用户的现场数据——而不是整洁的实验室分数——来判断是否成功。

图片鸣谢

• Modern computer monitor displaying web design work in a creative workspace — photo by Tranmautritam on Pexels
• Close-up of a laptop screen showing a search engine page loading — photo by cottonbro studio on Pexels
• Developer typing code on a laptop in a focused workspace — photo by olia danilevich on Pexels