上周，性能团队的贡献者正在努力完善他们的多 mime/WebP 功能的后续补丁，此前该功能的主要工作在 7 月底被合并到 6.1 的核心中。这包括较小的相关项目，例如用于不支持浏览器的 shim 和添加 PDF 支持，这些项目在单独的工单中处理。
为新的 JPEG 图像上传默认生成 WebP 图像的提议从一开始就存在争议。虽然 Google 赞助的推动该项目的贡献者在第一轮重要的批评反馈后进行了一些修改，但其他贡献者继续表达他们表示没有被考虑的担忧。一些贡献者报告了该功能的问题，并建议它应该从选择加入开始，这个想法在主要工作提交之前被立即驳回。
上周，WordPress 首席开发人员 Andrew Ozz 提出了新的反对意见：
像 @MatthiasReinholz、 @eatingrules和其他人一样，我认为这种方法可能缺乏。当其中一半永远不会在任何地方使用时，为什么会有两倍多的图像文件占用大量额外空间？
恕我直言，更好的方法是将所有图像子尺寸都设为 WEBP。如果确实需要 JPEG，则可以根据需要即时生成。没有必要用所有这些无用的文件来阻塞 Web 服务器的存储。
另一方面，如果 WEBP 文件大小实际上比 JPEG 大，那可能意味着需要更好的工具，而这个补丁还为时过早。
六周前，谷歌赞助的核心提交者亚当·西尔弗斯坦（Adam Silverstein）在回应一项关于“转换资源将是巨大的”的抱怨时证实，用于生成上传图像的资源将“急剧增加”。
“但是，服务于图像的资源将会减少，”西尔弗斯坦说。“由于与图像服务相比，图像上传非常罕见，因此压缩和存储图像的额外努力应该是值得的。”
这是 Ozz 在反对这种方法时引用的另一个问题。
“实际上，上传图片时资源使用量的急剧增加在这里是一个非常糟糕的副作用，”Ozz 说。“这意味着很多上传都会失败，让用户陷入困境。它还将显着增加对 WordPress 和托管公司的支持请求。不要认为这是可以接受的。正因为如此，即使 WordPress 需要图像多 mime 支持，当前的方法似乎也不是一个好的解决方案。”
大约 24 小时后，谷歌赞助的贡献者 Felix Arntz评论说，旧浏览器的 WebP 回退机制到 JPEG 已准备好提交，他计划在几天内提交。
“请不要在这里提交更多代码，除非它是为了解决上传后创建图像子尺寸所需的资源急剧增加，”Ozz 说。“正如我上面所说，这种增加是不可接受的。
“上传不同尺寸的图像时，是否有关于需要多少资源（内存、处理时间等）的数据？估计有多少网站可能会受到影响？关于如何处理它的任何建议？你知道上传图片后处理失败时会发生什么吗？
“坦率地说，目前看来，这个补丁必须被恢复和重构才能解决这个问题。”
亚当·西尔弗斯坦 (Adam Silverstein) 回应了他的担忧，澄清了他们选择当前方法的原因，预期某些极端情况，并最终增加对 AVIF 等格式的支持，一旦它得到更广泛的支持：
我倾向于同意您的评估，即所有子尺寸都应仅作为 WebP 生成，这就是原始提案的形式。对于绝大多数用例/用户来说，这将是最好的。我愿意考虑将此作为默认设置（有一些缓解措施，见下文）。
我们决定生成这两种格式的原因是出于向后兼容性考虑，我们确定了 WebP 图像可能无法工作的少数边缘情况：即电子邮件图像（一些较旧的 Outlook/Windows 客户端）、Open Graph 标签（一些服务不支持WebP) 和较旧的 Safari 浏览器。我们考虑的一种可能性是只保留全尺寸的 JPEG，以便它始终可用于那些边缘情况。
这里的“multi-mime”支持旨在生成多种格式，因此您的站点可以提供带有
picture元素之类的主要格式和备用格式。这对于 WebP 来说不太重要，因为它得到了广泛的支持，但对于通过插件或核心采用 AVIF 等新格式很有帮助。
Silverstein 还表示，动态生成图像的选项是他们需要弄清楚的，但“感觉超出了这项工作的范围”。
针对有关图像上传资源急剧增加的投诉，Silverstein 表示他们正在依靠“重试”机制来缓解这个问题。
“这一变化也使 WordPress 重试图像再生的次数增加了一倍，因此虽然处理时间会增加，但我认为我们不一定会看到失败的激增，”他说。“我知道过去我们在添加新尺寸时遇到了麻烦，但那是在我们添加重试机制之前。”
默认情况下，WebP 项目背后的团队更专注于在前端提供较小的图像尺寸，并认为上传时额外的资源使用是 WordPress 用户的必要牺牲。
“上传时的额外资源需要与服务较小 WebP 图像的资源减少进行权衡，特别是因为服务通常比上传更频繁地发生几个数量级，”Silverstein 说。
“如果在所有重试后上传失败，用户将获得与当前相同的体验：他们留下的图像损坏、无法使用。这可能是可以解决的，尽管我认为这种变化不会增加失败率。”
WordPress 首席开发人员 Dion Hulse 还评论了在 WordPress 照片目录中报告 WebP 转换问题的票：
请注意，这些额外的 webp 转换似乎是最近几周 WordPress 照片目录上传失败的主要原因。请参阅 #meta6142 并且票证作为其副本关闭。
Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes在尝试执行初始全尺寸原始 jpeg -> webp 转换时，错误通常与 （显然与字节值有关）。它并没有影响 每次上传，只影响某些图像。可能与
$quality为 webp 请求传递的值有关（IIRC 的默认值 82 已针对 jpeg 进行了优化？）。
由于这些错误， Hulse禁用了 JPEG 到 WebP 的转换，因为照片目录当前不使用 WebP，但指出这“可能表明可能值得考虑只为调整大小的图像生成 webp，而不是为原文件也是。”
Silverstein 说他们正在调查 Hulse 报告的问题，因为它可能暴露了一个错误。
Ozz 转而建议按需制作子尺寸将是一种更好的方法，它可以更快地处理上传的图像并减少空间需求，因为除非需要，否则不会生成额外的 JPEG 图像。他还指出，图像后处理的“重试”“效果不如预期”。
“坏消息是，如果后处理失败，最初上传的文件很可能会保留，”Ozz 说。“然后它将在任何地方使用，因为 WP 中的大多数代码都回退到可用大小，并且唯一的大小将是原始大小。这意味着我们将提供巨大的（平均 4MB – 8MB）图像。一个严重的缺点。”
Silverstein 回应了 Ozz 的建议，同意许多人的意见，并为该项目提出了两条潜在的前进道路：
- 保留当前的多 mime 基础结构，但更改默认值以便仅生成 WebP 文件，可能达到阈值大小，超过该阈值大小将仅生成 JPEG。大多数现有工作将继续进行；内容过滤可能会被删除。
- 恢复多 mime 基础架构并切换回单一 mime 方法，对达到阈值大小的图像使用 WebP，并调整兼容层以使用我们保留的 JPEG。
性能团队正在做更多的研究，并暂时停止提交任何其他事情，直到他们收到有关项目下一个方向的反馈。
