圖片幾乎是 WordPress 網站最重的資源。一張沒處理過的相機原圖動輒兩三 MB，而整頁的 CSS 加 JavaScript 常常還不到它的零頭。當首屏那張大圖成為 Largest Contentful Paint 的量測對象，它的下載速度就直接決定使用者看到完整畫面的時間，也牽動 Core Web Vitals 的分數。
要讓圖片變快，方向其實只有一個：在不犧牲清晰度的前提下，把實際傳給瀏覽器的位元組壓到最低。WordPress 圖片 CDN 與即時轉檔服務就是把這件事自動化的工具，它在邊緣節點依照來訪裝置即時轉成 WebP 或 AVIF、縮到剛好的尺寸，再從最近的機房送出去。這篇會講清楚這類服務實際怎麼運作、跟傳統把 WebP 存在自己主機的外掛差在哪、裝置適配是怎麼判斷的，以及上線前後要怎麼驗證它真的有在運作。
WordPress 圖片 CDN 跟一般 CDN 有什麼不同？
一般 CDN 只負責把檔案快取到各地節點、就近送出，送出去的是什麼就是什麼；圖片 CDN 多了一層即時處理，會在送出前依照來訪者的瀏覽器與螢幕，當場改寫圖片的格式、尺寸與壓縮率。
換句話說，傳統 CDN 解決的是「距離」問題，圖片 CDN 同時解決「距離」和「這張圖對這台裝置來說太大」的問題。同一個原始檔，桌機收到的可能是 1600 像素寬的 AVIF，手機收到的是 750 像素寬的 WebP，而你的媒體庫裡始終只放一份原圖。
這層即時處理通常包含三件事：依瀏覽器支援度挑格式（支援 AVIF 就給 AVIF，否則退回 WebP，再不行才回到 JPEG）、依版面與螢幕解析度縮放尺寸、依設定套用有損或無損壓縮。處理完的結果會被快取在邊緣節點，後續同樣的請求就直接命中快取，不必每次重算。
即時轉檔服務是怎麼把原圖變成 WebP 或 AVIF 的？
它靠的是瀏覽器在每個請求裡都會帶的 Accept 標頭。瀏覽器會在這個標頭裡宣告自己看得懂哪些格式，服務讀到之後就知道該回哪種格式，這個過程叫做內容協商。
實際流程大致是這樣。讀者打開頁面，瀏覽器對某張圖發出請求，請求標頭裡寫著 Accept: image/avif,image/webp,image/*。邊緣節點收到後，先看快取裡有沒有對應這個格式與尺寸的版本；沒有的話，就回源去你的 WordPress 主機抓原圖，當場轉成對應格式、縮到請求的尺寸，存進快取，再回給瀏覽器。下一個用同樣裝置的讀者進來，就直接吃快取，毫秒級就送出。
這裡有個容易混淆的點：服務送出的是 WebP 或 AVIF 的位元組，但網址的副檔名不一定會跟著改。像 Jetpack 的 Site Accelerator 就會對支援的瀏覽器送出 WebP 資料，但網址仍維持原本的 .jpg。判斷有沒有真的轉檔，不能只看網址結尾，要看回應內容的實際類型。
格式之間的取捨也值得先有概念。WebP 同時支援有損與無損壓縮，多數情況下檔案比同畫質的 JPEG 或 PNG 小，瀏覽器支援度已經很高。AVIF 的壓縮率又比 WebP 更進一步，畫質保留也好，缺點是編碼較慢、舊瀏覽器支援尚未普及。所以即時轉檔服務的常見策略，就是讓邊緣節點按照 Accept 標頭逐一往下退，永遠送出該瀏覽器吃得下的最現代格式。
圖片 CDN 跟本機 WebP 外掛該怎麼選？
先給結論：如果你的網站是一般 WordPress 佈景主題、編輯都從媒體庫上傳圖片，兩種做法都可行；差別在於轉檔運算放在哪、檔案存在哪、以及你想要多少控制權。
本機外掛（例如 ShortPixel Image Optimizer、EWWW、Imagify）的做法是：圖片上傳後，在你自己的主機上預先產生 WebP 或 AVIF 版本存起來，讀者來訪時由佈景主題或伺服器規則決定要送哪一個檔。WordPress 6.1 之後核心已內建上傳時自動轉 WebP 的能力，這也屬於本機派。它的好處是檔案都在自己手上、不依賴第三方服務、沒有額外的流量計費；代價是會佔用主機儲存空間（每張圖會多出好幾個衍生檔），而且尺寸版本是上傳當下就固定的，事後想換斷點得重跑一次批次。
圖片 CDN（例如 Optimole、ShortPixel Adaptive Images、BunnyCDN 搭配 Optimizer、ImageEngine）則把轉檔搬到雲端邊緣，原圖留在你的媒體庫，所有格式與尺寸都在邊緣節點即時產生並快取。它的好處是裝置適配做得最徹底、不佔你的主機資源、全球節點就近送圖；代價是要依流量或來訪數計費，而且你多依賴一層外部服務，那層出狀況時圖片就會受影響（多數服務在 CDN 異常時會退回送原圖）。
選擇可以這樣判斷：
- 流量不大、想自己掌握檔案、不想多付月費：用本機外掛或 WordPress 內建 WebP，搭配一個一般的快取／CDN 即可。
- 圖片很多、讀者來自各地、在意行動裝置 LCP：用圖片 CDN，讓邊緣替你處理裝置適配。
- 無頭（headless）架構、圖片在自訂前端或物件儲存裡：用通用型圖片 CDN（如 BunnyCDN、ImageKit、Imgix）比硬塞 WordPress 專用外掛乾淨。
不論選哪一派，有一條鐵則：同一個職責只交給一個工具。讓兩個外掛同時去壓縮、改寫網址或做延遲載入，是 WordPress 圖片出問題最常見的原因，會出現重複壓縮、網址被改寫兩次、延遲載入套錯張的狀況。一個圖片優化工具當主角，再配一個負責 HTML／CSS／JS 的頁面快取外掛，各管各的，就單純很多。
裝置適配到底在適配什麼？
裝置適配的核心，是讓每台裝置只下載「對它而言剛好夠清楚」的尺寸，不多浪費一個位元組。要判斷剛好，服務要同時看三個變數：版面給這張圖多寬、螢幕的裝置像素比（DPR），以及瀏覽器支援哪種格式。
第一個變數來自原生的 srcset 與 sizes 機制。srcset 列出同一張圖的多種寬度版本，sizes 告訴瀏覽器這張圖在不同視窗寬度下會佔多大版面，瀏覽器據此挑出最小但仍夠清楚的那一張。一個典型的內容圖會準備 400、800、1200 三種寬度，全幅的首圖再多備 1600 或 2000 寬。一般建議用寬度描述子（如 800w）而不是像素密度描述子（如 2x），因為前者在各種 DPR 下挑圖的結果更可預測。
第二個變數是裝置像素比。高解析螢幕（例如 Retina 或多數現代手機）一個 CSS 像素對應到兩三個實體像素，所以一塊版面上看起來 400 像素寬的圖，在 DPR 為 2 的螢幕上其實要 800 實體像素才不會糊。圖片 CDN 會自動把版面寬度乘上 DPR，挑出對應的實體尺寸，這也是它比手動切圖省心的地方。
第三個變數就是前面講的格式協商。三件事合起來，服務才能對「桌機、DPR 1、支援 AVIF」送出一個版本，對「手機、DPR 3、只支援 WebP」送出另一個版本。
本機外掛也能做 srcset，但尺寸版本是上傳時就固定的固定集合；圖片 CDN 的差別在於它可以在邊緣即時生成任何請求到的尺寸，等於把切圖這件事完全自動化。
衡量這件事做得對不對，Lighthouse 有個「適當調整圖片大小」的檢測，它比的是圖片的原生尺寸（檔案實際存著的像素）跟算繪尺寸（瀏覽器實際畫出來的像素）差多少。一般的 <img> 浪費超過約 4KB 就會被標記，用了響應式語法的圖片門檻放寬到約 12KB。差距越小，代表尺寸給得越剛好。
上線前要先確認哪些事？
換用圖片 CDN 不是裝完外掛就沒事，動到圖片網址的東西都有連帶風險，務必先在能還原的狀態下逐項檢查。
切換前的準備動作：
- 先備份整站，至少確保媒體庫原始檔都還在，不要讓任何服務刪掉原圖。
- 關掉其他會處理圖片的外掛，避免兩個工具搶著壓縮或改寫網址。
- 清掉頁面快取與物件快取，否則你看到的可能是舊的 HTML，圖片網址根本還沒換。
- 能在測試環境先開就先開，至少在正式站開啟後立刻逐頁檢查。
要檢查的頁面別只看首頁，首頁、一篇文章、一個彙整頁、一個 WooCommerce 商品頁都要看過，因為佈景主題在不同版型載入的圖片尺寸不一樣。
上線後怎麼確認它真的有在運作？
不要只看外掛後台的儀表板數字，要直接用瀏覽器的開發者工具看實際送出的內容。最快的方法是打開 Chrome 開發者工具，切到 Network 分頁、用 Img 過濾，重新整理頁面，逐項核對。
關鍵要看這幾點：
- 圖片是不是從 CDN 網域載入的：網址主機名稱應該變成服務的網域，而不是你原本的主機。
- 第一次之後是不是命中快取：看回應標頭，重複請求應該出現快取命中的標記。
- 整頁圖片傳輸量有沒有明顯下降：把 Network 的傳輸大小加總，跟切換前比。
- 格式有沒有真的換成 WebP 或 AVIF：看回應的內容類型，別只看網址副檔名。
- 首屏那張 LCP 圖有沒有被誤設成延遲載入：LCP 圖一旦被 lazy load，反而會拖慢首屏，它應該優先載入。
srcset還在不在、width與height有沒有保留：尺寸屬性消失會讓版面在載入時跳動，推高 Cumulative Layout Shift。
如果換了之後速度沒改善，常見原因有幾個：外掛根本沒在改寫網址、快取外掛還在送舊的 HTML、WebP／AVIF 沒被啟用、佈景主題用 CSS 背景圖的方式繞過了改寫範圍，或是原圖本身就大到所有衍生檔都還是很重。圖片 CDN 能放大效果的前提，是你的佈景主題本來就給它合理的輸入。
行動裝置的 LCP 建議用 PageSpeed Insights 另外量一次，因為實驗室數據要等真實使用者的場域資料累積後才會反映在 Search Console，別只憑單次測試就下結論。
收費方式怎麼看，會不會踩到隱形成本？
這類服務的收費邏輯不只一種，看懂計費單位比看月費數字更重要，因為不同模型在你網站成長後的帳單差很多。常見的計費方式有三種。
第一種是按流量（GB）計費，像 BunnyCDN 這類，圖片傳了多少 GB 就收多少，通常還要再加一筆固定的圖片處理月費。它的好處是成本跟著實際用量走、可預測，媒體庫變大也不會突然爆帳，因為處理費是固定的。
第二種是按來訪數計費，像 Optimole，不看你優化了幾張圖、也不看流量，而是算每月的不重複來訪人數。這種模型適合討厭算流量的人，但要留意它計算來訪的方式可能跟你的網站分析工具不一樣，而且免費額度通常不大（常見落在每月數千次來訪），流量一成長就得升級。
第三種是信用點或無限方案，像 ShortPixel 用信用點數（一點對應一張優化），也提供含一定 CDN 流量的方案。重點是看清楚「優化額度」跟「CDN 流量額度」是分開算的兩件事，CDN 流量一旦用完，服務可能就改送未優化的原圖，速度當場打回原形。
要避免隱形成本，記得確認這幾件事：免費額度的單位與上限到底是流量、來訪還是張數；超量之後是降級送原圖還是直接收費；AVIF 與自訂網域是不是要更高方案才有；以及這層服務萬一停掉，圖片會不會跟著掛掉。把計費單位跟你網站的成長曲線對齊，再決定哪種模型對你最划算。
把圖片變快，該從哪一步開始動？
WordPress 圖片 CDN 與即時轉檔服務能做的，是把「依裝置送出剛好大小的現代格式圖片」這件事自動化，省去手動切圖、手動轉檔的工夫，並用就近的邊緣節點縮短傳輸距離。它對 Core Web Vitals、尤其是 LCP 的改善通常很直接，前提是設定正確、而且你的佈景主題本來就給它合理的輸入。
實務上的順序可以這樣排：先把原圖尺寸控制在合理範圍，別把超大原圖直接丟給服務去救；接著依網站規模選一派，流量小就用本機外掛或內建 WebP，圖片多又重視行動體驗就上圖片 CDN；切換時守住「一個職責一個工具」，正式上線後立刻用開發者工具逐項驗證格式、尺寸與快取都對。把這三步走完，圖片這塊就不再是拖累速度的那一個瓶頸。