上周，表演团队的贡献者随后的补丁努力改进其 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 需要图像多 mime 支持，当前的方法似乎也不是一个好的解决方案。”
大约 24 小时后，Google 赞助的贡献者 Felix Arntz 评论说，旧浏览器的 JPEG 回退机制已准备好提交，他计划在几天内提交。
“请不要在这里提交更多代码，除非它是为了解决上传后创建图像子尺寸所需资源的急剧增加，”Ozz 说。 "正如我上面所说，这种增加是不可接受的。
"上传不同尺寸的图片需要多少资源（内存、处理时间等），有没有数据？估计有多少站点可能受到影响？关于如何处理它有什么建议吗？你知道上传图片后处理失败会发生什么吗？
“坦率地说，在这一点上看起来必须恢复和重构这个补丁来解决这个问题。”
Adam Silverstein 回应了他的担忧，阐明了他们选择当前版本的原因方法，预测了一些极端情况，并在 AVIF 等格式得到更广泛的支持后最终添加了对它的支持：
我倾向于同意根据您的评估，所有子尺寸都应该仅作为 WebP 生成，这就是最初的提议。对于绝大多数用例/用户来说，这将是最好的。我愿意考虑将其设为默认值（有一些缓解措施，见下文）。
我们决定制作这两种格式的原因是为了向后兼容，我们发现了一些 WebP 图像可能无法工作的边缘情况：即电子邮件图像（一些较旧的 Outlook/Windows 客户端）、Open Graph 标签（一些服务不支持 WebP）和旧的 Safari 浏览器。我们考虑过的一种可能性是只保留全尺寸 JPEG，以便它始终可用于那些边缘情况。
此处的“多 MIME”支持旨在生成多种格式，因此您的网站可以使用图像元素等内容提供主要格式和备用格式。这对 WebP 不太重要，因为它得到广泛支持，但有助于通过插件或核心采用新格式，如 AVIF。
Silverstein 还表示，动态生成图像的选项是他们需要解决的问题，但“感觉超出了这项工作的范围”。
针对有关图片上传资源急剧增加的投诉，Silverstein 表示他们依靠“重试”机制来缓解这个问题。
“这一变化还将 WordPress 重试图像重新生成的次数加倍，因此虽然处理时间会增加，但我认为我们不一定会看到失败次数激增，”他说。 “我知道我们过去在添加新尺寸时遇到过麻烦，但那是在我们添加重试机制之前。”
默认情况下，WebP 项目背后的团队更专注于提供更小的图像尺寸，并认为上传时额外的资源使用是 WordPress 用户的必要牺牲。
“上传的额外资源必须与服务较小的 WebP 图像的资源减少进行权衡，特别是因为服务通常比上传发生的频率高几个数量级，”Silverstein 说。
“如果在所有重试后上传失败，用户将拥有与当前相同的体验：他们留下损坏的、无法使用的图像。这可能是可以修复的，尽管我认为这种改变不会增加失败率。”
WordPress 首席开发人员 Dion Hulse 还评论了一张报告 WordPress 照片目录中 WebP 转换问题的票证：
请注意，这些额外的 webp 转换似乎是最近几周 WordPress 照片目录上传失败的主要原因。观看#meta6142 和门票作为重复关闭。
错误通常是 256M 字节的允许内存大小已用尽（尝试分配 90M 字节（显然是字节值），同时尝试进行初始全尺寸原始 jpeg -> webp 转换。
它并没有影响每次上传，只是影响某些图像。可能与为 webp 请求传递的 $quality 值有关（IIRC 默认值 82 针对 jpeg 进行了优化？）。
Hulles 禁用 JPEG 到 WebP 的转换 由于这些错误，照片目录目前不使用 WebP，但指出“这可能表明值得考虑只为调整大小的图像生成 webp，而不是原始文件 webp ”
Silverstein 说他们正在调查 Hulse 报告的问题，因为它可能暴露了一个错误。
Oz 回过头来建议按需调整规模会更好，它可以更快地处理上传的图像并减少空间需求，因为除非需要，否则不会生成额外的 JPEG 图像。他还指出，“r用于图像后处理的 etries”“无法按预期工作”。
“坏消息是，如果后处理失败，最初上传的文件可能会保留下来，”Ozz 说。 “然后它将在任何地方使用，因为 WP 中的大部分代码都会回落到可用大小，并且唯一的大小将是原始大小。这意味着我们将提供巨大的（平均 4MB – 8MB）图像。这是一个严重的缺点。 "
Silverstein 回应了 Ozz 的建议，同意许多人的观点，并为该项目提出了两条可能的前进道路：
- 保持当前的 multi-mime 基础设施，但更改默认值以仅生成 WebP 文件，可能会达到阈值大小，超过该阈值将仅生成 JPEG。大多数现有工作将继续进行；内容过滤可能会被移除。
- 恢复多 mime 基础设施并切换回单 mime 方法，对达到阈值大小的图像使用 WebP，并调整兼容层以使用我们保留的 JPEG。
li>
性能团队正在做更多的研究，并且在他们收到关于项目下一个方向的反馈之前暂不提交任何其他内容。
类别: 新闻, WordPress
资源
