上周，性能團隊的貢獻者正在努力改進他們的多 mime/WebP 功能的後續補丁，之後主要工作是 合併到 6.1 的核心 在七月底。 這包括較小的相關項目，例如用於不支持瀏覽器的 shim 和添加 PDF 支持，這些項目在單獨的工單中處理。
為新的 JPEG 圖像上傳默認生成 WebP 圖像的提議從一開始就存在爭議。 雖然谷歌贊助的推動該項目的貢獻者在第一輪重要的批評反饋後進行了一些修改，但其他貢獻者繼續表達他們表示沒有被考慮的擔憂。 一些貢獻者報告了該功能的問題，並建議它應該從選擇加入開始，這個想法在主要工作提交之前被立即駁回。
上周，WordPress 首席開發人員 Andrew Ozz 新的反對意見：
喜歡 @MatthiasReinholz, @eatingrules，而其他人我認為這種方法可能是缺乏的。 當其中一半永遠不會在任何地方使用時，為什麼會有兩倍多的圖像文件佔用大量額外空間？
恕我直言，更好的方法是將所有圖像子尺寸都設為 WEBP。 如果確實需要 JPEG，則可以根據需要即時生成。 沒有必要用所有這些無用的文件來阻塞 Web 伺服器的存儲。
另一方面，如果 WEBP 文件大小實際上比 JPEG 大，那可能意味著需要更好的工具，而這個補丁還為時過早。
六周前，谷歌贊助的核心提交者亞當·西爾弗斯坦（Adam Silverstein）在回應一項抱怨「轉換資源將是巨大的」時證實，用於生成上傳圖像的資源將「急劇增加」。
「但是，服務於圖像的資源將會減少，」西爾弗斯坦說。 「由於與圖像服務相比，圖像上傳非常罕見，因此壓縮和存儲圖像的額外努力應該是值得的。」
這是 Ozz 在反對這種方法時引用的另一個問題。
「實際上，上傳圖片時資源使用量的急劇增加在這裡是一個非常糟糕的副作用，」Ozz 說。 「這意味著很多上傳都會失敗，讓用戶陷入困境。 它還將顯著增加對 WordPress 和託管公司的支持請求。 不要認為這是可以接受的。 正因為如此，即使 WordPress 需要圖像多 mime 支持，當前的方法似乎也不是一個好的解決方案。」
大約 24 小時後，Google 贊助的貢獻者 Felix Arntz 評論 建議舊瀏覽器的 WebP 回退機制到 JPEG 已準備好提交，他計劃在幾天內提交。
「請不要在這裡提交更多代碼，除非它是為了解決上傳後創建圖像子尺寸所需的資源急劇增加，」Ozz 說。 「正如我上面所說，這種增加是不可接受的。
「上傳不同尺寸的圖像時，是否有關於需要多少資源（內存、處理時間等）的數據？ 估計有多少網站可能會受到影響？ 關於如何處理它的任何建議？ 你知道上傳圖片後處理失敗時會發生什麼嗎？
「坦率地說，目前看來，這個補丁必須被恢復和重構才能解決這個問題。」
亞當·西爾弗斯坦 (Adam Silverstein) 回應了他的擔憂，澄清了他們選擇當前方法的原因，預期某些極端情況，並最終增加對 AVIF 等格式的支持，一旦它得到更廣泛的支持：
我傾向於同意您的評估，即所有子尺寸都應僅作為 WebP 生成，這就是原始提案的形式。 對於絕大多數用例/用戶來說，這將是最好的。 我願意考慮將此作為默認設置（有一些緩解措施，見下文）。
我們決定生成這兩種格式的原因是出於向後兼容性考慮，我們確定了 WebP 圖像可能無法工作的少數邊緣情況：即電子郵件圖像（一些較舊的 Outlook/Windows 客戶端）、Open Graph 標籤（一些服務不支持WebP) 和較舊的 Safari 瀏覽器。 我們考慮的一種可能性是只保留全尺寸的 JPEG，以便它始終可用於那些邊緣情況。
這裡的「multi-mime」支持旨在生成多種格式，因此您的站點可以提供帶有圖片元素之類的主要和備用格式。 這對於 WebP 來說不太重要，因為它得到了廣泛的支持，但對於通過插件或核心採用 AVIF 等新格式很有幫助。
Silverstein 還表示，動態生成圖像的選項是他們需要弄清楚的，但「感覺超出了這項工作的範圍」。
針對有關圖像上傳資源急劇增加的投訴，Silverstein 表示他們正在依靠「重試」機制來緩解這個問題。
「這一變化也使 WordPress 重試圖像再生的次數增加了一倍，因此雖然處理時間會增加，但我認為我們不一定會看到失敗的激增，」他說。 「我知道過去我們在添加新尺寸時遇到了麻煩，但那是在我們添加重試機制之前。」
默認情況下，WebP 項目背後的團隊更專註於在前端提供較小的圖像尺寸，並認為上傳時額外的資源使用是 WordPress 用戶的必要犧牲。
「上傳時的額外資源需要與服務較小 WebP 圖像的資源減少進行權衡，特別是因為服務通常比上傳更頻繁地發生幾個數量級，」Silverstein 說。
「如果在所有重試後上傳失敗，用戶將獲得與當前相同的體驗：他們留下的圖像損壞、無法使用。 這可能是可以解決的，儘管我認為這種變化不會增加失敗率。」
WordPress 首席開發人員 Dion Hulse 也 評論 在 WordPress 照片目錄中報告 WebP 轉換問題的票證上：
請注意，這些額外的 webp 轉換似乎是最近幾周 WordPress 照片目錄上傳失敗的主要原因。 看 #meta6142 並且門票作為副本關閉。
錯誤通常是在嘗試執行初始全尺寸原始 jpeg -> webp 轉換時，允許的內存大小為 256M 位元組耗盡（嘗試分配 90M 位元組（顯然帶有位元組值）。
它並沒有影響每次上傳，隻影響某些圖像。 可能與為 webp 請求傳遞的 $quality 值有關（IIRC 的默認值 82 已針對 jpeg 進行了優化？）。
胡爾斯 禁用 JPEG 到 WebP 的轉換 由於這些錯誤，照片目錄目前不使用 WebP，但指出「這可能表明值得考慮只為調整大小的圖像生成 webp，而不是為原始文件生成 webp。」
Silverstein 說他們正在調查 Hulse 報告的問題，因為它可能暴露了一個錯誤。
奧茲盤旋迴到 推薦 按需製作子尺寸將是一種更好的方法，它可以更快地處理上傳的圖像並減少空間需求，因為除非需要，否則不會生成額外的 JPEG 圖像。 他還指出，圖像後處理的「重試」「效果不如預期」。
「壞消息是，如果後處理失敗，最初上傳的文件很可能會保留，」Ozz 說。 「然後它將在任何地方使用，因為 WP 中的大多數代碼都回退到可用大小，並且唯一的大小將是原始大小。 這意味著我們將提供巨大的（平均 4MB – 8MB）圖像。 一個嚴重的缺點。」
Silverstein 回應了 Ozz 的建議，同意許多人的意見，並為該項目提出了兩條潛在的前進道路：
- 保留當前的多 mime 基礎結構，但更改默認值以便僅生成 WebP 文件，可能達到閾值大小，超過該閾值大小將僅生成 JPEG。 大多數現有工作將繼續進行； 內容過濾可能會被刪除。
- 恢復多 mime 基礎架構並切換回單一 mime 方法，對達到閾值大小的圖像使用 WebP，並調整兼容層以使用我們保留的 JPEG。
績效團隊正在做更多的研究，並暫時停止提交任何其他事情，直到他們收到有關項目下一個方向的反饋。