網站圖片優化

圖片優化是 WordPress 性能裏最“高回報”的一項：同樣的頁面結構、同樣的主題，只要圖片體積、尺寸、格式、交付方式做對，加載體驗往往立刻提升。

但圖片優化也最容易讓人“越弄越亂”，原因不是技術太難，而是信息太碎：
你看了幾篇文章，知道要“壓縮”“WebP/AVIF”“懶加載”，再看插件介紹又説“每月免費100 credits”“免費 20MB”“每張圖 1 credit”，結果越看越糊塗——到底免費夠不夠？扣費怎麼扣？是不是你理解錯了“同一個東西”？以及最關鍵的：你做完之後到底有沒有真的生效？

這篇文章只做三件事：

1. 給你一條可執行的路線圖（先做什麼、後做什麼）
2. 把你要選的方案講清楚（免費/付費到底差在哪、各自適合誰）
3. 把最常見的坑提前寫出來（避免你做完還要到處搜索排查）

1. 底層：WordPress 自帶什麼，不自帶什麼

如果你不先搞懂 WordPress 核心已經做了什麼，很容易出現兩種情況：

• 該享受的“免費能力”沒用上，反而花時間/花錢重複造輪子
• 以為 WordPress 會“自動把舊圖都轉 WebP/AVIF”，結果發現並不會

WordPress 核心已經內置了這些關鍵能力：

• 響應式圖片（srcset/sizes）：從 WordPress 4.4 起，核心會為圖片輸出 srcset 與 sizes，並利用上傳時生成的多尺寸圖片，讓瀏覽器按屏幕條件選擇更合適的資源加載。
• 原生懶加載：WordPress 5.5 起默認對圖片啓用原生懶加載，使用 HTML 標準 loading 屬性實現。
• 支持上傳 WebP：WordPress 5.8 起可以像 JPEG/PNG 一樣上傳並使用 WebP（前提是主機環境支持 WebP）。
• 支持上傳 AVIF：WordPress 6.5 起可以像 JPEG/PNG 一樣上傳並使用 AVIF（同樣依賴主機環境支持）。

但注意：
“支持上傳/使用” ≠ “自動轉換/自動交付”。
也就是説：就算你已經是 WP 6.5，你的媒體庫裏那些 JPG/PNG 不會自己變成 WebP/AVIF；你也不會自動獲得“按瀏覽器能力輸出 AVIF/WebP、並對不支持的瀏覽器回退到原圖”的完整鏈路——這部分通常需要插件或服務補齊。

2. 路線圖：圖片優化按 5 步走

做什麼、為什麼、做到什麼算合格、典型坑是什麼。

2.1 先把“尺寸”做對（最容易被忽略，但收益最大）

很多站慢並不是壓縮沒做，而是下載了遠超顯示區域的大圖：
例如頁面實際只顯示 900px 寬，你卻讓訪客下載 3000px 原圖，瀏覽器只是“下載完再縮小顯示”。這會浪費帶寬、增加解碼時間、拖慢首屏。

WordPress 4.4+ 的響應式圖片機制（srcset/sizes）正是為了解決這個問題。

做到什麼算合格：

• 手機打開頁面時，下載的圖片尺寸應明顯比桌面更小
• 同一張圖在不同設備上加載的資源大小不同（而不是永遠下載原圖）

最常見的坑：

• 有的主題/構建器把圖當作 CSS 背景圖、或用自定義方式輸出，可能繞開 srcset，導致一直下大圖
• 你用外鏈圖牀、第三方圖片塊，也可能繞開媒體庫生成的多尺寸體系

---

2.2 壓縮（把 KB 降下來，但不要把質量“壓壞”）

壓縮的核心不是“越小越好”，而是“肉眼幾乎看不出差異，但體積下降明顯”。

規則如下：

• 照片/實拍（人物、產品、風景）：優先有損壓縮（收益最大）
• 界面截圖/文字多的圖片：壓縮要更保守，避免文字發虛
• Logo/圖標：優先 SVG 或謹慎無損（有損很容易邊緣糊）

做到什麼算合格：

• 大多數頁面圖片體積明顯下降
• 不出現明顯的噪點、糊邊、色塊斷層、文字變糊

---

2.3 WebP / AVIF（格式策略：同等清晰度更小）

WordPress 已支持上傳 WebP（5.8）與 AVIF（6.5）。
但要把“下一代格式”真正用起來，通常要解決兩件事：

1. 歷史媒體庫如何批量轉換（否則你只優化了“以後上傳的新圖”）
2. 是生成副本，還是替換原圖（這是風險分水嶺；後面會重點講 Plus WebP 的“替換並刪除原圖”）

推薦寫法：

• WebP：一般作為默認首選（兼容性更穩）
• AVIF：更進一步的壓縮方向，適合大圖/首屏大圖/相冊圖（但更依賴環境支持）

---

2.4 懶加載要用對（不要一刀切）

WordPress 5.5 起默認懶加載圖片。
它能減少初始渲染時的帶寬佔用：

• 懶加載適合“屏外資源”
• 首屏最關鍵那張大圖（很多時候是首屏關鍵圖）往往不適合被延後加載

---

2.5 交付層：CDN / 圖片 CDN

壓縮、尺寸、格式解決的是“文件更小更合適”。
但如果圖片總是從源站遠距離拉取，網絡延遲仍會明顯影響體驗。這時就需要“交付層”的方案（CDN/圖片 CDN）。

兩個典型方向：

• Cloudflare Polish：Cloudflare 文檔介紹了 Polish 的壓縮方式（無損/有損/WebP），並提到用 format=auto 允許使用 WebP/AVIF 格式。
• Jetpack Site Accelerator：Jetpack 文檔説明它會優化圖片並與靜態資源一起通過其網絡分發。

圖片優化負責變小變合適，CDN 負責交付更近更穩

3. 選型：只走兩條主路線

圖片優化最常見的失敗，不是“沒裝插件”，而是裝了太多插件導致重複處理：
A 在壓縮、B 也在壓縮；A 在轉 WebP/AVIF、B 也在轉；A 在改 URL、B 又做重寫——最後你自己都説不清站裏現在到底發生了什麼。

規則：

只走一條路線：要麼全免費本地，要麼雲壓縮三選一。

• 路線 A（全免費本地）：Plus WebP or AVIF + EWWW Image Optimizer（或者只選擇其中一個）
• 路線 B（雲壓縮三選一）：ShortPixel / Imagify / TinyPNG

---

3.1 路線 A：全免費本地（Plus WebP or AVIF 或 EWWW）

這條路線的特點是：

• 你不依賴“按月額度/按張計費”的第三方壓縮服務（當然有些功能也可能提供可選服務）
• 代價是：批量處理可能更吃服務器 CPU/IO，需要你更關注“策略和風險”

3.1.1 Plus WebP or AVIF：核心是“生成/替換”，它不是傳統意義的“壓縮工具”

• 生成全量圖片時：原始圖片文件 ID 會被 WebP/AVIF 覆蓋、原始文件會被刪除，內容中的 URL 也會被替換。
• 插件提供 WP-CLI 命令，並提醒：文件多時用 WP-CLI 更可靠。

這意味着：它不是“悄悄幫你生成一份 WebP”，而可能是一次資產遷移（尤其你開啓“替換並刪除原圖”相關選項時）。

兩種模式的差別

模式 1：保留原圖 + 生成 WebP/AVIF 副本（更穩）

• 優點：遇到兼容問題更容易回退
• 代價：磁盤佔用會上升（原圖 + 新格式 + 多尺寸縮略圖）

模式 2：替換並刪除原圖（更激進）

• 優點：磁盤不會膨脹得那麼快；站內引用直接變成新格式
• 風險：你在“改資產 + 改引用”，遇到兼容問題排查成本會更高（尤其當某些外部系統或主題邏輯依賴原文件名/路徑/格式）

Plus WebP or AVIF 的典型坑

1. 做完全庫替換後，某些頁面圖片顯示異常
   原因通常不是“圖片壞了”，而是 URL 替換、緩存、縮略圖策略等鏈路裏某環沒對上。
2. 縮略圖數量越多，改動範圍越大
   WordPress 上傳一張圖會生成多個尺寸；主題/插件還可能增加更多尺寸。全量替換意味着你可能在改動一套很龐大的文件集合。
3. 只做格式遷移，不等於體積一定最小
   WebP/AVIF 一般更小，但“尺寸策略”和“壓縮策略”仍然很關鍵。不要把 Plus WebP 當成“一鍵變快”。

---

3.1.2 EWWW Image Optimizer：免費本地壓縮的代表

EWWW 插件頁的定位非常明確：

• 它可以在你的服務器上使用一系列工具進行優化（jpegtran、optipng、pngout、pngquant、gifsicle、cwebp 等）
• 如果你需要更高壓縮或更省 CPU，也可以把耗 CPU 的處理卸載到其服務器（可選）。

EWWW 在路線 A 裏應該承擔什麼角色？

如果你用 Plus WebP 做“格式遷移/替換策略”，那麼 EWWW 更適合承擔：

• 壓縮與體積優化（尤其是 JPG/PNG 等原始資源的減重）
• 批量優化歷史媒體庫（以“體積下降”為目標，而不是“替換 URL”）

EWWW 的典型坑

1. 批量優化時服務器負載升高
   因為本地壓縮就是吃 CPU/IO。解決思路不是“別用”，而是“分批、低峯、必要時選擇卸載/雲方案”。
2. “生成了 WebP”不等於前台一定在出 WebP
   很多插件都存在這個誤會：生成是一回事，交付策略（重寫、picture 標籤、緩存命中等）是另一回事。
3. 和別的插件重複做同一件事
   如果你走路線 A，就儘量別再疊加 ShortPixel/Imagify/TinyPNG 之類雲壓縮；如果你走路線 B，就不要再開 Plus WebP 的替換邏輯。核心原則：一條路線走到底。

---

3.2 路線 B：雲壓縮三選一（ShortPixel / Imagify / TinyPNG）

這條路線適合“想省服務器資源、想更省心做批量、接受按額度/按量計費”的人。
但云壓縮最容易產生誤解的點是：免費額度並不是“免費張數”那麼簡單。縮略圖尺寸數量、是否生成 WebP/AVIF、是否反覆重壓，都會顯著影響消耗。

下面會説明：免費/收費怎麼回事、額度怎麼扣、最容易踩什麼坑、適合什麼站點類型。

---

3.2.1 ShortPixel：100 free credits/月，但 credits 會被縮略圖與 WebP/AVIF 放大消耗

免費/付費怎麼回事

ShortPixel 插件介紹明確寫到：

• 每月 100 個免費 credits
• 也有“額外的無限月度 credits”（插件頁給出了對應價格信息）
• 也提供“永不過期的一次性 credits 包”（並給出起始價格信息）

提示：

• 免費：每月給一定 credits，用於輕量站點或測試
• 一次性包：適合“媒體庫很大、想一次性清庫存”的站點（買一次用完為止，通常不會過期）
• 月度/無限：適合持續更新圖片、長期穩定優化的站點

ShortPixel 官方 KB 對“一次性包 vs 無限月度”也給了清晰解釋：無限月度是按月（或按年）付費，提供無限 credits，並帶固定的 CDN 配額；一次性 credits 不會過期，讓你更可控地按需使用。

最關鍵：ShortPixel 的 credits 怎麼算？

ShortPixel 官方文檔 KB 講得非常直白：

• WordPress 上傳一張圖片會生成多個縮略圖；
• 每個縮略圖的優化都會算一個 credit；
• 如果你選擇生成 WebP 或 AVIF，每個原圖與縮略圖的 WebP/AVIF 版本會額外再消耗一個 credit；
• 你可以排除某些縮略圖不優化以減少 credits 消耗。

credits 示例：

假設你上傳 1 張圖片，主題/插件生成了 8 個縮略圖：

• 只優化原圖+縮略圖：1（原圖）+ 8（縮略圖）= 9 credits
• 如果還要生成 WebP/AVIF：上面 9 個每個再多一個 next-gen 版本 → 再 +9 credits
  也就是説，你以為“1 張圖”，實際可能消耗接近“2 位數 credits”。

所以：“免費 100 credits”並不等於“免費 100 張圖”。

ShortPixel 最常見的坑

1. 免費 100 credits 很快用完
   根因：縮略圖多 + 生成 WebP/AVIF 額外 credits。
   建議：

• 先評估站點縮略圖數量
• 排除不必要的縮略圖尺寸（只優化真正會用到的尺寸）
• 先確定壓縮策略再批量跑，避免反覆試錯消耗

2. 同時疊加別的轉格式插件
   如果你又開 Plus WebP 替換，又讓 ShortPixel 生成/插入 next-gen 標籤，邏輯會疊加，排查變難。路線 B 就讓 ShortPixel 單獨負責。
3. 以為裝了就一定“前台在出 WebP/AVIF”
   ShortPixel 插件頁提到它能轉換 WebP/AVIF，並能把 next-gen 圖片加入前台頁面（例如通過標籤方式）。
   但做完仍然要驗證效果。

---

3.2.2 Imagify：免費 20MB/月；按“原圖大小 + 縮略圖數量”扣配額，重壓會重複扣

免費額度與定位

Imagify 官方價格頁寫得很明確：免費賬户每月 20MB 配額。
它的插件頁也明確它能壓縮、調整尺寸，並轉換 WebP/AVIF。

配額怎麼扣？

Imagify 官方文檔 “How is Quota Usage Calculated?” 把扣費機制拆得很清楚：

• 縮略圖數量會影響消耗：比如你有 10 個縮略圖尺寸，優化 1 張圖片會變成優化 11 張（原圖 + 10 個縮略圖），這些都會貢獻配額消耗。
• 按原始文件大小扣配額：例如你把一張 100KB 的圖片發送給 Imagify，就會從配額中扣 100KB。
• 更改壓縮級別並重新優化，會再次消耗配額。
• 同一個 API Key 可用於多個站點，但配額會在這些站點之間共享。

這就是 Imagify 的“核心理解方式”：
它更像流量包：你送多大，它扣多大；縮略圖越多扣得越多；你反覆重壓會重複扣。

容易看懂的 Imagify 配額示例

假設你上傳一張原圖 800KB，站點生成 8 個縮略圖。

• Imagify 優化時會把“原圖 + 8 個縮略圖”都納入（如果你選擇全部優化），也就意味着這一次動作會消耗接近“所有這些文件的原始大小總和”的配額。
  這就是為什麼有些站點覺得“20MB 很快用完”：不是 Imagify 不夠用，而是你每次上傳的圖片太大、縮略圖太多、並且你可能還反覆試壓縮級別。

Imagify 最常見的坑

1. 免費 20MB 不夠做“全站歷史清庫”
   20MB 通常更適合測試與輕量更新；如果你媒體庫本來就很大，一次性清庫很可能要升級。
2. 反覆調整壓縮級別導致配額重複消耗
   Imagify 明確説明重新優化會再次消耗配額。
   建議你在本頁就把“策略”寫清楚：

• 先用少量圖片確定壓縮級別與觀感
• 確定策略後再批量跑
  避免在全庫上反覆試錯

3. 多站共用 API Key 導致配額“莫名其妙變少”
   如果你把同一個 API Key 用在多個站，配額會共享。
   所以在團隊/多站場景，最好明確：哪些站共用，哪些站單獨用，以免預算不可控。

---

3.2.3 TinyPNG（Tiny Compress Images）：免費 500 credits/月；轉 WebP/AVIF 會“每個尺寸額外扣 1 credit”

免費額度與它的計費思路

TinyPNG 的 WordPress 插件頁寫得非常清楚：

• 每月 500 credits 免費
• 在“常規 WordPress 安裝”裏，大概能壓縮 約 100 張圖片/月
• 但如果啓用 AVIF 或 WebP 轉換：每個圖片尺寸會額外消耗一個 credit，因此大概只能壓縮並轉換 約 50 張圖片/月（具體取決於你有多少縮略圖尺寸）。

同時，Tinify（TinyPNG/TinyJPG 的開發者）也在其 API 定價頁寫明：註冊即可獲得每月 500 次免費壓縮；超過後是按成功壓縮次數計費、沒有強制訂閲。

用一句話概括 TinyPNG 的理解方式：
它按 credits 計數；縮略圖尺寸越多、你開啓 WebP/AVIF 越多，就越快消耗 credits。

容易看懂的 TinyPNG credits 示例

假設你站點對每張圖片生成 8 個縮略圖尺寸：

• 僅壓縮：原圖 + 8 個縮略圖 → 需要 9 credits
• 若開啓 WebP/AVIF 轉換：每個尺寸還要額外扣一次 credit → 可能接近翻倍
  這正對應插件頁的説明：開啓轉換後免費額度大約從“100 張/月”變成“50 張/月”。

TinyPNG 最常見的坑

1. 以為 500 credits=500 張圖
   不是。它按“圖片尺寸/變體”消耗。插件頁已經明確提醒“轉換會對每個圖片尺寸額外扣 1 credit”。
2. 主題/電商插件生成尺寸太多，免費額度下降很明顯
   尺寸越多，credits 越容易被放大消耗。
3. 啓用轉換後發現額度突然不經用
   這不是 bug，是它的計費機制。
   策略建議：

• 如果免費階段主要用於壓縮減重，可以先只壓縮，等你確認站點結構穩定、確實需要 next-gen，再開啓轉換

4. 分場景推薦：不同類型站點怎麼選

同樣是 WordPress，內容站、電商、作品集、會員站的“圖片壓力點”並不一樣。

4.1 內容站/博客（文章圖多、更新頻率中等）

優先級建議：

1. 尺寸策略（Step 1）
2. 壓縮（Step 2）
3. WebP（Step 3）

更適合的路線：

• 想省心：路線 B 三選一（ShortPixel / Imagify / TinyPNG）
• 想免費：路線 A（Plus WebP + EWWW），但建議先從“保守模式（不刪除原圖）”開始評估風險

典型坑：

• 文章頁首圖很大，懶加載策略不當會拖慢首屏

4.2 電商/產品站（縮略圖多、圖片變體多、穩定性第一）

電商最容易出問題的地方不是“壓縮效果不好”，而是“優化後某些尺寸不對、縮略圖缺失、前台組件取不到圖”。

優先級建議：

1. 先穩：壓縮策略保守一點、不要一上來就做全庫替換
2. 評估縮略圖尺寸：電商主題通常生成更多尺寸，額度消耗會放大（ShortPixel/TinyPNG 特別明顯）
3. 先做小範圍驗證再批量（非常關鍵）

更適合的路線：

• 路線 B 往往更省心：ShortPixel/Imagify/TinyPNG 都能批量，關鍵是你要理解額度機制，提前評估成本
• 路線 A 也可以，但要更謹慎對待 Plus WebP 的“覆蓋 ID/刪除原圖/替換 URL”行為：這屬於資產遷移，不建議一上來就全量替換。

4.3 作品集/攝影站（單圖質量敏感、圖片大、對觀感要求高）

優先級建議：

1. 尺寸策略（顯示區域控制）
2. 壓縮策略（寧可大一點，也不要把細節壓壞）
3. WebP/AVIF（大圖場景收益很明顯，但要驗證觀感）

更適合的路線：

• Imagify：按“原圖大小”扣配額，這種站點更容易做“預算可控”（你知道每張大圖大概扣多少），但要避免反覆重壓。
• ShortPixel：如果縮略圖尺寸不多，credits 也很直觀；但如果你生成很多尺寸+next-gen，credits 消耗會放大，需要提前規劃。

5. 額度/計費對比：把“免費夠不夠用”説透

到底選哪個更划算、免費能撐多久？

5.1 三種扣費模型

• ShortPixel（credits）：按“原圖+縮略圖數量”計 credits；生成 WebP/AVIF 會對每個對應版本額外扣 credit。
• Imagify（MB 配額）：按“原始文件大小”扣配額；縮略圖越多扣得越多；重壓會再次扣。
• TinyPNG（credits）：每月 500 credits；啓用 WebP/AVIF 轉換會對每個圖片尺寸額外扣 credit。

5.2 快速估算方法

你可以這樣估算：

1. 隨便找一張“你常上傳的原圖”，看它大概多大（比如 300KB / 1MB / 3MB）
2. 看你站點大概生成多少縮略圖尺寸（比如 5 個 / 10 個 / 20 個）
3. 決定你是否要生成 WebP/AVIF（是/否）

然後用下面的“心算”理解消耗：

• ShortPixel：每張圖≈（1 + 縮略圖數）credits；如果生成 WebP/AVIF，≈再翻一倍（因為 next-gen 版本也要 credit）
• Imagify：每張圖≈（原圖大小 + 各縮略圖大小）扣配額；改壓縮級別重壓會再次扣
• TinyPNG：免費 500 credits；如果你站點每張圖產生很多尺寸，且啓用轉換，免費張數會明顯下降（插件頁給了“約 100 張/月”與“約 50 張/月”的直觀預期）

6. 風險提示

風險 1：不要讓多個插件重複做同一件事

這是最常見的“災難源頭”

• 路線 A：Plus WebP or AVIF + EWWW（兩者分工，不要同時做同類轉換與交付，或者只安裝其中一個）
• 路線 B：ShortPixel / Imagify / TinyPNG 三選一（選一個負責壓縮與 next-gen）

風險 2：Plus WebP 的“覆蓋 ID / 刪除原圖 / 替換 URL”屬於資產遷移

再次強調：Plus WebP 的描述明確寫到全量生成時會覆蓋原圖 ID、刪除原文件，並替換內容 URL。
這意味着它不是“可隨時撤回的小設置”，而是一次資產層面的改動。

建議的策略應該是：

• 先小範圍測試（幾十張～幾百張）
• 確認前台顯示、縮略圖、緩存更新都正常
• 再考慮全庫處理

風險 3：雲壓縮“免費額度”的真實消耗取決於縮略圖數量與 next-gen 選擇

• ShortPixel：縮略圖和 next-gen 會顯著影響 credits
• TinyPNG：啓用 WebP/AVIF 會對每個圖片尺寸額外扣 credit
• Imagify：按原圖大小扣，縮略圖越多扣越多，重壓會重複扣

風險 4：“生成了 WebP/AVIF”不等於“前台在交付 WebP/AVIF”

很多人做完轉換後感覺“沒變快”，根因是前台仍在出 JPG/PNG（緩存/重寫/標籤/瀏覽器協商等任一環沒對上）。

7. 做完怎麼驗證有沒有生效

4 個非常簡單的驗證點：

1. 同一頁面刷新第二次，加載是否更穩定更快（緩存與優化是否起作用的體感）
2. 手機與桌面加載的圖片尺寸是否明顯不同（響應式 srcset/sizes 是否發揮作用）
3. 抽查幾張圖：是否出現 WebP 或 AVIF 文件/資源（站點是否真的在用 next-gen）
4. 抽查幾張圖：放大看是否明顯糊、文字是否發虛（壓縮質量是否過頭）

如果這四條都符合，説明你選的路線已經跑起來了。接下來再去做 CDN “交付層”，整體會更穩。

8. 行動建議

1. 先選路線：

• 想盡量免費：Plus WebP or AVIF + EWWW（或者只安裝其中一個）
• 想省服務器資源、按額度付費更省心：ShortPixel / Imagify / TinyPNG 三選一

2. 先做小範圍測試（幾十張）
3. 確認沒問題再批量
4. 需要進一步提升交付穩定性：閲讀 CDN 加速

常見問題

1. 我到底要裝幾個插件？能不能都裝上？

儘量只走一條路線。

• 路線 A：Plus WebP or AVIF + EWWW Image Optimizer（或者只安裝其中一個）
• 路線 B：ShortPixel / Imagify / TinyPNG 三選一
  同一個站裏同時讓多個插件做“壓縮/轉 WebP/AVIF/改 URL/交付重寫”，最容易越弄越亂、也最難排查。

2. WordPress 不是已經支持 WebP/AVIF 了嗎？我還需要插件嗎？

需要分清：
“支持上傳/使用” ≠ “自動轉換/自動交付”。
WordPress 6.5 也不會自動把舊的 JPG/PNG 批量轉成 WebP/AVIF，也不會自動幫你做“按瀏覽器能力輸出 AVIF/WebP 並回退”的完整鏈路。要想讓歷史媒體庫也跟上，通常需要插件或服務補齊。

3. 圖片優化裏，最“高回報”的到底是哪一步？

通常是 先把“尺寸”做對（srcset/sizes）。
很多站慢不是因為沒壓縮，而是頁面只顯示 900px 卻讓用户下載 3000px 原圖。壓縮能省 KB，但“尺寸不對”會讓你白白多下幾倍的數據。

4. 我怎麼確認現在加載的是不是“更小的那張”，而不是永遠下原圖？

看兩個現象：

• 手機打開頁面時，下載的圖片尺寸明顯比桌面更小
• 同一張圖在不同設備加載的資源大小不同
  如果永遠下載原圖，常見原因是主題/構建器把圖當作 CSS 背景圖或自定義輸出，繞開了媒體庫的多尺寸與 srcset。

5. “生成了 WebP/AVIF”是不是等於前台一定在出 WebP/AVIF？

不等於。
生成只是“文件層”完成了；前台是否真的交付 WebP/AVIF，還取決於重寫、picture 標籤策略、緩存是否命中、瀏覽器協商是否生效等。你做完一定要“抽查幾張圖的資源類型”。

6. Plus WebP or AVIF 到底危險在哪？我能不能一鍵全庫跑？

它的風險點不是“壓縮”，而是資產遷移級別的改動：

• 全量生成時可能覆蓋原始圖片文件 ID、刪除原始文件，並替換內容中的 URL。
  所以不建議一上來就全庫替換：先小範圍測試（幾十張～幾百張）+ 有可用備份，再考慮全庫處理。

7. Plus WebP 的兩種模式怎麼選：保留原圖 vs 替換並刪除原圖？

簡單理解：

• 模式 1：保留原圖 + 生成 WebP/AVIF 副本（更穩）：方便回退，但磁盤會漲（原圖 + 新格式 + 多尺寸縮略圖）。
• 模式 2：替換並刪除原圖（更激進）：磁盤不易膨脹，但你在“改資產 + 改引用”，出現兼容問題排查成本更高。
  站點越複雜（電商/多插件/多尺寸），越建議從更穩的模式開始。

8. EWWW Image Optimizer 免費本地壓縮夠用嗎？會不會把服務器壓垮？

EWWW 更像“本地幹活的壓縮工”：會吃 CPU/IO。
常見情況是批量優化時負載升高，這不代表它“不行”，而是策略要對：分批、低峯、必要時選擇卸載/雲方案。
如果你追求省心、或服務器資源緊張，路線 B 更省服務器。

9. ShortPixel 的 100 free credits/月，為什麼我感覺幾張圖就沒了？

因為 credits 不是“圖片張數”，會被縮略圖與 next-gen 放大：

• 原圖 + 每個縮略圖都算 credit
• 如果生成 WebP/AVIF，每個對應版本還會額外再消耗 credit
  所以你以為“1 張圖”，可能實際消耗接近“2 位數 credits”。ShortPixel

10. Imagify 的免費 20MB/月，為什麼也很快用完？

Imagify 更像“流量包”：

• 按你發送的原始文件大小扣配額
• 縮略圖越多，消耗越大
• 改壓縮級別重新優化，會再次消耗配額
• 同一個 API Key 多站共用，配額共享
  所以“20MB 很快用完”經常是圖片太大、縮略圖太多、或者反覆試錯造成的。

11. TinyPNG 免費 500 credits/月，為什麼插件説大概只有 100 張/月，開 WebP/AVIF 後還變 50 張/月？

因為 TinyPNG 的 credits 也會被“尺寸/變體”放大：

• 常規 WordPress 安裝大概壓縮約 100 張/月
• 啓用 AVIF 或 WebP 轉換：每個圖片尺寸會額外消耗一個 credit，所以大概只能壓縮並轉換約 50 張/月（取決於縮略圖尺寸數量）。
  所以 500 credits ≠ 500 張圖。

12. 我站裏縮略圖到底有多少？為什麼它會影響這麼大？

WordPress 上傳一張圖會生成多個尺寸；主題/插件（尤其電商）可能還會增加更多尺寸。
雲壓縮的 credits/配額通常是“原圖 + 縮略圖一起算”，所以縮略圖數量越多，免費額度就越不經用。

13. 懶加載是不是一定能加速？為什麼有人説懶加載反而變慢？

懶加載適合“屏外資源”。
如果首屏最關鍵那張大圖也被延後加載，可能拖慢首屏體驗。WordPress 5.5 起默認懶加載沒問題，但不要“一刀切”。

14. 我走路線 A 或 B，什麼時候需要 CDN / 圖片 CDN？

壓縮、尺寸、格式解決的是“文件更小更合適”；
CDN 解決的是交付更近更穩。
當圖片從源站遠距離拉取導致延遲明顯時，再補 CDN/圖片 CDN（例如 Cloudflare Polish / Jetpack Site Accelerator）整體會更穩，閲讀 WordPress CDN加速。

15. 做完後我用什麼最簡單的方法驗證“真的生效”？

最省時間的驗證法：

• 同一頁面刷新第二次，加載是否更穩定更快
• 手機與桌面加載的圖片尺寸是否明顯不同（srcset/sizes 是否發揮作用）
• 抽查幾張圖：是否出現 WebP 或 AVIF 文件/資源
• 抽查幾張圖：放大看是否明顯糊、文字是否發虛