一年前，WordPress 5.8 引入了對 WebP 的支持，允許用戶在其內容中上傳和使用 WebP 圖像。 2022 年 3 月，性能團隊開始通過以下方式擴展對圖像格式的核心支持 提議 WordPress 默認啟用 WebP. 這將包括為新的 JPEG 上傳生成 WebP 圖像以及將 WebP 圖像用於網站內容。 4 月，有爭議的提案是 擱置 在重要的關鍵反饋之後。
經過數月的研究，該團隊已 重新評估其方法 並總結其發現。 對 WebP 兼容性的擔憂似乎沒有根據，因為 研究 顯示超過 97% 的網路瀏覽器是兼容的，超過 97% 的電子郵件客戶端也是如此。
移動應用程序與支持 WebP 的 iOS 14+（舊版本將提供 JPEG）和從 Android 4.0 原生支持 WebP 的 Android 具有很強的兼容性。 團隊發現所有頂級 RSS 閱讀器都支持 WebP。 兼容性方面的唯一異常值是 Open Graph 消費者，它們具有混合支持。
先前反饋的主要擔憂之一是該提案有可能使用於圖像的磁碟空間量增加一倍，因為除了 JPEG 子大小之外，它還會生成 WebP 縮略圖。 性能團隊貢獻者 Adam Silverstein 在對託管公司進行調查後分享了團隊的發現：
來評估整體 生成 WebP 圖像對站點存儲的影響，該團隊調查了託管服務提供商。 共有 17 條回復， 結果 表明存儲文件的數量對於大多數主機/站點來說通常不是問題，儘管隨著時間的推移存儲空間可能會成為一些用戶的問題。 儘管如此，對於大型主機（擁有 1,000 個或更多託管站點），絕大多數站點 (> 86%) 將不受影響，即使它們的存儲需求翻了一番。 我們還了解到，一些存儲空間有限的低端託管計劃在其託管堆棧中也缺乏 WebP 支持，這意味著他們無論如何都不會獲得額外的圖像生成。
聲明中可能包含一些假設，即「對於大多數主機/站點而言，存儲文件的數量通常不是問題」。 對該團隊調查的回應表明，58% 的用戶不會受到存儲需求翻倍的影響。 僅調查了 17 位房東，數據中未包含公司名稱。 即使估計有 14% 的網站面臨接近容量的風險，這也有可能影響數百萬個 WordPress 網站。
績效團隊提出了一些值得注意的改變來解決問題，包括 提供 JavaScript 片段 檢測缺乏 WebP 支持的瀏覽器並改為載入 JPEG。 默認情況下，其他 WebP 修訂包括以下內容：
- 在 6.1 中默認自動生成僅核心圖像大小的 WebP 版本。 自定義圖像大小最初必須選擇接收自動生成的 WebP 版本，或者如果它們專門用於 WebP 無益或不支持的特殊情況，則選擇退出。
- 僅當次要 (WebP) 子大小小於主要 MIME 類型時才保留它們。
- 只為用於面向用戶的前端內容的圖像大小生成 WebP 圖像。 這避免了為永遠不會使用的 WebP 圖像浪費存儲空間。
- 引入一個過濾器來控制基於圖像子大小的其他 MIME 類型的生成。 這使開發人員能夠排除某些圖像大小，例如那些未在前端內容中使用的圖像大小。
默認情況下，WebP 提案只會影響包含在核心中後上傳的新圖像。 它不會為現有上傳自動生成 WebP 圖像。 想要轉換過去上傳的用戶需要使用 WP-CLI 或像 Regenerate Thumbnails 這樣的插件。
迄今為止，對該提案的修訂收到了不同的反饋。 一些人強烈支持新方法，而另一些人則鼓勵團隊考慮對可能受到影響的用戶的一些實際影響。
「不能簡單地說沒關係，因為『絕大多數網站 (> 86%) 不會受到影響，』」WordPress 開發人員 Jon Brown 說. 「首先，14% 是 WordPress 的條款很多。 我們不知何故需要繼續支持仍在運行 PHP 5.6 的 2.8% 的網站，但 14% 不是很重要嗎？
「這裡不僅需要考慮 IF，還需要考慮這 14% 的站點將如何受到影響，不僅是今天，未來也是如此。 站點是否只需要順利升級存儲，或者它們會用完磁碟空間並崩潰？ 還是備份突然開始失敗？」
評論中的多位參與者建議 WordPress 考慮採用更現代的 AVIF 格式，與 WebP 相比，它具有更好的質量和壓縮率。
「既然這項舉措本質上是一種漸進式增強，那麼在優雅地回退的同時支持下一代格式（如 AVIF）不是更有意義嗎？」 JavaScript 開發人員 Kevin Batdorf 說。 「隨著時間的推移，隨著時間的推移，瀏覽器會增加支持，它們就會到位。
「轉向 WebP 支持的感覺就像 WordPress 添加了 REST API，而每個人都開始轉向 GraphQL。 REST 很棒，WebP 也很棒，但它是當前的技術，很快就會過時。」
表演團隊貢獻者 Bethany Chobanian Lang 說 AVIF 是 在他們的雷達上，但它的瀏覽器支持仍然不足，不到 70% 的網路。
對話在評論中繼續 更新 Silverstein 還鼓勵參與 跟蹤票 對於修改後的方法。 性能團隊貢獻者的目標是在 6.1 發布周期的早期合併此更改以獲得更多測試。