Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124

如果你的網站目前尚未使用 WebP 的圖片格式,那麼透過今天的 WebP 介紹,或許你可以考慮將網站的圖片格式轉換成 WebP,以增快網站速度。
用 AI 摘要這篇文章:
你在經營一個 WordPress 網站,打開首頁卻要等上好幾秒,圖片一張一張慢慢浮現。這種體驗不只讓訪客不耐煩,Google 也不會給你好的排名。問題的核心往往不是你的主機不夠快,而是圖片根本沒有經過最佳化處理。
WebP 就是為了解決這個問題而生的圖片格式。由 Google 從 2010 年開始開發,WebP 能夠在保持幾乎相同畫質的前提下,把圖片檔案大小壓縮到 JPEG 的 70%、PNG 的 55%。換句話說,你的網站圖片總容量可以直接砍掉三分之一甚至一半,而且肉眼幾乎看不出差異。
早期 WebP 最大的障礙是瀏覽器支援。2018 年那個年代,只有 Chrome 和 Opera 能正確顯示 WebP 圖片,Safari 甚至到 2020 年都還不支援。但到了 2026 年的今天,局面完全不同了。Chrome、Firefox、Edge、Safari 16+ 全部原生支援 WebP,覆蓋率超過 97% 的全球使用者。對於任何一個認真經營的 WordPress 網站 來說,啟用 WebP 已經不再是「要不要做」的問題,而是「什麼時候要開始做」。
WebP 同時支援有損壓縮和無損壓縮兩種模式。有損模式用來取代 JPEG,適合照片類圖片;無損模式用來取代 PNG,適合需要保留每個細節的圖示或截圖。更棒的是 WebP 還支援 Alpha 透明通道和動畫,等於一個格式就能吃掉 JPEG、PNG 和 GIF 三種傳統格式的功能。
目錄
光說 WebP 比較小還不夠具體,讓我用實際測試資料來說明。Google 在開發 WebP 時做了大量測試,結論很明確:在相同畫質的前提下,WebP 有損壓縮的檔案比 JPEG 小 25-34%;WebP 無損壓縮的檔案比 PNG 小約 26%。如果你把 PNG 先做破壞性壓縮再轉 WebP,差距還會更大,達到 45% 左右。
以下是一張 1920×1080 解析度的風景照片,在不同格式下的實際檔案大小對比:
| 格式 | 壓縮方式 | 檔案大小 | 與 JPEG 比較 | 透明度支援 |
|---|---|---|---|---|
| JPEG | 有損 | 185 KB | 基準 | 否 |
| WebP(有損) | 有損 | 125 KB | -32% | 否 |
| PNG | 無損 | 420 KB | +127% | 是 |
| WebP(無損) | 無損 | 310 KB | +68% | 是 |
| AVIF | 有損 | 95 KB | -49% | 是 |
從表格可以清楚看到,同樣是有損壓縮,WebP 比 JPEG 少了 32% 的體積,而無損的 WebP 雖然比有損的 JPEG 大,但比起無損的 PNG 仍然小了 26%。如果你原本用 PNG 來存放照片(很多人確實會這麼做),轉換成 WebP 的效益非常驚人。
動畫方面的差距更誇張。一個 5 秒的簡單動畫,GIF 格式可能要 800 KB,同樣的動畫用 WebP 格式只需要大約 300 KB,壓縮率超過 60%。對於需要在文章中嵌入簡短動態效果的場景,圖片最佳化工具 搭配 WebP 格式是目前的最佳組合。
表格中也列出了 AVIF 格式。AVIF 是比 WebP 更新的下一代格式,壓縮率更高,但目前瀏覽器支援度還在追趕中。關於 AVIF 與 WebP 的深入比較,我會在後面的章節詳細討論。如果你想先了解 線上壓縮工具 的實際使用體驗,也可以參考之前的介紹。
為什麼圖片格式這件事值得你花時間研究?因為圖片是大多數網頁中最肥大的資源。根據 HTTP Archive 的統計,圖片平均佔了一個網頁總載入量的 50% 到 65%。你的伺服器再快、你的 快取外掛 再強,只要圖片沒有最佳化,整體速度就是快不起來。
Google 從 2021 年開始正式把 Core Web Vitals 納入排名因素。其中最重要的指標是 LCP(Largest Contentful Paint),也就是頁面中最大元素載入完成的時間。在大多數 WordPress 網頁中,這個「最大元素」通常就是一張圖片,特別是文章特色圖片或 Hero 區塊的大圖。
我用自己的一個測試網站做過實驗。原本首頁的 LCP 是 3.4 秒,主要因為一張 450 KB 的 JPEG 特色圖片拖慢了整體表現。把這張圖轉成 WebP 之後,檔案降到 180 KB,LCP 直接縮短到 1.9 秒。光是一張圖片的改變,就讓 Google PageSpeed Insights 的分數從 65 跳到 88。
如果你用 網站速度測試工具 來檢測自己的 WordPress 網站,很可能會在建議項目中看到「Serve images in next-gen format」這條。Google 直接告訴你:請使用 WebP 或 AVIF 這類現代格式來取代 JPEG 和 PNG。這不是選配,而是 Google 明確列出的 SEO 最佳化 建議。
除了 LCP,圖片大小也間接影響 FID(First Input Delay)和 CLS(Cumulative Layout Shift)。大的圖片佔用更多頻寬,導致瀏覽器在解析和渲染時花更多時間;如果圖片沒有設定好尺寸屬性,載入時還會造成版面跳動。所以圖片最佳化的效益是全方位的,不只是 伺服器回應時間 的問題,而是整體使用者體驗的提升。
對於已經在使用 GiftofSpeed 或其他速度檢測工具的站長來說,你應該已經很清楚圖片最佳化的重要性。WebP 不是唯一的解法,但它是最容易實作、效益也最明確的那個。搭配良好的 WordPress 網站最佳化策略,效果會更顯著。
早期的 WordPress 完全不支援 WebP,你甚至無法把 .webp 檔案上傳到媒體庫。這個限制直到 WordPress 5.8(2021 年 7 月)才被打破。從這個版本開始,你可以直接上傳 WebP 圖片,WordPress 會把它當成一般圖片格式來處理,包括在編輯器中預覽和插入文章。
不過 5.8 的支援只是「能上傳」而已,距離真正的自動化還很遠。WordPress 不會自動把你的 JPEG 轉成 WebP,也不會在上傳 WebP 時產生不同尺寸的子圖片。這些功能是後續版本才逐步加入的。
WordPress 6.1 開始支援 WebP 子尺寸的自動產生。也就是說,當你上傳一張 WebP 圖片時,WordPress 會自動幫你生成縮圖、中型、大型等不同尺寸的 WebP 版本。到了 WordPress 6.5,WebP 的處理效能進一步改善,跟 JPEG 的處理流程更加一致。
但原生的支援仍有幾個明顯的限制。第一,它不會自動把現有的 JPEG 或 PNG 圖片轉換成 WebP。你媒體庫裡已經存在的幾百張舊圖片,除非手動重新上傳,否則不會有任何改變。第二,原生的 WebP 支援依賴伺服器的 PHP 圖片處理擴充套件(GD 或 Imagick),如果你的主機沒有安裝這些擴充套件,WebP 相關功能就無法使用。
要檢查你的主機是否支援 WebP 處理,可以在 WordPress 後台進入「工具」→「網站狀態」→「資訊」頁面,搜尋「GD」或「Imagick」看看是否有 WebP 支援的相關資訊。如果你使用的是主流的 WordPress 推薦主機,通常都已經內建支援了。
既然 WordPress 原生不會自動轉換既有圖片,最簡單的做法就是安裝一個圖片最佳化外掛。這類外掛會在你上傳圖片時自動產生 WebP 版本,有些還能回頭處理媒體庫裡的舊圖片。以下是我實際用過、覺得值得推薦的幾款外掛。
ShortPixel 是我自己用了好幾年的圖片壓縮服務,也是本站長期使用的工具。它提供免費方案,每個月可以免費壓縮 100 張圖片,而且支援自動產生 WebP 格式。安裝外掛後,每次上傳圖片時 ShortPixel 就會自動壓縮並產生 WebP 版本,同時保留原始檔案。
付費方案的價格也很合理,一張圖片大約 0.003 美元,換算下來壓縮 1000 張圖片大約只要 3 美元。對於一個正常更新的部落格來說,一個月 100 張的免費額度其實就夠用了。如果圖片量真的很大,可以參考他們的一次性購買方案,買一次用完為止,沒有時間壓力。
ShortPixel 的設定很直覺。安裝後到設定頁面,勾選「也產生 WebP 版本」這個選項就行了。如果你同時使用 WP Rocket 或其他支援 WebP 的快取外掛,ShortPixel 產生的 WebP 檔案就能自動被快取外掛引用,在不支援 WebP 的瀏覽器上則自動退回原始格式。如果你還沒有安裝快取外掛,可以參考後面的相關介紹。
如果你不想付任何費用,Converter for Media(原名 WebP Converter for Media)是目前最好的免費方案。它的運作原理跟 ShortPixel 類似,安裝後會自動把媒體庫裡的圖片轉換成 WebP 格式。免費版支援 WebP,付費版(約 30 美元一次性購買)還額外支援 AVIF 格式。
這個外掛的好處是完全免費、沒有每月額度限制、操作簡單。缺點是它的壓縮引擎不如 ShortPixel 精細,在極端情況下可能出現品質差異。但對大多數網站來說,差異微乎其微。
Imagify 是另一款優質的圖片壓縮外掛,提供 Normal、Aggressive、Ultra 三種壓縮等級,與 WP Rocket 是同一家公司開發的,整合度特別好。免費方案每月 20 MB,對圖片數量不多的網站勉強夠用。
EWWW Image Optimizer 走的是精確控制路線,你可以自行設定壓縮品質參數、選擇要轉換的格式。新會員有 500 張免費額度,之後按張計費每張 0.003 美元。適合對壓縮品質有特殊要求的進階使用者。
如果你的主機是 SiteGround,他們自家的 SG Optimizer 外掛也內建了圖片最佳化功能,包含 WebP 轉換,不需要額外安裝第三方外掛。
以下是這幾款外掛的快速比較:
| 外掛名稱 | 免費額度 | WebP 支援 | AVIF 支援 | 適合對象 |
|---|---|---|---|---|
| ShortPixel | 100 張/月 | 是 | 付費版 | 一般網站、追求品質者 |
| Converter for Media | 無限制 | 是 | 付費版 | 預算有限的使用者 |
| Imagify | 20 MB/月 | 是 | 否 | WP Rocket 使用者 |
| EWWW IO | 500 張(一次性) | 是 | 付費版 | 進階使用者 |
如果你不想在 WordPress 裡面裝額外的圖片處理外掛,另一條路是讓 CDN(內容傳遞網路)來幫你處理 WebP 轉換。CDN 方案的優勢很明顯:不佔用你的伺服器資源、不需要修改 WordPress 設定,而且通常只需要點幾個按鈕就能啟用。
Cloudflare 是全球最多人使用的 CDN 服務之一。它的 Pro 方案(每月 20 美元)內建了一個叫做 Polish 的功能,會自動把經過 Cloudflare 的圖片轉換成 WebP 格式,再傳送給支援 WebP 的瀏覽器。整個過程完全透明,你的 WordPress 完全不需要做任何設定。
Cloudflare 免費方案雖然沒有 Polish 功能,但仍然提供基本的 CDN 快取服務,能有效縮短全球使用者的 網路存取延遲。加上免費的 DNS 代管、DDoS 防護和 Turnstile 驗證碼 等功能,即使不升級 Pro 方案,Cloudflare 對網站的幫助也非常大。我自己從架站第一天就開始使用 Cloudflare 的 DNS 服務,到現在從未換過。
Jetpack 是另一個零設定的選擇。這個由 WordPress 母公司 Automattic 開發的外掛,免費方案就包含了 CDN 圖片加速功能。啟用後,Jetpack 會把你網站的所有圖片透過他們的 CDN 來提供服務,CDN 會自動偵測瀏覽器是否支援 WebP,然後動態轉換格式。對於不想花時間設定的使用者來說,Jetpack 是最省事的方案。
Cloudinary 則是更專業的圖片管理平台。它不只是單純的 CDN,而是一套完整的圖片處理系統,包含自動裁切、智慧最佳化、格式轉換等進階功能。Cloudinary 會根據使用者的裝置和瀏覽器自動選擇最佳的圖片格式和尺寸。適合圖片量大、對品質要求高的商業網站。
CDN 方案的選擇跟你使用的主機也有關聯。如果你用的是 Kinsta 這類高階託管 WordPress 主機,他們通常已經內建了伺服器端的快取和 CDN 整合,你可能不需要額外處理。而如果你用的是共享主機方案,搭配 Cloudflare 或 Jetpack CDN 來處理 WebP 轉換會是最划算的做法。想知道更多主機選擇,可以參考我們的 WordPress 主機推薦懶人包。
對於有技術背景、使用 VPS 或專屬主機的站長,你可以直接在伺服器層面設定 WebP 的自動轉換和切換。這個方法的優點是完全不需要安裝 WordPress 外掛,不佔用 PHP 處理資源,效能是最好的。缺點是設定過程需要對伺服器配置有一定了解。
前提條件是你需要先確保伺服器上已經有 WebP 版本的圖片檔案。手動設定不會幫你產生 WebP,它只是負責在瀏覽器支援 WebP 時,自動把 .jpg 或 .png 的請求導向對應的 .webp 檔案。你可以用批量轉換工具(後面會介紹)先把所有圖片轉換好,再套用伺服器規則。
如果你的主機是 Apache 伺服器,可以在 .htaccess 中加入 Rewrite 規則。這段規則會偵測瀏覽器的 Accept 標頭是否包含 image/webp,如果是,就檢查是否存在對應的 .webp 檔案,有的話就改為提供 WebP 版本。
Nginx 伺服器的設定方式稍有不同,需要用到 map 指令來偵測瀏覽器支援,然後在 try_files 中加上 WebP 的查找路徑。概念一樣,只是語法不同。
這個方法還需要搭配正確的 HTTP 壓縮設定,確保伺服器在傳送 WebP 圖片時有正確的 Content-Type 標頭和快取標頭。設定不當可能導致瀏覽器快取失效或 MIME 類型錯誤。
如果你使用的是 A2 Hosting 或 SiteGround 這類提供完整 cPanel 管理介面的主機商,他們的技術支援團隊通常可以協助你設定這些伺服器層級的規則。如果你對伺服器配置不熟悉,我建議用前面介紹的外掛或 CDN 方案就好,不用勉強走手動路線。選擇主機時可以多方比較,找到最適合自己技術能力的方案。
很多人在轉換 WebP 時會遇到一個問題:壓縮太激進導致圖片糊了,壓縮太保守又感覺沒什麼效果。到底該把品質參數設在哪裡?
根據我多次測試的經驗,有損 WebP 的品質參數設在 75 到 85 之間是最好的平衡點。低於 75 開始出現肉眼可見的細節流失,特別是在文字邊緣和漸層色帶的地方;高於 85 雖然品質再提升一點點,但檔案大小會急遽增加,CP 值很低。我個人習慣設在 80,這個數值在檔案大小和畫質之間取得了不錯的平衡。
如果你的圖片包含透明背景(比如 Logo 或圖示),轉換時要特別注意 Alpha 通道的設定。WebP 支援透明度,但某些轉換工具預設會把透明背景填成白色。使用 ShortPixel 或 Converter for Media 這類外掛時,通常會自動保留透明度,但用命令列工具或 線上轉檔工具 時就要自己確認設定是否正確。
說到批量轉換,Google 官方提供了 cwebp 這個命令列工具,可以在 macOS、Windows 和 Linux 上使用。基本的指令是 cwebp -q 80 input.jpg -o output.webp,寫個簡單的 Shell 腳本就能一次處理整個資料夾的圖片。如果你不習慣命令列,Optimizilla 和 Compress PNG/JPG 這類線上工具也提供批次處理功能,只是有檔案大小和數量的限制。
在 WordPress 中調整圖片壓縮品質,除了透過外掛的設定介面之外,也可以在佈景主題的 functions.php 中加入 add_filter('jpeg_quality', function(){return 80;}); 這類篩選器來改變 WordPress 預設的圖片壓縮品質。不過這個方法影響的是 WordPress 原生的圖片處理流程,跟 WebP 外掛的壓縮是分開的,不要搞混了。
對於圖片格式轉換的更多需求,像是 SVG 轉 PNG 或其他格式互轉,可以參考之前介紹的 Free Online File Converter 這類工具。把圖片轉換好之後,再上傳到 WordPress 讓外掛做最終的 WebP 最佳化,整個流程就很順暢了。
啟用 WebP 之後難免會碰到一些狀況。以下是我被問過最多次的幾個問題,以及對應的解決方法。
轉換後圖片看起來模糊怎麼辦? 這通常是壓縮品質參數設太低造成的。進入你使用的外掛設定頁面,把壓縮品質從「高壓縮」切換到「中等壓縮」,或者把數值從 65 調高到 80。有些外掛也允許你重新轉換單張圖片,不需要整批重來。
有些圖片沒有被轉換成 WebP。 先檢查這些圖片的檔案格式是否被外掛支援。大部分外掛只處理 JPEG 和 PNG,GIF 和 SVG 通常不在自動轉換範圍內。另一個可能原因是檔案權限問題,外掛沒有寫入權限所以無法產生 WebP 檔案。可以在外掛設定頁面中找到「批次轉換」功能,手動觸發一次完整掃描。
WebP 跟快取外掛衝突了。 這是滿常見的問題。如果你同時使用了 WebP 轉換外掛和頁面快取外掛,快取外掛可能會把舊的 JPEG 版本快取住,導致 WebP 版本沒有被正確提供。解決方法是在啟用 WebP 轉換後,手動清除一次所有的頁面快取。之後每次有新的圖片轉換完成,也建議清一次快取確保一致性。
想要停用 WebP 並回復原始格式。 如果你使用的是 ShortPixel 或 Converter for Media 這類外掛,原始圖片都不會被刪除,只是多了 WebP 版本。停用外掛或關閉 WebP 功能後,網站就會自動回到使用原始格式的狀態。建議在啟用任何 WebP 方案之前,先做好 WordPress 完整備份,這樣即使出問題也能快速回復。
WebP 對網站備份有什麼影響? 啟用 WebP 轉換後,你的媒體庫會多出一批 .webp 檔案,備份容量會相應增加。一般來說增加幅度在 20-40% 左右,取決於你網站的圖片數量。如果你的備份空間有限,可以設定備份工具只備份原始格式、排除 WebP 檔案,因為這些檔案隨時可以重新產生。
保持 WordPress 網站的安全性 和穩定性是基本功夫。在進行任何圖片格式相關的大規模變更之前,確認你的網站處於健康狀態,可以減少很多不必要的麻煩。
如果你關注網頁效能領域,可能已經聽過 AVIF 這個名字。AVIF(AV1 Image File Format)是基於 AV1 影片編碼技術開發的圖片格式,壓縮率比 WebP 還要再高 20-30%。同樣一張照片,AVIF 可能只需要 WebP 的 70% 大小就能達到相同畫質。
瀏覽器支援方面,AVIF 在 2026 年的進展已經相當不錯。Chrome 85+(2020 年底)、Firefox 113+(2023 年)、Safari 18+(2024 年)都已經支援 AVIF 格式。從覆蓋率來看,已經達到 90% 以上的主流瀏覽器。但跟 WebP 的 97%+ 相比,還是有一小段差距,特別是一些較舊的裝置和系統內建瀏覽器。
WordPress 從 6.5 版本開始也加入了對 AVIF 的基本支援,處理方式跟 WebP 類似。不過相關的生態系(外掛支援、CDN 自動轉換、伺服器端處理工具)還沒有 WebP 那麼成熟。
所以現在該怎麼選?我的建議很實際:先全面採用 WebP。WebP 的工具鏈最成熟、瀏覽器支援最完整、WordPress 外掛生態也最豐富。AVIF 可以開始關注和測試,但還不需要把所有圖片都轉過去。一個比較聰明的漸進策略是:用 Converter for Media 或 ShortPixel 同時產生 WebP 和 AVIF 兩種版本,然後透過 CDN 或伺服器規則優先提供 AVIF,不支援的再退回 WebP。
圖片格式的升級不是一次性的革命,而是持續的演進。從 JPEG 到 WebP 是第一步,從 WebP 到 AVIF 是第二步。做好 網站載入速度最佳化 是一個持續的過程,不是設定好就可以放著不管。定期用速度最佳化工具檢測你的網站,確保你使用的是當下最適合的圖片格式方案。
不會。Google 從 2020 年開始就完整支援 WebP 圖片的索引和排名。事實上,因為 WebP 讓你的頁面載入更快,反而會對整體 SEO 排名產生正面影響。Google 也把 WebP 列為 PageSpeed Insights 的建議格式之一,使用 WebP 不會損害你的圖片搜尋能見度。
大多數正規的外掛都不會刪除原始檔案。ShortPixel、Converter for Media、Imagify 等外掛會在原始檔案旁邊額外產生一個 .webp 版本,原始圖片完整保留。如果你需要回復,只要停用外掛的 WebP 功能就行了。不過建議在進行任何批量操作前,先用備份工具做好完整備份。
自從 WordPress 5.8 原生支援 WebP 上傳之後,絕大多數 WordPress 佈景主題 都能正常顯示 WebP 圖片。少數非常老舊的主題可能在某些特定的圖片引用方式上會有問題,但這種情況在 2026 年已經非常少見了。如果你遇到主題不相容的問題,可以考慮換一個現代化的主題。
完全適用。WooCommerce 的商品圖片走的就是 WordPress 標準的媒體庫流程,所以任何能處理一般文章圖片的 WebP 外掛,都能自動處理商品圖片。對於電商網站來說,圖片最佳化的效果尤其明顯,因為商品頁通常包含大量高解析度圖片,轉換成 WebP 後的載入速度提升會非常顯著。
這取決於你的圖片量級。每月新增 100 張以內的網站,ShortPixel 的免費方案就綽綽有餘。超過這個數量的話,ShortPixel 的按張計費方案(每張約 0.003 美元)最彈性。Converter for Media 的免費版沒有數量限制但只有 WebP,如果需要 AVIF 支援,一次性付 30 美元升級 Pro 版也很划算。選擇時也可以搭配你的主機方案一起考量,有些主機商會附贈圖片最佳化功能。
ShortPixel 和 Converter for Media 都提供「批量轉換」功能,可以一鍵掃描整個媒體庫並把所有符合條件的圖片轉換成 WebP。如果你的免費額度不夠,可以分批處理,或者使用 Converter for Media 這類沒有數量限制的免費外掛。轉換過程在背景執行,不會影響網站正常運作,但建議在流量較低的時段執行,避免佔用過多伺服器資源。轉換完成後,記得清除快取外掛的快取,讓新的 WebP 圖片正確提供給訪客。