每個 WordPress 網站最終都會撞上同一個問題。圖片是頁面上最重的東西，編輯上傳的是相機直接輸出的檔案，而行動端分數為此付出代價。慣常的答案是裝一個圖片最佳化外掛，慣常的候選是 Smush、ShortPixel 和 Imagify。

還有第二種做法，它的運作方式完全不同，而這個比較很少被公平地做出來，因為它並不是同類產品。Cloudflare Image Transformations 不會壓縮你的圖片再把結果存起來，而是在圖片被請求的那一刻重寫它。理解這個差別，決策就完成了一大半。

真正決定選擇的區別： 外掛處理並儲存你圖片的最佳化副本。Cloudflare 按請求轉換，並把結果快取在邊緣。外掛按你擁有多少張圖片計費。Cloudflare 按你提供多少個不同變體計費。這兩種模式適合的網站截然不同。

兩種做法有何不同

傳統的最佳化外掛工作在你的媒體庫上。它取走每一張上傳的圖片，傳送到廠商伺服器或在本機處理，壓縮之後把結果寫回去。你的媒體庫最終存著最佳化過的檔案，而且常常是多個尺寸。這項工作只發生一次，在上傳時或批次執行時，結果留在你的來源伺服器上。

轉換把這件事反了過來。你的原圖原封不動。當訪客請求一張圖片時，請求經過 Cloudflare，它在途中完成縮放與格式轉換並快取結果。沒有任何東西被寫回你的媒體庫，而你隨時可以改變提供的尺寸，只需改一個 URL，而不是重新處理整個媒體庫。

這帶來一個很多人很晚才發現的實際後果。用外掛時，如果你明年決定縮圖應該換個尺寸，你要重新產生整個媒體庫。用轉換時，你改一個參數。

各家免費額度真正給了什麼

比較在這裡變得具體，而行銷頁面在這裡幫助最小。

Smush，來自 WPMU DEV，啟用安裝量超過一百萬。免費版提供無損與有損壓縮、批次最佳化和延遲載入。需要知道的限制是：超過五百萬位元組的圖片會被整個略過，而多數人真正想要的東西，也就是 WebP 和 AVIF 轉換、CDN 傳遞以及自動縮放，全都是 Pro 功能。免費版是個壓縮器，不是一條現代格式流水線。

ShortPixel 安裝量超過三十萬，採用點數模式。每處理一張圖片或縮圖消耗一點，每月贈送一百點免費額度。這聽起來很慷慨，直到你想起 WordPress 每次上傳都會產生多個縮圖尺寸，所以一張照片可能消耗四到五點。每月無限點數是 9.99 美元，一次性方案從 19.99 美元起。WebP 和 AVIF 都包含在內，進階方案還帶 CDN。

Imagify，來自 WP Media，安裝量同樣超過一百萬。免費額度是每月兩千萬位元組的圖片，大約兩百張。WebP 和 AVIF 轉換包含在所有方案裡，免費版也不例外，這是三家在格式方面最慷慨的立場。產品中不含 CDN。

Cloudflare Image Transformations 在免費方案下每月給你五千次唯一轉換，之後每千次五十美分。一次唯一轉換是指每個曆月裡圖片與參數的一個不同組合，所以把同一張縮放後的圖片提供給五萬名訪客只算一次。自動格式選擇算作一次轉換，即使一部分瀏覽器拿到 AVIF 而另一部分拿到 WebP。

哪種模式適合哪種網站

誠實的答案取決於你媒體庫的形態，而不是哪個產品更好。

媒體庫穩定的小網站。 幾百張很少變動的圖片。任何一個外掛都能從容應付，尤其 Imagify 的免費額度很可能完全涵蓋。這種情況幾乎沒有理由把 Cloudflare 加進技術堆疊。

尺寸繁多的大型目錄。 數千件商品的商店，每件都需要縮圖、格線方塊和詳情檢視。按點數計價對這種形態懲罰很重，因為每件商品的每一張縮圖都在消耗點數。轉換按不同變體計費，與你有多少商品無關，而重複請求的折扣意味著熱門頁面不會產生額外費用。

流量很大但圖片很少的網站。 轉換在這裡發光，因為計費完全不跟隨流量。一篇爆紅文章把同樣的十二張圖片提供給十萬人，仍然是十二次轉換。

持續上傳的網站。 每天新增幾十張圖片的媒體，會在幾天內耗盡 Imagify 的兩千萬位元組或 ShortPixel 的一百點。兩者都需要付費方案。Cloudflare 或許也會，這取決於每次上傳需要多少個尺寸。

網站前面沒有 Cloudflare。 那麼不遷移 DNS 的話轉換根本不是選項，外掛是務實的選擇。

沒人提起的成本

每一張比較表裡都缺了兩樣東西。

儲存空間。 在原圖旁邊保留最佳化副本的外掛會增加你的磁碟占用，有時相當可觀，因為 WordPress 本來每次上傳就產生多個尺寸，而外掛又為其中每一個新增轉換版本。在廉價的共享主機上，這偶爾會取代速度成為真正的瓶頸。

重新處理。 換佈景主題，圖片尺寸就變，以外掛為基礎的方案需要一次完整的重新產生。在大型媒體庫上這意味著數小時的伺服器負載，而人們往往正是在這一刻發現自己的主機有 CPU 限制。

這兩點都不是迴避外掛的理由。它們只是落在價格頁之外的成本，而且隨著媒體庫變大，它們越來越有利於請求時轉換這種模式。

怎麼判斷你在為什麼付費

在做選擇之前，先數清關於你自己網站的四件事。這需要一個下午，而它比任何比較表都更可靠地決定答案。

你持有多少張圖片。 是媒體庫的數量，不是頁面數量。這決定了按點數計價是否根本可行。

每張需要多少個尺寸。 檢查你的佈景主題實際請求了什麼。WordPress 預設每次上傳產生多個尺寸，而多數佈景主題只用其中兩三個。如果你的佈景主題註冊了八個自訂尺寸卻只用四個，那麼這份名單上的每一個外掛你都在為剩下四個的處理付費，用 Cloudflare 也在為它們的轉換付費。修剪這份名單，在兩種情況下都是白撿的錢。

媒體庫多久變一次。 每天上傳的媒體和去年最後一次改動的展示型網站，面對的是不同的問題。月度配額懲罰前者，對後者則毫無影響。

圖片占了多少流量。 只有 Cloudflare 的模式對此不敏感，也只有外掛的 CDN 層級會為此收費。高流量、少圖片的網站是支持轉換的最清晰案例。

把這四個數字寫下來，選擇通常會自己浮現。數錯了，你會在續約時發現，或者在一次批次重新產生於目錄中途逾時的時候發現。

兩者並用

這兩種做法並不互斥，而且組合起來往往才是合理的答案。上傳時用外掛壓縮，讓原圖不至於無謂地重；傳遞時把尺寸調整與格式轉換交給轉換來做。你會得到更小的媒體庫和更小的傳輸量，而且兩套機制不會重複彼此的工作。

不該做的是同時執行兩套都在轉換格式的系統。兩個外掛爭奪 WebP 產生會造成令人困惑的結果與被浪費的處理，而這正是圖片在桌機上顯示正常、在較舊的行動瀏覽器上卻出問題的常見原因。

如果你想在 WordPress 上自動化 Cloudflare 這一側而不必寫 Worker，我維護的外掛 會把你的圖片 URL 改寫為使用轉換，補上缺少的寬高屬性，並允許你把不希望被更動的外部來源加入白名單。它是免費的，也不會附加自己的點數制度。

關於 URL 格式與 Worker 方式的機制，請看 Cloudflare Image Transformations 。如果你同時還在決定檔案該放在哪裡，用 Cloudflare R2 託管圖片 談了儲存這一側以及它為零的傳出費用。

為你的網站得出答案

這個決定歸結為一些你在一個下午就能數清的數字：你持有多少張圖片，每張需要多少個尺寸，媒體庫多久變一次，以及 Cloudflare 是否已經在你的網站前面。這四個答案會清楚地指向其中一個選項，而搞錯它們的代價，是那種事後拆解起來很煩人的昂貴。

Mecanik 會先做 WordPress 效能稽核 ，量出圖片究竟讓你付出了多少代價，然後才建議任何改動；當修正超出安裝某個東西的範圍時，也會透過 WordPress 開發 工作承接實作。

相關文章: WooCommerce 商品圖片：分類頁為什麼這麼慢 、WooCommerce 為什麼慢：真正的四個原因 、Cloudflare R2 價格詳解 - 與 S3 和 Backblaze 的真實成本對比 、Cloudflare Email Routing - 自訂網域免費電子郵件 。

常見問題

Cloudflare Image Transformations 比 Smush 或 ShortPixel 更好嗎？ 不是更好，是不同。外掛壓縮並儲存最佳化副本，按你擁有多少張圖片計費。Cloudflare 按請求轉換，按不同變體計費。大型目錄通常更適合 Cloudflare，小而穩定的媒體庫通常更適合外掛。

哪個圖片外掛的免費額度最好？ Imagify 在免費方案裡就包含 WebP 和 AVIF 轉換，而 Smush 把這些限制在 Pro，但 Imagify 每月只給兩千萬位元組。ShortPixel 每月給一百點，不過 WordPress 縮圖每次上傳要消耗好幾點。Cloudflare 給五千次唯一轉換。

我可以同時使用最佳化外掛和 Cloudflare 嗎？ 可以，而且常常是合理的。上傳時用外掛壓縮，讓原圖不至於無謂地重，把尺寸調整與格式轉換交給 Cloudflare。避免兩套系統都轉換成 WebP，那會浪費處理並產生不一致的結果。

使用轉換需要 Cloudflare 在我的網站前面嗎？ 需要。轉換適用於透過你 Cloudflare 帳戶下的區域提供的圖片。如果你的 DNS 不在 Cloudflare，或者圖片來自帳戶之外的主機，請求會繞過這套機制，外掛才是務實的選擇。

圖片最佳化真的能改善 Core Web Vitals 嗎？ 通常可以，因為圖片往往主導頁面重量，而其中最大的一張常常正是 Largest Contentful Paint 元素。以現代格式提供尺寸正確的圖片會直接降低這個指標，但它無法解決指令碼或伺服器回應時間造成的緩慢。