动画PNG与动画Webp与GIF

从Chrome 59开始，Chrome现在支持Animated PNG，我们有两种图像格式可以替代旧的GIF格式。关于何时使用APNG和动画Webp，不同的帖子和网站有不同的结论。在我的所有发现中（每次链接在下面，Gif的来源都在其中），动画webp每次都在文件大小上击败apng。有时不是很多。这当然是轶事，我对apng的了解不如创作者和其他创作者那么熟悉，因此他们可能比我更能挤出apng。

我听到并阅读过的所有内容都表示，APNG可能更大，但webp在浏览器中解码所需的时间更长。假设较大的APNG将比较小的Webp加载更快。是这样吗？我假设较小的Webp更快地下载到客户端，然后它将开始更快地解码。因此动画速度更快。因此，让我们实际测试一下，而不是让我吐出来哈哈。转到源GIF。

我在这篇文章中使用的GIF来自我关于将MP4转换为Webm的文章。那是一个1080p视频，缩减到大约5秒钟，并调整为800的宽度。

在我们甚至还不准备踏上这趟旅程之前，我们必须将上面的GIF转换为APNG和Animated Webp。也许您可以将此页面上的GIF转换为APNG并获得更好的结果。请尝试我不希望解雇APNG的次数，我认为我可能会退出。

Gif2apng提供了三种将GIF转换为动画PNG的选项。我们有zlib，7zip和Zopfli压缩。除zlib外，每个压缩选项都允许您设置默认为15的迭代量。

我使用gif2apng版本1.9 [1] [2]。对于7zip和zopfli，我将使用＆＃34; default＆＃34;迭代15和更积极的版本100。如果要执行此操作，请警告。根据您的服务器规格或本地计算机上的规格，Zopfli将花费很长时间。增加任何一种压缩算法的迭代次数也会增加将图像转换为APNG所花费的时间。如果您在计算机上进行此操作，请准备好留出很大一部分时间：)。

将GIF转换为动画PNG之后，我还将通过APNGOPT运行它。这应该＆＃34;优化＆＃34;动画PNG。这也提供了不同数量的迭代。我将使用默认的＆＃34;对于使用上述默认值转换的每个apng，其值为15，对于所有100次迭代，其值为100。

我们可以看到，在通过apngopt运行它们之前，Zopfli压缩会节省最多的时间。不过，它占用大量的CPU资源。在通过apngopt运行这些命令后，事​​情没有太大变化或根本没有变化。

在Windows计算机上，只需使用它们从sourceforge打包的GUI。它似乎是最新的。我还没有时间查看GUI和CLI是否有所不同，除非您对GUI的输出感到满意，然后继续进行操作，否则将由您自己决定！

如果您通过操作系统的程序包管理器（即apt-get / apt）安装gif2apng（取决于操作系统），则可能会获得1.7版。

如果再次使用apngopt的CLI版本，则取决于您的操作系统，您将获得1.1到1.4的版本。

使用三个不同的选项和WebP编码器版本：0.6.0（WebP Mux版本：0.4.0）将相同的参考gif转换为webp。

我没有深入研究gif2webp可用的不同CLI选项。这样的东西具有-kmin，-kmax（它们指定连续关键帧之间的最小和最大距离，并可以提高解码性能），或者从文档建议50中调整去块滤波器-f。通过调整和调整，这些可能会变小或变小实例更大的文件。您必须对这些图像进行测试以查看特定的图像，或者使用默认设置，例如我的图像。

默认情况下，Webp击败了每个转换后的APNG，Webp的频率为30.86MB，相比之下，使用默认APNG设置（zlib）的Webp为33.01MB，使用zopfli压缩的30.87MB @ 100次迭代。

好的，很酷，所有文件大小都无法使用。当它们如此接近时，几kb / mb是否重要？默认的webp设置使用apngout和zopfli @ 100次迭代为我们提供了与apng相同大小的文件。

是的。实际上，较大的apng解码速度会更快。但这有关系吗？有点儿。

通常，在这种情况下，我会使用Webpagetest的视觉比较选项，这样我们就可以看到页面并排加载。我先进行了桌面测试，然后使用新兴市场进行了移动测试。设置。我目前无法执行此操作，因为如上所述，Chrome 59+支持APNG。视觉比较工具使用的是Chrome的当前稳定版本（在我测试这些版本时恰好进行了更新。仍然要确保我使用的是Canary版本）。大多数使用非dev / beta版本的Chrome的人都使用什么。

因此，我正在Chrome Canary上运行这些测试，并将使用第一个视图的中位数作为比较。我将使用电缆连接（5Mbps 28ms延迟）在Chrome桌面上运行三（3）次每个图像选项/类型，并使用第四代Moto G及其移动3g运行三遍。连接— 768 Kbps 3G连接，延迟为300毫秒。

我运行的第一个比较是gif2webp的默认设置。如上所述，此参数默认为质量75，压缩模式为4，并且像APNG一样是无损的。您可以下载这些动画图像并自己运行。您将看到哪一个实际上加载得更快，甚至不必阅读哈哈。

实际上，默认情况下，Webp的文件大小可能比APNG小（对于此特定动画）。这实际上有助于我们减少网络中的字节发送量，但是就所有页面加载性能而言，您可以在下面看到它并没有太大帮助，或者根本没有帮助。

这些是大文件。如果您将这些巨大的麻烦事通过电话发送给他们，则会给您自己和您的用户造成伤害。

Webp的默认设置将帮助您建立速度较慢的3g连接，因为它发送的数据较少。 APNG由于解码速度更快，因此可以更快地将帧发送到屏幕，因此下面的速度指数更好。

因此，我认为请勿在慢速连接上使用APNG或Webp默认值。他们是大文件。

那么，有没有比gif大小小的文件大小的解决方案，实际上可以提高您的页面性能？是的，如果您不介意可能的有损压缩图像。

我们可以获取使用默认值，混合压缩（有损和无损），有损转换后的webp以及有损压缩和过滤后的webp图像转换后的Webp图像，并将其与“最佳”图像进行比较。文件大小明智的APNG和未优化的GIF。

在向您展示这些之前，这里是台式机上运行的那些数字。

最让我惊讶的是，默认设置的动画Webp以及未优化的gif页面加载时间和速度索引的接近程度。

由于存在有损压缩，因此与APNG的比较不是公平的。加载时间也存在很大差异。就像您在现实世界中遇到的情况一样。因此，将这些结果与一粒盐放在一起即可。我并没有付出太多努力来使它们全部自由变量。

借助这种动画Webp，您将获得最大收益的地方是缓慢的3g连接。

动画的webp在3g上的加载速度更快，因为发送的数据较少。 APNG的解码速度更快一些，而GIF恰好不好。我没有包括的是CPU繁忙时间，但是您可以在＆＃34; First Interactive＆＃34;中了解一下数字。这是Webpagetest所说的“首次互动”是：

报告何时首先预期页面可用，并将快速响应输入（随着更多内容加载，响应速度可能很慢）。

都不是。不完全是。好吧，我通常应该说，这取决于您的浏览器支持以及您所使用的源格式，您不应该使用其中的任何一种（动画化的Webp，动画png或GIF）。

如果您可以控制来源。这意味着您拥有希望用作短动画的实际视频，然后再使用短视频。正如我在另一篇文章“将MP4转换为Webm”中所显示的那样，这些视频格式可能要小得多。例如，这些相同的动画图像与其对应的MP4和webm相比要小得多。

在我看来，通过WPT运行这些短视频为我们提供了一个明确的答案，即为什么您应该将这些视频格式用于短gif（例如动画）而不是本文中的其他格式。

现在，这是一个非常特殊的＆＃34; test＆＃34;一种动画。与实际大小相比，某些图像和视频的文件大小会有很大差异。对于像使用响应图像的实例。如果我们在srcset或picture元素（希望您应该使用响应式image元素或属性）中使用了三个图像，它们的尺寸如下：1：

使用默认设置将GIF转换为Animated Webp和Animated PNG。 Webp动画的默认设置已在上面介绍。 gif2apng的PNG动画默认值为

然后，通常不会将800px宽的webp / apng发送给移动用户。因此页面加载时间和其余指标会更好。例如，以下是400像素宽的动画图像网页测试结果：

这些较小的图像加载速度更快。仍不及800px宽的MP4或WebM快。

Gyfcat（webm或MP4）和Imgur（gifv）为他们的＆＃34; GIFS＆＃39;提供视频是有原因的。它们更快，通常更小。最终用户还可以阻止这些播放器播放，这可能会阻止低功率机器风扇旋转：)或让他们实际使用该页面。

使用视频格式！如果您的浏览器支持允许它，然后考虑APNG，然后再考虑是否必须使用GIF，请考虑一下webp。您可以使用服务器和内容协商，如我在这篇文章中概述的那样：如果您无权访问服务器配置或htaccess文件，则可以同时为Nginx和Apache使用带有Nginx的Webp，JXR图像和Nginx，也可以使用picture元素和类型切换。