此页面由 Cloud Translation API 翻译。

常见问题解答

什么是 WebP？为什么我应该使用它？

WebP 是一种有损和无损压缩的方法，可用于网络上发现的各种摄影、半透明和图形图像。有损压缩的程度是可以调整的，以便用户可以在文件大小和图片质量之间进行权衡。WebP 的压缩率通常比 JPEG 和 JPEG 2000 高出 30%，并且不会降低图片质量（请参阅对比研究）。

WebP 格式主要是为了创建尺寸更小、更美观的图片，帮助提升网页加载速度。

哪些网络浏览器原生支持 WebP？

希望提高网站性能的网站站长可以轻松为当前图片创建经过优化的 WebP 替代方案，并有针对性地将其投放到支持 WebP 的浏览器。

WebP 有损支持
- Google Chrome（桌面设备）17 及更高版本
- Android 版 Google Chrome 版本 25+
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- Opera 11.10 及更高版本
- 原生网络浏览器，Android 4.0 及更高版本 (ICS)
WebP 有损、无损和 alpha 支持
- Google Chrome（桌面版）23+
- Android 版 Google Chrome 版本 25+
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- Opera 12.10 及更高版本
- 原生网络浏览器，Android 4.2 及更高版本 (JB-MR1)
- 淡月 26 岁以上
支持 WebP 动画
- Google Chrome（桌面版和 Android 版）32 及更高版本
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- 歌剧 19+

另请参阅 Wikipedia WebP 文章。

如何检测 WebP 的浏览器支持情况？

您可能只想将 WebP 图片投放给能够正确显示的图片，并回退到不支持的格式。幸运的是，有几种技术可用于检测 WebP 支持（客户端和服务器端）。某些 CDN 提供商在其服务中提供 WebP 支持检测。

通过 Accept 标头进行服务器端内容协商

Web 客户端通常会发送“接受”请求标头，以表明他们愿意接受哪些内容格式作为响应。如果浏览器事先表示它会“接受”图片/webp 格式，则网络服务器知道它可以安全地发送 WebP 图片，从而大大简化内容协商。如需了解详情，请访问以下链接。

现代主义者

Modernizr 是一个 JavaScript 库，用于在网络浏览器中方便地检测 HTML5 和 CSS3 功能支持。查找 Modernizr.webp、Modernizr.webp.lossless、Modernizr.webp.alpha 和 Modernizr.webp.animation 属性。

HTML5 `<picture>` 元素

HTML5 支持 <picture> 元素，可让您按优先级顺序列出多个备选图片目标，以便客户端能够请求可以正确显示的第一个候选图片。请参阅 HTML5 Rocks 相关讨论。<picture> 元素始终受更多浏览器支持。

使用您自己的 JavaScript

另一种检测方法是尝试解码使用特定功能的非常小的 WebP 图片，并检查是否成功。示例：

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

请注意，图片加载是非阻塞和异步的。这意味着，最好将依赖于 WebP 支持的所有代码都加入回调函数中。

Google 为什么要以开放源代码的形式发布 WebP？

我们坚信开源模型的重要性。借助开源的 WebP，任何人都可以处理该格式并提出改进建议。根据您提供的意见和建议，我们相信 WebP 会随着图形格式逐渐成为更加有用的工具。

如何将我的个人图片文件转换为 WebP 格式？

您可以使用 WebP 命令行实用程序将个人图片文件转换为 WebP 格式。如需了解详情，请参阅使用 WebP。

如果您要转换许多映像，可以使用平台的 shell 来简化操作。例如，如需转换文件夹中的所有 jpeg 文件，请尝试以下操作：

Windows：

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS：

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

我该如何评判自己的 WebP 图片质量？

目前，您可以查看 WebP 文件，方法是将其转换为使用无损压缩的常见格式（如 PNG），然后在任何浏览器或图片查看器中查看 PNG 文件。如需快速了解 WebP 质量，请参阅此网站上的图库，获取并排的照片对比。

如何获取源代码？

转换器代码位于 WebP 开源项目页面的下载部分中。该轻量级解码器和 VP8 规范的代码位于 WebM 网站上。如需了解容器规范，请参阅 RIFF 容器页面。

WebP 图片的大小上限是多少？

WebP 与 VP8 兼容，并采用 14 位的宽度和高度。 WebP 图片的最大像素尺寸为 16383 x 16383。

WebP 格式支持哪些颜色空间？

与 VP8 比特流一致，有损 WebP 专门与 8 位 Y'CbCr 4:2:0（通常称为 YUV420）映像格式兼容。如需了解详情，请参阅 RFC 6386 中的第 2 部分“格式概览”和 VP8 数据格式和解码指南。

无损 WebP 仅支持 RGBA 格式。请参阅 WebP 无损比特流规范。

WebP 图片能否大于其源图片？

是，通常在从有损格式转换为 WebP 无损格式时，反之亦然。这主要是因为色差（YUV420 与 ARGB）以及它们之间的转换。

典型的情形有以下三种：

如果源图片采用无损 ARGB 格式，则 YUV420 的空间降采样将引入比原始颜色更难压缩的新颜色。如果来源采用的是 PNG 格式，且颜色较少，则通常会发生这种情况：转换为有损 WebP（或类似于有损 JPEG）可能会使文件变大。
如果源文件是有损格式，使用无损 WebP 压缩来捕获来源的有损性质通常会使文件变大。这并非 WebP 中的问题，例如，在将 JPEG 来源转换为无损 WebP 或 PNG 格式时，可能会发生这种情况。
如果源文件采用有损格式，并且您正尝试将其压缩为采用较高质量设置的有损 WebP，例如，如果尝试将质量为 80 的 JPEG 文件转换为质量为 95 的 WebP 文件，通常会导致文件较大，即使这两种格式都有损耗。评估来源质量通常是不可能的，因此如果文件大小始终较大，建议降低目标 WebP 质量。另一种可能的方法是避免使用质量设置，而应使用 cwebp 工具中的 -size 选项或等效的 API 定位给定的文件大小。例如，如果以原始文件大小的 80% 为目标，可能更可靠。

请注意，将 JPEG 来源转换为有损 WebP，或将 PNG 来源转换为无损 WebP，不容易出现这种文件大小意外的问题。

WebP 是否支持渐进式或隔行显示？

WebP 不提供 JPEG 或 PNG 格式的渐进式或交错解码刷新。这可能会给解码客户端的 CPU 和内存带来过大的压力，因为每次刷新事件都需要经过一次完全解压缩系统。

平均而言，解码逐行 JPEG 图像相当于解码基准 3 次。

或者，WebP 提供增量解码，即所有可用的比特流传入字节都尝试尽快生成可显示的样本行。这既节省了客户端的内存、CPU 和重绘工作，又提供了有关下载状态的视觉提示。增量解码功能可通过高级解码 API 获得。

如何在我的 Android 项目中使用 libwebp Java 绑定？

WebP 支持 JNI 与 swig/ 目录中的简单编码器和解码器接口的绑定。

在 Eclipse 中构建库：

确保随 NDK 工具一起安装 ADT 插件，并且 NDK 路径已正确设置（偏好设置 > Android > NDK）。
创建一个新项目：File > New > Project > Android Application Project。
将 libwebp 克隆或解压缩到新项目中名为 jni 的文件夹。
将 swig/libwebp_java_wrap.c 添加到 LOCAL_SRC_FILES 列表。
右键点击新项目，然后依次选择 Android Tools 和 Add Native Support ...，以将库添加到您的 build 中。
打开项目属性，然后转到 C/C++ Build > Behaviour。将 ENABLE_SHARED=1 添加到 Build (Incremental build) 部分，以将 libwebp 构建为共享库。

注意：设置 NDK_TOOLCHAIN_VERSION=4.8 通常可以提高 32 位 build 的性能。
将 swig/libwebp.jar 添加到 libs/ 项目文件夹中。
构建您的项目。这将创建 libs/<target-arch>/libwebp.so。
在运行时使用 System.loadLibrary("webp") 加载库。

请注意，您可以使用 ndk-build 和随附的 Android.mk 手动构建该库。在这种情况下，您可以重复使用上述的某些步骤。

如何将 libwebp 与 C# 搭配使用？

可将 WebP 构建为导出 libwebp API 的 DLL。随后可以使用 C# 导入这些函数。

构建 libwebp.dll。这会正确设置 WEBP_EXTERN 以导出 API 函数。
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

将 libwebp.dll 添加到您的项目中，并导入所需的函数。请注意，如果您使用简单的 API，则应调用 WebPFree() 以释放返回的所有缓冲区。

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

为什么要使用动画 WebP？

与动画 GIF 相比，WebP 的优势

WebP 支持具有 8 位 Alpha 通道的 24 位 RGB 颜色，而 GIF 只有 8 位颜色和 1 位 Alpha 通道。
WebP 既支持有损压缩，也支持无损压缩；事实上，单个动画可以结合使用有损和无损帧。GIF 仅支持无损压缩。WebP' 有损压缩技术非常适合基于真实视频创建的动画图像，这种视频越来越受欢迎。
WebP 需要的字节数少于 GIF¹。转换为有损 WebP 的动画 GIF 小 64%，而无损 WebP 小 19%。这在移动网络上尤为重要。
有跳转时，WebP 可以缩短解码时间。在 Blink 中，滚动或更改标签页可以隐藏和显示图片，导致动画暂停，然后跳到不同的点。如果 CPU 使用率过高导致动画丢帧，可能还要求解码器在动画中前进。在这些情况下，动画 WebP 的总解码时间是 GIF 的 0.57 倍²，因此可减少滚动过程中的卡顿现象并加快 CPU 利用率峰值的恢复速度。这是因为 WebP 比 GIF 具有两个优势：
- WebP 图片会存储有关每个帧是否包含 Alpha 值的元数据，这样就无需解码帧即可做出判定。这样可以更准确地推断指定帧所依赖的前一帧，从而减少对前帧的不必要解码。
- 与现代视频编码器非常相似，WebP 编码器以启发方式定期添加关键帧（大多数 GIF 编码器都没有这样做）。这显著改善了长动画中的跳转效果。为了方便插入此类帧而不显著增加图片大小，除了 GIF 使用的帧处理方法之外，WebP 还为每个帧添加了'混合方法标志。这样一来，关键帧便可以像整个图片已被清空为背景颜色一样绘制，而不会强制上一帧完全尺寸。

动画 WebP 与动画 GIF 的缺点

在缺少跳转的情况下，WebP 的直线解码比 GIF 更需要 CPU 密集型处理。有损 WebP 所用的解码时间是 GIF 的 2.2 倍，而无损 WebP 的解码时间是 GIF 的 1.5 倍。
WebP 支持并不像 GIF 支持那么普遍，后者实际上是通用的。
为浏览器添加 WebP 支持会增加代码占用空间和攻击面。在 Blink 中，大约还需要 1500 行代码（包括 WebP 多路分配库和 Blink 端 WebP 图像解码器）。请注意，如果 WebP 和 WebM 共用更常见的解码代码，或者如果 WebP 的功能在 WebM 中使用，则将来可能会减少此问题。

为何不直接在 <img> 中支持 WebM？

从长远来看，支持 <img> 标记内的视频格式可能是有意义的。不过，为了同时让 <img> 中的 WebM 填充动画 WebP 的提议角色，这样做现在会出现问题：

在解码依赖于上一帧的帧时，WebM 需要比动画 WebP 多出 50% 的内存才能保留最低数量的上一帧³。
视频编解码器和容器支持因浏览器和设备而异。为方便内容自动转码（例如，为了节省带宽的代理），浏览器需要添加接受标头，以指明其图片代码支持的格式。甚至可能不够，因为“video/webm”或“video/mpeg”等 MIME 类型仍然不支持编解码器（例如 VP8 与 VP9）。另一方面，WebP 格式实际上已冻结，如果发布该格式的供应商同意提供动画 WebP，则所有 UA 中的 WebP 行为应保持一致；由于“image/webp”accept 标头已用于表明支持 WebP，因此无需更改新的“accept”标头。
Chromium 视频堆栈针对流畅播放进行了优化，并假设一次仅播放一两个视频。因此，该实现会积极消耗系统资源（线程、内存等），以最大限度地提高播放质量。此类实现并不能很好地扩展到多个同步视频，因此需要重新设计，以便与包含大量图片的网页配合使用。
WebM 目前并未采用 WebP 的所有压缩技术。因此，与替代方案相比，此图片在 WebP 压缩方面的性能明显提高：

¹ 对于 GIF 动画与 WebP 之间的所有比较，我们使用语料库中包含约 7000 张从网络中随机选取的 GIF 动画图片。这些图片已通过 'gif2webp' 工具（使用最新的 libwebp 源代码树，于 2013 年 10 月 8 日构建）而转换为动画 WebP。比较数字是这些图像的平均值。

² 截至 2013 年 10 月 8 日，使用最新 libwebp + ToT Blink 通过基准工具计算解码时间。“使用还原功能解码时间”的计算方法是：“解码前五帧，清除帧缓冲区缓存，解码接下来的 5 帧，依此类推”。

³ WebM 在内存中保留 4 个 YUV 参考帧，每个帧存储（宽度 + 96）*（高度 + 96）像素。对于 YUV 4:2:0，我们需要每 6 像素 4 字节（或每像素 3/2 字节）。因此，这些参考帧使用 4*3/2*(width+96)*(height+96) 字节的内存。另一方面，WebP 只需要上一帧（采用 RGBA），即 4*width*height 字节的内存。

⁴ 动画 WebP 渲染需要 Google Chrome 版本 32 及更高版本