給重度使用圖片的WordPress站點做過Lighthouse性能審計的朋友，一定熟悉那條反復出現的提醒：“請使用新一代格式提供圖片。”話里的意思就是，你的JPEG和PNG體積太大了，換成WebP格式能顯著減少文件大小。道理都知道，但真正到了執行環節，多數人只會把這條建議擱在待辦清單里，因為沒人愿意一張張手動轉換圖片，而能實現自動化的方案，要么需要你專門記得觸發批量任務，要么要求把圖片推送到某個有月度配額的云服務。

所以我想要的東西很簡單：上傳一張圖片，自動得到WebP版本，到此為止?；谶@個念頭，我寫了一個免費插件Pixellize Image Optimizer。接下來就順著當時解決問題的過程，聊聊這個插件的思路、它又是怎樣在服務器端不用任何外部服務就完成轉換的。

先看WebP這一格式到底值不值得折騰。在同等的主觀視覺質量下，WebP文件通常比對應的JPEG或PNG小25%到35%。放在圖片密集的頁面上，這份體積差異會直接體現在三個地方：首先是更快的最長內容繪制（LCP），這是谷歌用于排名的核心網頁指標之一，效果立竿見影；其次是帶寬消耗明顯下降，如果你為CDN流量付費，每一個字節的節省都會體現在賬單上；再者，只要不把壓縮質量調到過分極端的程度，肉眼根本看不出畫質損失。至于瀏覽器支持，現在已經沒必要猶豫，市面上所有主流瀏覽器都能正常顯示WebP圖片。

很多同類方案選擇把圖片上傳到云端轉換，再拉回結果，但這套路徑除了增加延遲，還多出一套賬戶、API密鑰和付費階梯。Pixellize Image Optimizer的思路正好相反——轉換工作全程留在自己的服務器上。上傳一張圖片到WordPress媒體庫的瞬間，插件調用主機上幾乎必備的PHP GD或Imagick擴展，在本地生成全尺寸圖片和每一個縮略圖尺寸對應的WebP文件。整個過程不需要申請任何賬號，沒有密鑰配置，也不會彈出什么“免費額度已用完”的提示。

如果你關心這背后是怎么和WordPress內部邏輯相處的，實際上插件并沒有另起爐灶，而是直接掛在原生上傳和渲染流程上。圖片上傳階段，它介入到附件元數據的生成過程里，所以轉換的不只是原圖，還包括系統中注冊過的所有縮略圖尺寸。這步之所以重要，是因為響應式圖片依賴srcset屬性向不同屏幕投放不同尺寸，只要有一個尺寸沒轉成WebP，整個srcset里還會夾著舊的JPEG，等于前功盡棄。到了前端輸出環節，插件通過WordPress已有的過濾器重寫圖片鏈接——依次處理附件圖片源、響應式srcset以及文章正文里嵌入的圖片地址。萬一某個文件還沒有對應的WebP副本，系統就繼續提供原始格式，不會報錯也不會出現空白。

文件命名也老老實實照著原始文件走：image.jpg的WebP版本就是image.webp；碰到WordPress為避免重名自動加上序號的情況，比如image?1.jpg，那么它對應的WebP文件就叫image?1.webp。一來瀏覽器能直接按規則找到對應資源，二來日后做遷移或者排查，也不會被一堆亂七八糟的命名弄暈。

到了0.4版，我把選擇權完全交給使用者，兩種模式可以滿足完全不同的策略。默認是“替換模式”，上傳的圖片最終只保留一份WebP，原始JPEG或PNG會被移除，最大限度節省磁盤空間。另一種是“保留模式”，原始文件依然留在媒體庫里，插件在旁邊建一份WebP，訪問者拿到的是輕量的新格式，但你可以隨時把任何一張圖切回原始版本。在保留模式下，媒體庫列表里會多出一個一鍵“還原”按鈕，點擊后讓附件重新指向源文件，并基于源文件重建所有縮略圖尺寸，操作不到一秒。等到真要刪除某張圖片，插件也會連帶清理掉所有關聯的WebP副本，不留冗余文件。

這個插件從最初的簡單念頭，到后來把保留原圖、一鍵還原這些實際使用中繞不開的需求都考慮進去，整個過程里我在意的始終是“不增加額外負擔”。不需要記住去點“批量轉換”，不需要擔心云服務某天改價格，不需要在性能優化的最佳實踐和日常操作習慣之間反復權衡。只要你的WordPress主機支持GD或Imagick——絕大多數都支持——那么從下一次上傳圖片開始，Lighthouse里那行“使用新一代格式”的建議就可以直接忽略掉了。