WordPress首席开发者提出新的反对意见 WebP将在6.1版本中暂停

上周，Performance团队的贡献者们正在完善他们对multi-mime/WebP功能的后续补丁，此前该功能的主要工作已于7月底合并到6.1的核心部分。这包括一些较小的相关项目，如针对不支持的浏览器和增加PDF支持，这些都在单独的票据中处理。

为新上传的JPEG图片默认生成WebP图片的提议从一开始就有争议。虽然谷歌赞助的推动项目的贡献者在最初一轮重要的批评性反馈后做了一些修改，但其他贡献者继续表达他们说没有被考虑的担忧。一些贡献者报告了该功能的问题，并建议它应该从选择加入开始，这个想法在主要工作投入之前就被立即驳回了。

上周，WordPress的首席开发人员Andrew Ozz在该票据上提出了新的反对意见。

像@MatthiasReinholz, @eatingrules, 和其他人一样，我认为这种方法也许是缺乏的。为什么会有两倍的图片文件占用大量的额外空间，而其中有一半永远不会被用到任何地方？

我认为一个更好的方法是把所有图像的子尺寸变成WEBP。如果确实需要JPEG，这些可以根据需要即时生成。没有必要用所有这些无用的文件来堵塞网络服务器的存储。

另一方面，如果WEBP文件的大小实际上比JPEG大，这可能意味着需要更好的工具，而这个补丁还不成熟。

六周前，在回应一个关于 “转换的资源将是巨大的 “的抱怨时，谷歌赞助的核心提交人Adam Silverstein证实，在上传时生成图片的资源将 “大大增加”。

“然而为图像服务的资源会降低，”Silverstein说。”由于与图像服务相比，图像上传非常罕见，压缩和存储图像的额外努力应该是值得的。”

这是Ozz在反对这种方法时提到的另一个问题。

“实际上，上传图片时资源使用量的那种急剧增加在这里是一个非常糟糕的副作用，”Ozz说。”这意味着大量的上传会失败，并使用户陷入困境。这也会使WordPress和托管公司的支持请求急剧增加。不要认为这是可以接受的。正因为如此，即使WordPress中需要图像多媒体支持，目前的方法似乎也不是一个好的解决方案。”

大约24小时后，谷歌赞助的贡献者Felix Arntz评论说，WebP对旧浏览器的JPEG回退机制已经准备好提交了，他计划在几天内提交它。

“请不要在这里提交任何更多的代码，除非是为了解决上传后创建图像子尺寸所需的资源急剧增加的问题，”Ozz说。”正如我上面所说，这种增加是不可接受的。

“是否有任何数据表明，在上传不同尺寸的图片时，需要增加多少资源（内存、处理时间等）？有没有关于多少网站可能受此影响的估计？有任何关于如何处理的建议吗？你知道当上传图片的后期处理失败时会发生什么吗？

“坦率地说，目前看来，这个补丁必须被还原和重构，才能解决这个问题。”

亚当-西尔弗斯坦回应了他的担忧，澄清了他们为什么选择目前的方法，因为他们预计到了某些边缘情况，并最终在AVIF等格式得到更广泛的支持后增加对它的支持。

我倾向于同意你的评估，即所有的子尺寸都应该只生成WebP，这就是最初提案的形状。对于绝大多数的使用情况/用户来说，这将是最好的工作。我愿意考虑将其作为默认格式（有一些缓解措施，见下文）。

我们决定生成两种格式的原因是为了向后兼容的考虑，我们发现少数边缘情况下WebP图像可能无法工作：即电子邮件图像（一些旧的Outlook/windows客户端），Open Graph标签（一些服务不支持WebP）和旧的Safari浏览器。我们考虑的一种可能性是只保留全尺寸的JPEG图片，这样它就可以随时用于这些边缘情况。

这里的 “multi-mime “支持是为了生成多种格式，所以你的网站可以用类似图片元素的东西提供一个主要和后备格式。这对WebP来说不那么重要，因为它得到了广泛的支持，但对于通过插件或核心采用AVIF等较新的格式会有帮助。

西尔弗斯坦还说，即时生成图像的选项是他们需要弄清楚的，但 “感觉超出了这项工作的范围”。

对于有关图片上传资源急剧增加的投诉，Silverstein说他们正在依靠 “重试 “机制来缓解这个问题。

“这一变化也使WordPress重试’图像再生’的次数增加了一倍，所以虽然处理时间会增加，但我不认为我们一定会看到失败率的跳跃，”他说。”我知道我们过去在添加新的尺寸时遇到了麻烦，然而那是在我们添加重试机制之前。”

WebP默认项目背后的团队更专注于在前端提供更小的图片尺寸，并认为上传时的额外资源使用是对WordPress用户的必要牺牲。

“Silverstein说：”上传时的额外资源需要与服务较小的WebP图像所减少的资源进行权衡，特别是由于服务通常比上传的频率高几个数量级。

西尔弗斯坦说：”如果在所有的重试之后上传失败，用户就会有和现在一样的体验：他们只能看到一张破碎的、无法使用的图片。这可能是可以解决的，尽管我不认为这种改变会增加失败率”。

WordPress的首席开发者Dion Hulse也对报告WordPress照片目录中的WebP转换问题的票据发表了评论。

只是在这里注意到，这些额外的WebP转换似乎是最近几周WordPress照片目录上传失败的主要原因。请看#meta6142和与之重复的已关闭的门票。

这些错误通常是沿着允许256M字节的内存大小用尽（试图分配90M字节（显然有字节值），而试图执行最初的全尺寸原始jpeg->webp转换。

这并没有影响到每次上传，只是影响到某些图片的上传。可能与webp请求传递的$quality值有关（IIRC默认的82是针对jpeg的优化？）

由于这些错误，Hulse禁用了JPEG到WebP的转换，因为照片目录目前没有使用WebP，但他指出，”这可能是一个迹象，可能值得考虑只为调整后的图像生成WebP，而不是也为原始文件生成WebP”。

Silverstein说他们正在调查Hulse报告的问题，因为这可能暴露了一个错误。

Ozz回过头来建议，按需制作亚尺寸将是一个更好的方法，它对上传的图像有更快的处理，并减少空间需求，因为除非需要，否则不会生成额外的JPEG图像。他还指出，图像后期处理的 “重试”，”并不像预期的那样有效”。

“坏消息是，如果后期处理失败，有可能会保留最初上传的文件，”Ozz说。”那么它将被到处使用，因为WP中的大部分代码都会回落到可用的尺寸，而唯一的尺寸将是原始的。这意味着我们将提供巨大的（平均4MB-8MB）图片。一个严重的缺点”。

Silverstein回应了Ozz的建议，同意了许多建议，并为该项目提出了两条潜在的发展道路。

保留目前的多媒体基础设施，但改变默认值，以便只生成WebP文件，可能达到一个阈值大小，超过这个阈值就只生成JPEG文件。大多数现有的工作将继续进行；内容过滤可能会被删除。
恢复多媒介基础结构，转回单一媒介方法，在阈值大小以内的图像使用WebP，并调整兼容层以使用我们保留的JPEG文件。

性能团队正在做更多的研究，并暂时暂停了对其他事情的承诺，直到他们收到关于项目下一步方向的反馈。