早在2021年，我在伯明翰有一个WooCommerce客户，一家家居用品店，约有4000张产品照片，全是用佳能单反相机拍摄的超大JPEG文件，上传时没有任何处理。他们的最大内容绘制时间是7.2秒。太糟糕了。我用Squoosh CLI把所有照片转换成WebP，重新运行Lighthouse，在一个下午就把LCP降到了2.8秒。客户哭了。真的。Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
但问题是：同样的技巧对我第二个月合作的另一个客户帮助不大。那是一个新闻摄影作品集网站，色彩保真度和打印级导出实际上很重要。在那里WebP是个错误的选择。我改用JPEG和激进的Lightroom导出设置，由于图像已经适当调整大小，性能差异微乎其微。
所以让我们好好讨论这个问题。不是"WebP总是更好"，也不是"JPEG之所以经典是有原因的"。真正的答案比任何一方承认的都要复杂得多。
---
底层实际有什么区别
JPEG 自 1992 年以来就已存在。它使用离散余弦变换压缩，对照片来说效果很好，但在高压缩比下会开始出现问题，因为它会引入那些熟悉的块状伪影。大多数网页开发者都知道这一点。
WebP 由 Google 在 2010 年发布，使用的是借鉴自 VP8 视频编码器的预测编码模型。简单来说：它对像素之间的空间关系建模更聪明，这意味着它可以在更少字节中保留更多品质。根据 Google 自己的研究，WebP 无损图像比 PNG 小 26%，有损 WebP 比同等品质的 JPEG 小 25-34%。Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
这些数字在实际中基本能成立。
差距真正显现的地方
25-34% 的节省往往出现在具有光滑渐变的自然照片、白色背景上的产品照片和生活方式类图像上。在高频细节上差距会大幅缩小：紧密的织物纹理、密集的叶片、有大量重复的建筑图案。我用 ImageMagick 进行过许多次并排比较测试。在某些高度细节化的照片上，尺寸差异会降低到 10% 以下，有时在相同品质设置下 WebP 甚至会输。ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
2026 年的浏览器支持：这还是个问题吗？
说实话，浏览器支持是 2018 年坚持使用 JPEG 的真正理由。Internet Explorer。Safari 采用缓慢。所有这些。
都过去了。Can I Use 现在将全球 WebP 支持率列在 97% 以上。Safari 在 2020 年的第 14 版本中添加了完整支持。IE 已经死了。2026 年没有任何有意义的受众群体无法接收 WebP 图像。Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.
我仍然遇到的唯一边界情况是：如果你将图像作为电子邮件附件提供或将其嵌入到服务器端生成的 PDF 导出中，一些较早的渲染管道对 WebP 会出问题。仅此而已。对于所有浏览器交付的内容，支持方面的论证已经结束了。
---
Core Web Vitals：图像格式选择真正能够改变结果的地方
LCP（最大内容绘制）是受图像格式影响最直接的Core Web Vitals指标。它衡量最大可见元素加载所需的时间。如果该元素是图像（在营销和电商网站上通常都是），那么格式、大小和交付方法都至关重要。
以下是我看到格式选择产生真正差异的实际情况分解：
- 英雄图像：这几乎总是LCP元素。如果你的英雄图是1920px宽的1.2MB JPEG，以质量82转换为WebP通常会将其压缩到380-450KB，而不会有明显的质量损失。 These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- 产品图像网格：许多小图像同时加载。WebP持续25%以上的节省在这里会产生复合效应。更快的网格=移动设备上总的阻塞时间更低。 Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
- 博客文章内嵌图像：影响真正很小。200KB的JPEG与3000字文章中段落中的140KB WebP不会改变你的LCP。 Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- 图标和徽标：都不会。使用SVG。我每次都得说这个。 Neither. Use SVG. I have to say this every single time.
- 归档页面中的缩略图：WebP在这里赢出来，特别是当你在网格中加载20-30个缩略图时。那是字节节省快速堆积的地方。 WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
Seahawk去年有一个金融科技项目，营销网站的英雄轮播中有14张折叠上方的图像旋转。疯狂，但客户坚持。将所有14张从JPEG以质量80转换为WebP并通过Cloudflare CDN提供，使他们的移动设备LCP从4.1秒下降到2.3秒。轮播仍然是个糟糕的想法，但至少加载得很快。
---
AVIF 的问题
每次我写关于 WebP 的文章，总有人问起 AVIF。这很合理。
AVIF 是下一步。它基于 AV1 视频编解码器，产生的文件比 WebP 更小（通常在照片上小 20-30%），并能正确处理 HDR 内容。Chrome、Firefox 和 Safari 的浏览器支持现在已经很完善了。问题在于编码速度。AVIF 的编码速度很慢，慢得很明显。在 VPS 上批量转换 4,000 张产品图像为 AVIF 需要花很长时间。WebP 生成速度要快得多。Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
我目前的想法是：使用 WebP 作为你的默认交付格式。如果你在构建一个高流量网站，额外的 AVIF 压缩收益足以抵消编码开销，那就为支持 AVIF 的浏览器提供 AVIF，并使用 WebP 作为后备。使用 <picture> 元素和 <source type="image/avif"> 可以实现这一点，无需任何 JavaScript。<picture> element with <source type="image/avif"> handles this without any JavaScript.
不要因为 AVIF 优柔寡断而停留在 JPEG。WebP 现在是正确的务实默认选择。
---
我选择格式的实际工作流程
经过 9 年和 12,000 多个网站的经历，这大致是我的思考方式：
- 这是照片还是照片级图像？从 WebP 有损压缩质量 80-85 开始。与质量 75 的 JPEG 比较。选择通过眯眼测试的较小文件。 Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- 这是带平面色彩的图形、徽标或插图吗？如果可能，用 SVG，否则用 PNG。WebP 无损是一个选项，但很少是最佳选择。 SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- 这是包含文字的截图吗？PNG。总是 PNG。JPEG 和 WebP 都会在文字边缘引入看起来很糟糕的伪影。 PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- 它是通过能自动进行格式协商的现代 CDN 提供的吗？如果你使用启用了 Polish 的 Cloudflare，或使用 Cloudinary，或 Imgix，那么老实说你不用担心太多。它们会检测浏览器并提供最优格式。让工具来处理。 If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- 这是 WordPress 网站吗？安装 ShortPixel 或 Imagify，并将它们配置为在上传时转换。完成。你根本不需要手动管理这个。 Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
关于质量设置的说明
质量 80 不等于质量 60。我看到开发者把 WebP 质量设置为 60，因为"它仍然比 JPEG 好"，然后想知道为什么客户抱怨产品照片看起来浑浊。做好你的视觉质量检查。我用浏览器中的 Squoosh 运行每一个格式决策，用分割视图工具在原图和输出之间切换。每种图像类型花 3 分钟，能省去与客户的争论。
---
JPEG 仍然是正确答案的情况
我直言不讳，因为我看不到足够多的人这样说：JPEG 并未过时。
如果你要建立一个网站，其中图像会被下载并重新编辑（摄影作品集、库存图像、新闻资产库），JPEG 仍然是合理的。它在地球上每个图像编辑应用中都得到通用支持。Photoshop 等工具中的 WebP 导出质量已大幅改进，但围绕 JPEG 的后期处理工作流的生态系统根本上更加成熟。
另外，如果你的图像已经是优化得很好的 JPEG（比如 800 像素宽的图像在 100KB 以下），转换为 WebP 只能节省大约 15-20KB。这不是零，但如果你手工进行转换，就不值得花费工程时间。选择你的战役。
如果你要打印的话。显而易见。WebP 是网络格式。不要将它用于任何最终会出现在纸张上的东西。
---
值得了解的实用工具
这些是我实际使用的工具，不是一个冗长的列表：
- [Squoosh](https://squoosh.app/)：基于浏览器，无需安装，非常适合一次性比较和在自动化任何东西之前找到合适的质量设置。 Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI：从终端进行批量转换。我在项目级迁移中使用这个。 Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel：WordPress 插件中最好的自动转换上传工具。有损设置开箱即用就很合理。 Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish：如果你已经在使用 Cloudflare Pro，打开这个功能。它自动在边缘进行转换和压缩。无需代码。 If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- Cloudinary：适合更大的编辑或电商运营，你需要格式协商、响应式尺寸调整和 CDN 交付作为托管服务。 The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- ImageMagick：用于服务器端工作流的命令行转换工具。比 Squoosh CLI 慢，但对于脚本化管道更灵活。 Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
常见问题
WebP 总是比 JPEG 更小吗？
不是。我希望人们停止这样说。对于高度详细、高频率的图像（想象一下：粗糙纹理的微距摄影、细节密集的建筑拍摄），尺寸差异可能微不足道，甚至可能根据编码器设置而反向。应该测试你的特定图像，而不是假设。
如果转换为 WebP，我需要保留原始 JPEG 吗？
需要。始终保留原始文件。WebP 是传输格式，不是存档格式。如果你运行的是带有 ShortPixel 的 WordPress 站点，插件默认会保留原始文件。不要改变该设置。
转换为 WebP 会伤害我的图像 SEO 吗？
不会。Google 对 WebP 图像进行索引没有任何问题。确保你的 alt 文本具有描述性，文件名合理即可。格式对图像搜索排名没有影响。
关于 `<picture>` 元素与直接提供 WebP 相比如何？
如果 97% 以上的用户支持 WebP，直接通过 <img> 标签提供 WebP 就可以了。当 Safari 是唯一不支持的浏览器时，<picture> 元素和源回退才有意义。现在它主要用于我之前提到的 AVIF 加 WebP 回退的模式。<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
图像格式会影响 CLS（累积布局偏移）吗？
格式本身不会。但如果你在转换图像时没有设置明确的宽度和高度属性（或在 CSS 中使用 aspect-ratio），无论什么格式都会产生布局偏移。这是我看到人们进行批量格式迁移时最常见的错误之一。修复你的尺寸。width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
格式决策看起来很小。其实不是。我看到过单个下午的图像优化就能把一个网站从"Core Web Vitals 不达标"变成"达标"，并为电商客户的转化率带来实质性的提升。在 2026 年，WebP 对于几乎所有浏览器交付的照片来说都是正确的默认格式。但它是一个默认值，不是规则。要知道你为什么做这个选择，在自动化前进行测试，并保留你的原始文件。