網站圖片優化

圖片優化係提升 WordPress 效能投資回報率最高嘅方法:喺頁面結構同主題都一樣嘅情況下,只要將圖片嘅大小、尺寸、格式同傳遞方式搞掂,通常就可以即刻改善載入體驗。

不過,圖片優化最容易搞到「愈整愈差」嘅局面。原因唔係技術太難,而係資訊太碎片化:
你睇咗幾篇文章,學到「壓縮」、「WebP/AVIF」同「懶載」,但當你睇返插件描述,就見到寫住「每月100免費額度」、「20MB免費」同「每張相1個額度」——睇得越多就越迷糊。免費額度真係夠用?收費點樣扣除?係咪你誤解咗「同一件事」?最重要係:你做完之後,佢真係有冇生效?

呢篇文章淨係做三件事:

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 開始,只要主機環境支援 WebP,就可以好似 JPEG/PNG 咁上載同使用 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) precisely to address this issue.

乜嘢先算及格分:

• 喺手機瀏覽呢個頁面嘅時候,下載嚟嘅圖片尺寸應該明顯細過桌面版。
• 同一張圖片嘅資源大小喺唔同裝置上都會唔同(而唔係每次都下載原始圖片)。

最常見嘅陷阱:

• 有啲主題或頁面構建器可能會繞過呢個限制,將圖片當做 CSS 背景圖,或者用自訂方法輸出佢哋。 srcset導致不斷下載大量圖片
• 利用外部圖片寄存服務或第三方圖片組件,你可以繞過媒體庫自動生成嘅多尺寸系統。

---

2.2 壓縮(減少 KB 大小,但唔好犧牲質素)

壓縮嘅精髓唔係「愈細愈好」,而係「以肉眼幾乎察覺唔到嘅細微差異,卻大幅減少體積」。

規則如下:

• 相片/實地拍攝(人像、產品、風景)優先使用有損壓縮(最大化收益)
• 截圖/包含大量文字嘅圖片壓縮要保守啲,先至唔會令文字變得模糊。
• 標誌/圖示優先使用 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/image CDN)。

兩種典型方法:

• Cloudflare 波蘭：Cloudflare 文件文章介紹咗Polish嘅壓縮方法(無損/有損/WebP),並提到使用 format=auto 可以使用 WebP/AVIF 格式。
• Jetpack 網站加速器：Jetpack 文件佢會優化圖片,並透過佢嘅網絡同靜態資源一齊分發。

影像優化負責減少檔案大小並確保適用性。CDN:更貼近、更可靠地交付

3. 選擇:只可追求兩條主要路線。

喺圖片優化中最常見嘅陷阱唔係「冇安裝插件」,而係安裝太多插件導致重複處理:
A 喺壓縮,B 都喺壓縮;A 喺轉 WebP/AVIF,B 都喺轉;A 喺改 URL,B 喺重寫佢哋──到頭嚟,連你自己都講唔清網站上究竟發生緊咩事。

規則:

只有一條出路:要麼完全免費嘅本地儲存,要麼係雲端壓縮,提供三個選擇。

• A 線(全程免費本地):仲有 WebP 或 AVIF + EWWW Image Optimizer(或者只揀其中一個)
• B 路徑(從三個雲端壓縮選項中揀一個):ShortPixel / Imagify / TinyPNG

---

3.1 路線A:完全免費本地(加WebP或AVIF或EWWW)

呢條路線嘅主要特徵係:

• 你唔會依賴以月額配額或逐檔計費方式運作嘅第三方壓縮服務(雖然某啲功能可能提供額外選項服務)。
• 折衷係批量處理喺CPU/IO方面可能會令伺服器負擔更重,要你更加留意「策略同風險」。“

3.1.1 仲有 WebP 或 AVIF核心概念係「生成/替換」,佢唔係傳統嘅「壓縮工具」。“

• 當生成全解析度影像時:原始影像檔案 ID 會俾 WebP/AVIF 檔案覆蓋,原始檔案會被刪除,內容入面嘅 URL 亦都會被替換。。
• 呢個插件提供咗 WP-CLI 命令,並建議:當處理大量檔案時,WP-CLI 更加可靠。

呢個即係話:佢唔係「靜靜咁幫你產生 WebP 檔案」,而係可能只會出現一次。資產遷移(特別係當你開啟「替換並刪除原始影像」選項時)

兩種模式嘅分別

模式1:保留原始圖片 + 產生 WebP/AVIF 副本(更穩定)

• 優點:如果出現相容性問題,更容易還原。
• 成本:磁碟空間使用量會增加(原始影像 + 新格式 + 多尺寸縮圖)

模式2:替換並刪除原始影像(更激進)

• 優點:磁碟唔會咁快擴展;內部參考會自動轉成新格式。
• 風險:當同時修改資產同參考資料時,要排除相容性問題嘅成本會大幅增加(尤其係當外部系統或主題邏輯依賴原始檔案名/路徑/格式時)。

WebP 或 AVIF 嘅常見陷阱

1. 完成咗完整嘅資料庫替換之後,有啲頁面影像顯示錯誤。
   通常問題唔係「圖片損毀」,而係鏈條上某個環節──例如 URL 替換、緩存或者縮圖生成政策──冇正確對齊。
2. 縮圖越多,變化範圍就越廣。
   將圖片上載到 WordPress 會產生多個尺寸;主題或外掛程式可能會新增更多尺寸。全面替換即係話你可能要修改一大堆檔案。
3. 淨係做格式遷移,唔能夠保證到最細嘅體積。
   WebP/AVIF 檔案一般都較細,但「尺寸策略」同「壓縮策略」依然好重要。唔好將 Plus WebP 當成「一鍵加速」嘅萬能方案。

---

3.1.2 EWWW 圖片優化器免費本地壓縮方案

EWWW 插件頁面嘅定位非常清晰:

• 佢可以喺你嘅伺服器上使用一系列工具做優化(jpegtran、optipng、pngout、pngquant、gifsicle、cwebp 等)。
• 如果你需要更高嘅壓縮率,或者想喺CPU度慳番啲,你都可以將嗰啲耗用CPU嘅處理轉去你嘅伺服器做(可選)。

EWWW 喺 Route A 應該扮演咩角色?

如果你用 Plus WebP 做「格式遷移/替換策略」,咁 EWWW 更適合去執行:

• 壓縮同體積優化(特別係對原始資源(例如 JPG/PNG 檔案)嘅壓縮)
• 歷史媒體庫嘅批量優化(目標係「減少數量」而唔係「取代網址」)

EWWW嘅經典陷阱

1. 批量優化期間伺服器負載會增加
   因為本地壓縮會消耗 CPU/IO。解決方法唔係「唔用佢」,而係「在非繁忙時間批處理,並喺必要時選擇離線或雲端方案」。
2. “產生 WebP 並唔代表前端一定會伺服 WebP。
   好多插件都誤以為:生成係一回事,而傳遞策略(重寫、圖片標籤、緩存命中等等)就係另一回事。
3. 複製其他插件嘅相同功能
   如果你走A路線,就避免堆疊使用ShortPixel/Imagify/TinyPNG等雲端壓縮服務;如果你走B路線,就停用Plus WebP替換邏輯。核心原則:堅持一條行動路線。

---

3.2 路線 B:從三款雲端壓縮服務(ShortPixel / Imagify / TinyPNG)中揀一款

呢個方案適合想慳伺服器資源、鍾意更無痛嘅批量處理方式,同埋接受按用量付費收費模式嘅人士。
不過,關於雲端壓縮最常見嘅誤解係:「free allowance」唔單止係「免費報紙」嘅意思。縮圖尺寸嘅數量、是否產生 WebP/AVIF 格式,以及是否進行重複壓縮,都會大大影響資源消耗。

以下我哋會講解:免費/收費級別點運作、配額點扣除、最常見嘅陷阱點避免,以及邊啲網站類型最啱用。

---

3.2.1 ShortPixel每月100免費積分,但縮圖同 WebP/AVIF 放大會消耗積分。

免費同收費有咩分別?

ShortPixel 插件說明中明確指出:

• 每月100免費積分
• 仲有「額外無限月費額度」(插件頁面提供咗相應嘅收費資訊)。
• 亦提供「終身有效一次性信用套餐」(並已提供初步定價資料)

備註:

• 免費:每月為輕量級網站或測試用途分配信用額度。
• 一次性套裝:適合擁有龐大媒體庫存並希望一次過清倉的網站(一次購買,可無限期使用,通常無到期日)。
• 月費/無限量:適合需要持續更新圖片及長期穩定優化嘅網站。

ShortPixel 嘅官方知識庫亦都講解咗「一次性套票同無限月費計劃」之間嘅比較。清晰嘅解釋無限月費計劃按月(或按年)收費,提供無限額度同固定CDN配額;一次性額度唔會過期,俾你隨時隨地更靈活掌控用量。

最重要嘅一點:ShortPixel 嘅信用點係點樣計算㗎?

ShortPixel 官方文件 KB 講得好清楚:

• 將圖片上載到 WordPress 會產生多個縮圖;
• 每個縮圖優化計作一信用。；
• 如果你揀生成 WebP 或 AVIF,每個原始圖片及其縮圖的 WebP/AVIF 版本,都會額外消耗一個信用額。；
• 你可以將某些縮圖排除出優化,以減少數據用量。

範例:致謝：

假設你上載一張圖片,主題/外掛會生成八張縮圖:

• 只優化原始圖片及縮圖:1(原始圖片)+ 8(縮圖)= 9 積分
• 如果仲要產生 WebP/AVIF 版本:就喺上述 9 個格式每一個加多一個次世代版本 → 然後再加多 9 個計費項目。
  換句話講,你可能以為嘅「一幅圖像」,其實可能要用到差唔多「十個積分」。

所以:“「免費100積分」並唔等於「免費100張相」。

ShortPixel 最常見嘅陷阱

1. 免費100個積分好快用晒
   根本原因:要生成 WebP/AVIF 需要大量縮圖同額外資源。
   建議：

• 首先評估網站上嘅縮圖數量。
• 移除唔必要嘅縮圖尺寸(只優化實際會用嘅尺寸)
• 首先喺批量處理之前,先確定壓縮策略,避免重複嘅試錯浪費資源。

2. 同時覆蓋其他格式轉換插件
   如果你同時開啟 Plus WebP 替換,又指示 ShortPixel 產生/插入新一代標籤,邏輯就會層層疊加,令排錯更困難。Route B 就由 ShortPixel 獨立處理。
3. 單憑安裝就以為「前端會提供 WebP/AVIF」。“
   ShortPixel 外掛頁面佢可以將 WebP/AVIF 格式嘅圖片轉換,並將新一代圖片整合到前端頁面(例如透過標籤實作)。
   不過,一旦完成,結果仍然要驗證。

---

3.2.2 Imagify每個月免費20MB;配額會根據「原始圖片大小 + 縮圖數量」扣除;重新壓縮會導致重複扣除。

免費配額及定位

Imagify 官方定價頁面寫得好清楚:免費帳戶有每個月20MB嘅配額。
佢嘅插件頁面亦都明確講可以壓縮、重新尺寸同轉換 WebP/AVIF 檔案。

配額點樣扣除?

Imagify 官方文件 “「配額使用量點樣計算?」清楚咁拆解扣除機制:

• 縮圖嘅數量會影響消耗。例如,如果你有十種縮圖尺寸,優化一張圖片就變成要優化十一張圖片(原始圖片加十張縮圖),全部都會計入配額消耗。
• 按原始檔案大小扣除配額例如,如果你將100KB嘅圖片傳送畀Imagify,就會從你嘅配額扣除100KB。
• 更改壓縮級別並重新優化會再次消耗配額。。
• 同一條 API 密鑰可以喺多個網站上使用,但配額會喺呢啲網站之間共享。

呢個係 Imagify 嘅「核心理解方法」:
佢更似一個數據套餐:你傳幾多就扣幾多;縮圖越多就扣得越多;多次大量上載就會多次扣費。

易明嘅 Imagify 配額示例

假設你上載咗一張800KB嘅原始圖片,而網站會生成8張縮圖。

• 用 Imagify 優化時,如果揀「優化全部」,就會連原本嘅圖片同八張縮圖一齊處理。即係話,呢次操作會消耗嘅配額,差唔多等於所有呢啲檔案原本尺寸總和。
  呢就係點解有啲網站發現佢哋嘅「20MB」配額好快用晒:唔係 Imagify 做唔到,而係你上傳嘅圖片太大、生成太多縮圖,又可能不斷試唔同壓縮級別。

Imagify 嘅常見陷阱

1. 免費嘅 20MB 唔夠用嚟執行「完整網站歷史清除」“
   20MB 一般嚟講更適合用嚟做測試同細微更新;如果你嘅媒體庫已經好大,一次過清晒就可能要升級。
2. 不斷調整壓縮級別會導致重複消耗配額。
   Imagify 明確聲明重新優化會再次消耗配額。
   建議喺呢頁清楚列出策略:

• 首先,用少量影像去決定壓縮級別同視覺質素。
• 喺批量運行之前完成策略
  避免喺整個資料庫度不斷試錯。

3. 跨多個網站共用 API 密鑰會令配額神秘地減少。“
   如果你喺多個網站上使用同一條 API 密鑰,配額會共享。
   因此,喺團隊/多地點嘅情況下,建議清晰界定邊啲地點共用資源、邊啲獨立運作,以防止預算失控。

---

3.2.3 TinyPNG(Tiny Compress Images):每月免費500個積分;轉成WebP/AVIF每種尺寸額外扣1個積分。“

免稅額及其計費方式

TinyPNG 嘅 WordPress 插件頁面寫得好清晰:

• 每月免費500積分
• 喺「標準嘅 WordPress 安裝」入面,可以壓縮大約 大約每個月100張相片
• 不過,如果開啟咗 AVIF 或 WebP 轉換:每張圖片尺寸都會額外扣取信用額度。所以,佢大概只可以被壓縮同轉換。 大約每個月50張相片(視乎你有幾多張縮圖尺寸)

與此同時,Tinify(TinyPNG/TinyJPG 的開發者)亦喺佢嘅網站上宣佈。 API 定價頁面注意:註冊即可每月獲取500次免費壓縮。超出此配額後,按成功壓縮次數收費,毋須訂閱。

用一句話總結 TinyPNG:
佢係用積分計;你嘅縮圖尺寸越多、啟用嘅 WebP/AVIF 格式越多,積分就會用得越快。

一個易明嘅 TinyPNG 積分示例

假設你嘅網站為每張圖片生成八種縮圖尺寸:

• 只壓縮:原始圖片 + 8 個縮圖 → 需要 9 個積分
• 如果開啟 WebP/AVIF 轉換:每增加一個尺寸就會額外扣減一次信用 → 費用可能會差唔多加倍。
  呢個同插件頁面嘅描述完全一致:一旦啟用轉換功能,免費配額由大約「每月100張圖片」變成「每月50張圖片」。

使用 TinyPNG 時常見嘅陷阱

1. 假設500個信用點等於500張圖片
   唔係。佢會根據「圖片大小/變體」嚟消耗積分。插件頁面明確寫住:「轉換會喺每個圖片大小扣除額外1分積分。」
2. 主題/電子商務插件會產生過多尺寸,導致免費配額大幅減少。
   規模越大,信用就越容易放大同消耗。
3. 喺開啟咗轉換之後,我發現信用額度突然唔夠用。
   呢個唔係漏洞;呢個係佢嘅收費機制。
   策略建議:

• 如果免費 tier 主要用嚟做壓縮同減輕重量,你一開始可以淨係專注做壓縮。一旦你確認咗網站結構穩定,而且真係需要 next-gen,就可以開始做轉換。

4. 基於情境嘅推薦:點樣為唔同網站類型作選擇

雖然全部都用 WordPress,但內容站、電商平台、作品集同會員站,各有唔同嘅圖片相關痛點。

4.1 內容導向嘅網站/博客(每篇文章配有大量圖片,更新頻率適中)

優先建議:

1. 維度策略(第一步)
2. 壓縮(第2步)
3. WebP (第3步)

更合適嘅路線:

• 為咗免卻麻煩:從三個替代方案(ShortPixel / Imagify / TinyPNG)中揀一個。
• 免費選項:Route A(Plus WebP + EWWW),但建議先以「保守模式(不刪除原始圖片)」評估風險。

常見陷阱:

• 文章嘅標題圖片好大,懶載入策略唔啱用。會令第一頁變慢

4.2 電子商務/產品網站(大量縮圖、多種圖片變體、穩定性至關重要)

電商最常見嘅問題唔係「壓縮效果差」,而係「優化後尺寸錯誤、縮圖缺失,同前端組件攞唔到圖片」。

優先建議:

1. 審慎行事:採用保守嘅壓縮策略;避免即刻進行完整資料庫替換。
2. 評估縮圖尺寸:電子商務主題通常會生成更多尺寸,加劇配額消耗(特別是在使用 ShortPixel/TinyPNG 時更為明顯)。
3. 喺擴展之前做小規模驗證(極其重要)

更合適嘅路線:

• Route B 通常比較直接:ShortPixel、Imagify 同 TinyPNG 都支援批量處理。關鍵係要了解佢哋嘅配額機制,並預先評估成本。
• Route A 都可行,但要對 Plus WebP 嘅「覆蓋 ID/刪除原始圖片/替換網址」行為更加小心:呢啲屬於資產遷移,一開始就全面替換係唔建議嘅。

4.3 作品集/攝影網站(對影像質素、檔案大小及視覺標準有高度要求)

優先建議:

1. 維度策略(顯示區域控制)
2. 壓縮策略(寧願大啲,都唔好令細節流失)
3. WebP/AVIF(喺大圖場景下帶嚟顯著好處,但視覺質素仍需驗證)

更合適嘅路線:

• Imagify按「原始圖片大小」分配配額,可以令呢啲網站更有利於「預算控制」(因為你大概知道每張大圖會用幾多),但要避免重複壓縮佢哋。
• ShortPixel如果縮圖尺寸嘅數量有限,信用消耗仍然可控;但當同時生成大量尺寸同新一代資產時,信用用量會大幅上升,需要預先規劃。

5. 配額/賬單比較:解釋免費配額是否足夠

邊個更抵用?免費期會持續幾耐?

5.1 三種費用扣除模式

• ShortPixel(謝幕)積分會根據原始圖片同縮圖嘅數量計算;生成 WebP/AVIF 版本會喺每個相應格式度額外扣減積分。
• Imagify(MB配額)配額扣除以原始檔案大小計算;生成更多縮圖會導致更大扣除;重新壓縮會再作扣除。
• TinyPNG(謝幕)每個月500個積分;開啟WebP/AVIF轉換會按每張圖片大小額外扣減積分。

5.2 快速估算方法

你可以咁樣估計:

1. 揀任何你經常上載嘅「原始圖片」,檢查佢嘅大約大小(例如 300KB / 1MB / 3MB)
2. 估計你嘅網站會產生嘅大約縮圖數量(例如:5 / 10 / 20)
3. 決定是否產生 WebP/AVIF(是/否)

然後用以下「心算」去理解消費:

• ShortPixel每張圖片大約需要(1 + 縮圖數量)個署名;如果生成 WebP/AVIF,則大約要加倍(因為新一代版本亦需要署名)。
• Imagify每張圖片大約會消耗等同於(原始圖片大小 + 所有縮圖總大小)嘅配額;用唔同壓縮級別重新壓縮,會再扣除額外配額。
• TinyPNG免費:500 個信用額;如果你嘅網站為每張圖片生成多種尺寸,並且已啟用轉換功能,免費額度就會大幅減少(外掛頁面提供咗直觀嘅估計,即「每月約100張圖片」與「每月約50張圖片」)。

6.風險披露

風險1:避免多個插件重複執行相同功能。

呢個係最常見嘅災難來源。“

• A 線:仲有 WebP 或 AVIF + EWWW(將責任分拆畀兩邊;唔好同時做相似嘅轉換同送遞,或者淨係安裝其中一樣。)
• B 路線:ShortPixel / Imagify / TinyPNG 從三個中揀一個(揀一個負責壓縮同新一代嘅)

風險2:Plus WebP 的「覆蓋 ID/刪除原始圖片/替換網址」功能屬於資產遷移。

再一次,必須強調:仲有 WebP 描述中明確指出,在完整生成過程中,原始圖片 ID 會被覆蓋,原始檔案會被刪除,並將內容 URL 替換。
呢個表示唔係「隨時都可以撤回嘅細微調整」,而係資產層面嘅修改。

建議嘅策略應該係:

• 初步小型測試(數十至數百項)
• 確認前端顯示、縮圖同緩存更新運作正常。
• 考慮全數據庫處理

風險3:實際使用雲端壓縮嘅「免費額度」視乎所揀嘅縮略圖數量同新一代選項而定。

• ShortPixel縮圖同次世代會對積分造成重大影響。
• TinyPNG開啟 WebP/AVIF 會對每個影像尺寸額外扣除信用點。
• Imagify按原始圖片尺寸扣除;縮圖越多,扣除越多。過度壓縮會導致重複扣除。

風險4:「產生咗 WebP/AVIF」並唔等於「前端實際傳遞 WebP/AVIF」“

好多用家反映做完優化之後網站都冇變快,根本原因係前端仍然會輸出 JPG/PNG 檔案(因為喺任何一個環節──緩存、重寫、標籤或者瀏覽器協商──出現唔匹配)。

7. 點樣驗證完成任務之後有冇生效?

四個非常簡單嘅驗證要點:

1. 當第二次重新整理同一頁時,載入過程會唔會更加穩定同更快?(緩存同優化嘅感知效能)
2. 手機同桌面版載入時,圖片尺寸有冇明顯分別?(響應式) srcset/sizes 唔知佢有冇用
3. 隨機檢查幾張圖片:有冇 WebP 或 AVIF 檔案/資源?個網站真係有用緊佢咩? 下一代）
4. 隨機檢查幾張相片:放大後睇吓有冇明顯模糊,或者文字有冇霧氣。(壓縮質素有冇太過?)

如果四個標準全部都符合,就表示你所選擇嘅路線而家已經可以運作。請繼續進行下一步。 CDN「傳遞層」“整體穩定性會得到加強。

8. 行動建議

1. 首先揀你嘅路線:

• 我想盡量保持佢免費。仲有 WebP 或 AVIF + EWWW(或者淨係安裝其中一個)
• 為咗慳伺服器資源,同時享受按用量計費帶嚟嘅更大安心。請從以下選項中選擇一個:ShortPixel / Imagify / TinyPNG

2. 進行一個小型測試(幾十項)
3. 喺進行批次之前,請確認一切都冇問題。
4. 需要進一步改進以提升交付穩定性:閱讀 CDN 加速

常見問題

1. 我應該安裝幾多個插件?可唔可以全部都安裝?

試吓盡量只行一條路線。

• 路線A:WebP 或 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嘅圖片。壓縮可以慳幾千字節,但尺寸唔配就無故浪費幾倍嘅數據。

4. 我點樣可以確定而家載緊嘅圖係「細嗰張」,而唔係成日都下載原本嗰張?

觀察兩個現象:

• 喺手機開呢個頁面嘅時候,下載嚟嘅圖片尺寸明顯比喺桌面電腦上細。
• 同一張圖片喺唔同裝置上載入時,資源大小會唔同。
  如果原始圖片成日被下載,常見原因係主題或構建器將圖片當做 CSS 背景圖或自訂輸出,從而繞過媒體庫嘅多尺寸功能同 srcset 功能。

5. 「generated WebP/AVIF」一定代表前端會輸出 WebP/AVIF 嗎?

佢唔同。
生成只係完成「檔案層」;前端究竟係咪真係提供 WebP/AVIF,就要視乎重寫、圖片標籤策略、緩存命中同瀏覽器協商有冇生效等因素。做完之後,你要「抽查幾張圖嘅資源類型」。

6. WebP 或 AVIF 究竟有咩風險?可唔可以一次過喺整個相片庫度用一鍵轉換?

佢嘅風險點唔係「壓縮」,而係資產遷移級別修改：

• 喺全尺寸生成嘅過程中,原始影像檔案嘅 ID 可能會被覆蓋,原始檔案可能會被刪除,內容入面嘅網址都會被替換。
  所以唔建議即刻將成個資料庫都替換。首先進行小型測試(數十至數百筆記錄),並確保備份可用,然後再考慮處理整個資料庫。

7. 點樣喺 Plus WebP 嘅兩個模式之間揀:保留原始圖片定取代並刪除原始圖片?

簡單嚟講:

• 模式1:保留原始圖片 + 產生 WebP/AVIF 副本(更穩定)方便回滾,但會佔用更多磁碟空間(原始影像 + 新格式 + 多種尺寸縮圖)。
• 模式2:替換並刪除原始影像(更激進)磁碟擴充唔係咁容易做到,但當你同時修改資產同參考時,要排除相容性問題嘅成本就會大幅提高。
  網站愈複雜(電商平台/多個插件/多種尺寸),就愈建議由一個較穩陣嘅方法開始。

8. EWWW Image Optimizer 嘅免費本地壓縮夠唔夠用?會唔會令伺服器過載?

EWWW 更似一個「本地壓縮工具」:佢消耗 CPU/IO。
喺批次優化期間,負載增加好常見。呢個唔代表呢個方法唔夠用,而係要策略得體:分批實施、喺非繁忙時間進行,必要時選擇卸載或者雲端方案。
如果你想搵一個無煩惱嘅方案,或者正遇到伺服器資源不足,Route B 更加節省伺服器資源。

9. ShortPixel 每個月100次免費轉換——點解轉幾張圖就用晒咁快?

因為 分數唔係「張數」。“會被縮成縮圖,然後放大到下一代:

• 原始圖片同每一個縮圖都計作一次信用
• 如果產生 WebP/AVIF,每個對應版本都會額外消耗信用額度。
  所以你可能會以為「1 張圖片」其實可能要用到接近「十位數積分」。ShortPixel

10. 點解 Imagify 免費嘅每個月 201 TP234T 配額咁快就用晒?

Imagify更似一個「數據包」:

• 按你嘅訊息原始檔案大小扣除配額
• 縮圖越多,消耗就越大。
• 重新優化壓縮級別會再次消耗配額。
• 同一個 API 密鑰會喺多個網站之間共用,配額都會相應分享。
  所以「20MB 即將用盡」呢個訊息通常係因為圖片太大、縮圖太多,或者反覆試錯所致。

11. TinyPNG 每個月提供 500 個免費額度,點解插件話淨係得大約每個月 100 張相? 仲有,開啟 WebP/AVIF 之後,點解又跌到每個月淨係得 50 張相?

因為 TinyPNG 嘅積分亦會因「size/variant」而放大:

• 一個標準嘅 WordPress 安裝通常每個月會壓縮大約100張圖片。
• 啟用 AVIF 或 WebP 轉換:每張圖片尺寸都會額外扣取信用額度。所以,每個月大概只可以壓縮同轉換大約50張相(視乎縮圖尺寸嘅數量)。
  所以,500個積分≠500張圖片。

12. 我個網站有幾多張縮圖?點解佢會有咁大嘅影響力?

將圖片上載到 WordPress 會產生多個維度;主題/外掛(尤其係電商相關嘅)可能會再加入其他維度。
雲端壓縮配額/額度通常會以「原始圖片加縮圖合共」計算,所以縮圖越多,免費額度就用得越快。

13. 懶惰載入係咪永遠都可以加快速度?點解有人話其實會變慢?

懶載適合用喺離螢幕嘅資源。
如果首頁上最重要嘅大圖都延遲載入,可能會拖慢首次載入嘅體驗。雖然 WordPress 5.5 嘅預設懶動載入大致上都算可以接受,但要避免一刀切式嘅做法。

14. 如果我揀A路由或B路由,幾時需要CDN / Image CDN?

壓縮、大小同格式就滿足到「要細啲、更合適嘅檔案」嘅需要。
CDN 確保傳遞更快速、更可靠。。
當因為圖片要從遠端原始伺服器抓取而出現明顯延遲時,為每張圖片加上 CDN(例如 Cloudflare Polish/Jetpack Site Accelerator)通常可以令體驗更穩定,令內容更易閱讀。 WordPress CDN 加速。

15. 我做完之後,最簡單嘅方法係點樣驗證佢真係有用?

最慳時間嘅驗證方法:

• 當第二次重新整理同一頁時,載入過程會唔會更加穩定同更快?
• 喺手機同桌面載入時,圖片尺寸有冇明顯分別?(srcset/sizes 有冇正常運作?)
• 隨機檢查幾張圖片:有冇 WebP 或 AVIF 檔案/資源?
• 隨機檢查幾張相片:放大後睇吓有冇明顯模糊,或者文字有冇霧氣。