原文地址：Guide To Using WebP Images Today: A Case Study

俗话说一图胜千言，但在网上，一图却可以抵过上千字节甚至更多。HTTP 文档表明图片平均占整个网页的64%，基于此，图片的压缩是非常关键的，尤其当用户因为你的页面加载过慢时而关闭它。

图片压缩的主要问题是保证图片大小的情况下而不牺牲图片质量，相对于JPEG, PNG 和 GIF这些标准格式，在过去通过尝试创建新类型文件去压缩图片并不是太成功。

开始 WebP

WebP 是在2010创建并且现在由Google开发的一种图片格式，它提供了图片的无损和有损压缩。一些大的公司都有使用WebP，显著地有Google, Facebook 和 eBay。

在我们公司，一直尝试使用技术提升网站性能。因此，我们做了一些 A/B 测试去弄明白WebP对图片的影响，以及它如何才能更好的应用在我们客户的项目中。

“较小的文件尺寸”是我们开始使用 WebP 的一个主要原因，根据 Google 介绍：

  • WebP 无损图片文件比 PNG 格式的小26%
  • 在同等结构指标下，WebP 有损图片文件比 JPEG 格式的小25% 到 34%
  • WebP 支持无损透明（也被称为Alpha通道），仅只需22%的字节

我们的测试揭露了 WebP 图片格式的利与弊：

利 弊
更小的文件尺寸 较差的浏览器支持
改良的压缩算法 不具有可塑的外观
平滑的颜色层次 较差的输出（导出）接口
Alpha通道的掩饰 -

图片质量

WebP 运用了一种新的压缩算法，相对于其他类型的文件，它并没有因为人工痕迹（比如变形或退化）而看上去不同。WebP 运用了一个很好的原理来保持图片清晰的边缘，但是，正如你所期望的有损文件，它丢失了细节和纹理。而相比 JPEG 文件在固定区域表现紧致的人工痕迹 ，WebP 拥有下降到最低质量设置的平滑划分。在低配置中的一个负面东西就是人脸可别塑造或色调分色的外观。

在 WebP 图片格式上，我们还有其他事情需要考虑，压缩设置和JPEG不是一比一匹配的，不要期望一个50%质量的JPEG和一个50%质量的 webP 相同。在 WebP 上质量会大幅度下降，因此以你的方式去开始高质量的压缩。

另一个颠覆性的好处是它能够增加一个alpha 通道的掩盖，很像PNG，不像它的无损副本，然而，你通常可以压缩一个可用的WebP图片，相对与它将近十分之一尺寸等效的PNG图。允许对主机的选项和功能，这对WebP是一个出色的应用，如果不这样，大尺寸的文件会让网站运行缓慢，一个实际的例子就是，880KB 的 PNG图（24位alpha通道），被压缩到41KB—节约了95%，虽然这95%不是标准，但它确实表明有这种可能。

为了进一步减小图片的大小，我们可以在图片编辑的保存对话框里，通过取消“保存元数据”的选项来省略元数据。甚至为了更进一步的压缩保存，我们可以选择“有损alpha通道”选项。alpha通道的质量设置反应在这些图片中。比如，一个50%质量图片将会有50%质量有损alpha通道。在我们的测试中，我们期望在遮罩边缘有人工痕迹，但它同时也是一个对整个图片值得注意的压缩改变。我们当然认为这是进一步缩小文件大小的选择，当这样做时我们会密切监控图像质量，同时，在差的网速下监视带有渐变消失的alpha通道。

我们很激动的发现一个 Photoshop 插件 可以支持WebP。这让设置WebP质量的量度变的很容易， 这个插件的界面遗留了一些待改进的东西—它还未被Adobe完全采纳，目前看来，你不能通过预览图片去决定质量的设置，这是很不爽的。

作为一个解决方案，Google的chrome浏览器允许文件做一个快速对比。在Photoshop中访问保存对话框同样也不方便。为了节约时间，我们建立了一套键盘快捷键，因此可以避免重复访问“保存”的下拉菜单。尽管有些警告，相当于那些繁琐的操作还是值得的。

在显著文件尺寸保存中，好的质量和alpha通道，在所有的图片格式当中，WebP像一个真正的赢家。当测试时，结果明朗化了，奇怪的是在不同图片格式中没有明显的赢家。通常情况是WebP比其他格式出色的多，但是JPEG和PNG8总是偶然的在尺寸或者质量，或者同时两者上战胜WebP。在使用WebP前，你应该做大量测试，因为它可能不是你想要的理想情况。

运用

一旦决定使用，WebP将会在我们工作中成为一个高效的工具，我们让开发者来测试执行。WebP 在 Chrome, Opera, Opera Mini浏览器里原生支持的，而安卓浏览器和安卓版chrome、Firefox、IE、Safari这些浏览器 是不原生支持，尽管Firefox在WebP方面有相当长的历史。幸运的是，针对不支持的浏览器有一些解决方案。

通过研究，我们发现支持WebP格式有三个可行的选项，我们想确保对于页面尺寸我们使用的是最佳选项，请牢记速度指数是一个关键的指标，并且要把需要的任何JavaScript polyfills考虑进去。

我们运行了四个测试来思考应该朝哪个方向进行。第一个测试我们使用普通的JPEG来作为控制量，而其他三个测试运用的选项如下。我们使用JPEG图片和同等质量的WebP图片（269KB 的JPEG 和52KB 的WebP），四个测试所有的可用结果在这个PDF中。

在第二个测试中，我们引用了 WebPJS，一个由Dominik Homberger开发、大小为67K的polyfill ，它使得WebP支持主流浏览器，甚至包含IE6。这个polyfill非常有用，因为它不要求你改变现有代码img元素的语法，只需要改变将.jpeg 或 .png后缀名改为.webp，polyfill 就能正常工作。

第三个方案是使用 Picturefill，这个polyfill让我们可以使用 <picture> 元素，即便它还不能原生支持。对于支持webP的浏览器，它同样允许开发者使用 <source> 元素，而对于不支持webP的浏览器，它将webP转换为JPEG, PNG或其他格式的图片（显然，<picture> 元素也有惊人的力量）。

第四个测试是将webP应用在服务器上.htaccess文件的代码里，这个选择就是由 Vincent Orback设计。使用此方案，.htaccess代码会查找页面中每个图片WebP 的版本号，如果发现浏览器支持WebP ，并且WebP图片可用，它丢弃JPEG或PNG而采用WebP图像。这对节约大量时间非常有用，因为你不用在代码中改变img的语法，也不用改变图片到.webp的扩展。

通过审查这些数据，我们认定运行在所有浏览器当中，WebP polyfill（测试二）是最轻量级的解决方案，但这个方案上在速度指标上并没有给我们很深的印象。除了在IOS以外，在图片下载上这个WebP polyfill表面看上去比JPEG控制量和其他测试应用更糟。

我们同样注意到了在iOS设备上，100KB大小的文件比在其他设备上大。在测试中，我们仍然注意到在iOS5.1 以及 IE8 和 IE9中，WebP 图片会被下载三次。因为两次额外的请求并不理想，它总是比同等的JPEG小。我们没有测试新版本的IOS版本，因此这个问题可能已解决。我们更倾向于最初的应用，因为它能更好的支持浏览器。

展望未来

我们团队已经决定采用之前测试中的方案三，对支持webP的浏览器，使用 <picture> 元素去服务WebP 图片，而对不支持的则应用JPEG 或 PNG，我们相信这对渐进增减和平稳退化是一种非常好的渠道。我们原本以为可以结合WebP polyfill来应用WebP，结果发现效果都不太理想。

WebP不会让JPEG 和 PNG这种图片格式过时，但对于增加你的技能它是一个很不错的工具，准备好迎接WebP，并在每个新的项目中做一些测试和比较吧！