WooCommerce 產品頁圖片與字型載入：先看哪幾個訊號
產品頁載入慢，最常見的反應是換主機、裝多一個快取外掛，或一次過壓縮所有圖片。但同一個「慢」可能停在主圖下載、畫廊的 lazy loading、字型換字，或第三方 script。這篇只處理兩個視覺資源：圖片與字型。先用五個可量測訊號定位，再決定改動順序。
先找 LCP 元素與它的資源，再看圖片的實際顯示尺寸與 loading 屬性，最後看字型請求與 CLS 來源。 未量測前，不要一次改主題、外掛、快取和字型；否則你不會知道哪個改動有效，也無從回滾。
一、五個訊號：把「慢」拆成可量測的欄位
產品頁的視覺載入，可以先看成五個訊號。它們不是五個外掛，而是五條要回答的問題：
| 訊號 | 要回答的問題 | 常見證據 |
|---|---|---|
| LCP 元素 | 首屏最大的內容是主圖、文字，還是背景圖？ | DevTools Performance、Lighthouse、PageSpeed Insights 的 LCP 診斷 |
| 實際顯示尺寸 | 圖片下載尺寸是否遠大於版面顯示尺寸？ | Network 的 transferred size、Elements 的 CSS 尺寸、currentSrc |
loading／fetchpriority | 首屏主圖有沒有被 loading="lazy" 延後？ | 實際 HTML、Network waterfall、Lighthouse 的 LCP 診斷 |
| 字型請求 | 載入幾多個字型檔、哪種格式、有否子集化、font-display 是甚麼？ | Network 的 font requests、CSS @font-face、Coverage |
| CLS 來源 | 版面跳動來自圖片未留尺寸、字型換字，還是後來注入的元件？ | Performance 的 Layout Shift、DevTools 的 shift sources |
另外有一條邊界：聊天插件、付款徽章、分析 script、頁面建構器載入的資源，也可能拖慢產品頁。它們不屬於「圖片與字型」，但量測時會混入同一個 waterfall。若第三方 script 是 render-blocking，先把它當另一個問題處理，不要用圖片壓縮來解釋。
A · 圖片與畫廊
先問：主圖是不是 LCP？
- 找 LCP 元素主圖、文字、背景圖，三者路徑不同。
- 對尺寸下載尺寸 vs CSS 顯示尺寸；手機不應拿桌面大圖。
- 看 loading首屏主圖不要 lazy；下方畫廊才考慮延後。
- 留版面width／height 或 aspect-ratio，避免圖片推走內容。
B · 字型與 CLS
先問：文字是未出現，還是換字時跳？
- 數請求幾個字重、幾個語言、是否重複載入同一字型。
- 看顯示策略
font-display決定等待、換字或略過。 - 減檔案WOFF2、子集化；缺字與動態產品名要實測。
- 對齊 fallback用 size-adjust 等令換字前後佔位接近。
同一產品 · 同一模板 · 同一手機 · 同一網絡條件；每次只改一項，保存 before／after。
二、主圖：先確認 LCP 元素，再談尺寸與格式
LCP 量的是首屏最大內容的渲染時間。web.dev 的官方指引以 2.5 秒或以下、並覆蓋 75% 頁面瀏覽為「良好」目標 [5]。這是量測門檻，不是任何主機、主題或外掛的速度保證；單一實驗室分數也不能代替真實用戶數據。
1. 先看 LCP 元素是不是主圖
在 DevTools 的 Performance 面板或 Lighthouse 報告找「Largest Contentful Paint element」。若元素是 <img>，記下它的 currentSrc、實際顯示尺寸、下載大小與開始下載時間。若 LCP 是文字，字型可能就是那條路徑的關鍵資源；不要只追圖片。
同一個產品頁，桌面與手機的 LCP 元素可能不同。不要只看桌面 WiFi 的漂亮分數；應以手機模擬、冷快取、接近真實網絡條件量測，並對照你的實際流量。
2. 對照 WooCommerce 的圖片類型與主題顯示寬度
WooCommerce 官方文件把產品圖片分為三類：單一產品主圖、目錄圖片、產品縮圖；主圖是產品詳情頁最大的圖片，並會在商店不同位置以不同尺寸重用 [1]。官方建議上載至少 800 × 800 像素的圖片，讓主圖、目錄與縮圖都有足夠細節；WooCommerce 會按設定產生顯示尺寸 [1]。
但實際顯示寬度由主題決定。傳統主題可在「外觀 > 自訂 > WooCommerce > 產品圖片」調整主圖寬度、縮圖寬度與裁剪；區塊主題可能在網站編輯器或主題本身設定，主題亦可覆寫寬度並隱藏部分控制項 [1][2]。所以不要只看 WooCommerce 設定，還要看前台實際 CSS 寬度與 currentSrc。
3. 用 srcset／sizes 讓瀏覽器選合適版本
WordPress 自 4.4 起支援原生 responsive images，會在產生的圖片標記加入 srcset 與 sizes [3]；wp_get_attachment_image_srcset() 是其中一個產生 srcset 值的函式 [4]。理想情況下，手機不應下載桌面大圖；瀏覽器會按顯示尺寸、像素密度與 sizes 描述選版本。
但主題、頁面建構器或圖片外掛可能改寫輸出、移除 srcset，或令 sizes 與實際版面不一致。檢查實際 HTML，而不是假設「WordPress 一定會處理」。若圖片是 LCP 資源，而它是從 CSS 背景圖或 script 才被發現，才考慮用 preload 及 imagesrcset／imagesizes 提早提示；官方文件提醒 preload 應配合 fetchpriority="high"，而且不應濫用 [6]。
4. 保留 width／height 或 aspect-ratio
圖片沒有保留版面空間，載入完成後會把下方內容推走，形成 CLS。官方 CLS 指引建議為圖片設定 width 與 height，或使用 CSS aspect-ratio 預留比例 [8]。這與壓縮圖片是兩件事：就算檔案很細，沒有尺寸仍然會跳。
5. 格式與壓縮：先看實際輸出，不要假設
WebP、AVIF 等格式通常可減少位元組，但是否自動產生、由哪個外掛或 CDN 轉換、瀏覽器收到哪個版本，取決於實際版本、主題與外掛設定。先看 Network 的 Content-Type、檔案大小與 currentSrc，再決定是否引入轉換。不要在新聞稿式文章裡承諾「換格式就一定快」；這不是可驗證的保證。
三、畫廊與縮圖：lazy loading 不是越多越好
WooCommerce 的產品主圖本身是畫廊第一項，不需要重複加入畫廊 [1]。畫廊縮圖與第二張以後的圖片，通常不在首屏；對它們使用 loading="lazy" 可以延後下載，讓首屏主圖先取得頻寬。瀏覽器層級的 lazy loading 會在圖片接近視窗時才載入，不需要自訂 JavaScript [7]。
但有兩個常見反向錯誤：
- 把首屏主圖設成 lazy。 若主圖是 LCP 元素，
loading="lazy"會令它等到版面確認後才開始載入，官方文件明確指出不應 lazy-load LCP 圖片 [5][6]。 - 畫廊 script 一次過載入全部圖片。 即使
<img>有loading="lazy"，某些畫廊或燈箱 script 可能預先建立所有圖片請求。以 Network waterfall 為準，不要只看 HTML 屬性。
WooCommerce 文件列出畫廊與目錄縮圖相關的尺寸設定／filter，例如 woocommerce_gallery_image_size、woocommerce_gallery_thumbnail_size 等；實際名稱與效果仍取決於版本與主題 [2]。若你要改主題或外掛輸出，先在 staging 用同一產品比對請求數量與 LCP，不要直接在正式站改核心檔案。
四、字型：先分「看不到字」與「字到了但版面跳」
字型問題最容易被誤診。客人說「頁面很慢」，可能其實是文字用預設字型顯示，換字時版面跳了一下；也可能是字型檔太大，令文字遲遲未出現。兩者的修法不同。CLS 以 0.1 或以下為良好目標 [11]。
1. font-display 決定文字等待或換字
@font-face 的 font-display 控制字型未載入時的文字顯示策略。swap 會先用系統字型顯示，再換成網頁字型；optional 可能讓瀏覽器在慢網絡下不換字；block 則可能短暫隱藏文字。web.dev 的 LCP 指引指出，只要 font-display 不是 auto 或 block，文字在載入期間通常仍可看見，LCP 不會被額外字型請求完全阻塞 [5]。這不是說 swap 永遠最好；品牌字型、正文與圖示字型要分開考慮。
2. 只 preload 真正關鍵的字型
preload 可以提早發現藏在 CSS 內的字型，但每一個 preload 都會與其他資源爭頻寬。只對首屏、品牌主標或 LCP 文字真正需要的字型使用；不要把所有字重、所有語言版本都 preload。若字型是 LCP 資源，才值得進一步考慮 preload 與 font-display 的組合 [5][6]。
3. 自託管與第三方字型：少一次連線，不等於必然更快
第三方字型供應商通常要建立額外連線；自託管可省去這段跨來源連線建立，但不保證整體下載必然更快。web.dev 的字型最佳實務指出，實測差異未必一面倒；是否自託管要連同 CDN、HTTP/2／HTTP/3、快取標頭、字型檔案最佳化及連線成本一起量度 [9][10]。不要把「自託管」當成單一開關。
4. WOFF2、子集化與中文字型
WOFF2 有廣泛瀏覽器支援與較佳壓縮；官方文件指其壓縮率可比 WOFF 好約 30% [10]。中文字型字集大，子集化（只保留實際用到的字符）通常能顯著減少檔案，但要確認產品名稱、動態內容、罕見字與多語言切換不會缺字。子集化不是一次設定就永久有效；產品目錄變更後要重跑。
5. 用 fallback 字型尺寸減少 CLS
即使使用 swap，網頁字型與系統 fallback 的字寬、字高不同，仍可能造成版面跳動。官方字型最佳實務建議用 size-adjust 等技術調整 fallback 字型，令換字前後的佔位接近 [9]。這比單純把 font-display 改成 swap 更完整：前者處理「看不到字」，後者處理「看到但跳」。
五、量測流程：同一頁、同一手機、同一條件
以下流程是實務建議，不是任何工具或主機的效能保證。重點是可重複：
- 固定測試對象。 選一個有主圖、畫廊、品牌字型與常見第三方元件的產品頁；記錄主題、WooCommerce 版本、外掛與 CDN／快取狀態。
- 用手機模擬與冷快取。 DevTools 選手機裝置、停用快取、套用 4G 或更慢的網絡節流；每個設定跑三次，取中位數，不要只貼一次最佳分數。
- 先看 LCP 元素。 記錄元素類型、
currentSrc、顯示尺寸、下載大小與開始時間。若 LCP 是文字，記錄字型請求。 - 再看 CLS 來源。 在 Performance 記錄 Layout Shift，找出是圖片、字型換字，還是後來注入的元件。
- 對照真實用戶數據。 PageSpeed Insights 的 CrUX 與實驗室 Lighthouse 可能不一致；官方文件指 CrUX 通常更代表真實體驗，而且要看頁面而非整個 origin 的數據 [5]。
- 一次只改一項。 每次改動後重跑同一流程，保存 before／after 截圖、waterfall 與 LCP／CLS 數值；若無改善或令其他頁變差，回滾。
六、改動順序與 Go／No-Go
先後次序比「裝哪個外掛」重要。以下排序以可量測、可回滾為原則：
| 順序 | 先改甚麼 | 通過證據 | 不應做 |
|---|---|---|---|
| 1 | 首屏主圖的 loading 與 fetchpriority | LCP 圖片不再被 lazy 延後；waterfall 顯示較早開始 | 把所有圖片一律設 lazy |
| 2 | 圖片實際顯示尺寸與 srcset／sizes | 手機下載版本接近顯示尺寸；LCP 圖片大小合理 | 只改 WooCommerce 設定而沒看主題 CSS |
| 3 | 圖片 width／height 或 aspect-ratio | Layout Shift 不再由圖片推動 | 用固定高度裁切所有比例 |
| 4 | 字型請求數、格式、子集與 font-display | 首屏文字可讀；換字 CLS 減少；沒有缺字 | 一次 preload 所有字重 |
| 5 | 畫廊與首屏以下圖片的 lazy loading | 首屏請求減少；畫廊互動仍正常 | 把首屏縮圖或燈箱首圖設 lazy |
| 6 | 第三方 script、頁面建構器與主題資產 | 確認它們是否 render-blocking；與圖片／字型分開記錄 | 用圖片壓縮解釋 script 造成的延遲 |
可以放行：同一產品、同一模板、同一手機條件下，LCP 元素與資源已確認；首屏圖片沒有被錯誤 lazy；圖片有保留尺寸；字型沒有缺字且換字穩定；before／after 有可重複數據；改動可回滾。
應阻擋：只憑一次 Lighthouse 分數、只改快取但沒看 LCP 元素、把所有圖片 lazy、把字型 preload 當萬能、或未在高用量產品頁與畫廊測試。未知不是通過。
七、客服與營運交接
產品頁效能不是單純前端問題。改動前，先通知客服與推廣同事：可能會短暫影響產品圖、畫廊或字型顯示；不要在促銷開賣前最後一刻改。若最近做過 WordPress／WooCommerce 更新，先看更新後回歸檢查；若改動涉及快取，配合Cloudflare 頁面快取清除的實際流程；若同時改 PHP 版本，另看PHP 版本相容性，不要把兩件事混成一個測試。
交接紀錄至少要有：產品 URL、模板、主題與外掛版本、測試裝置與網絡條件、LCP 元素與資源、圖片顯示尺寸與下載尺寸、字型請求與 font-display、CLS 來源、before／after 截圖、改動人、時間、回滾方法。若要在新主題或推廣頁上線前演練，可配合上線前檢查清單。
要整理產品頁的圖片與字型載入紀錄？
若你需要按實際產品頁、主題輸出、LCP 與 CLS 訊號整理檢查紀錄，可聯絡 Managed-WP.™ PRO（WordPress 專業代管服務）。
常見問題
首屏產品主圖可以用 lazy loading 嗎？
不建議。若主圖是 LCP 元素，loading="lazy" 會令它等到版面確認後才開始載入，官方文件明確指出不應 lazy-load LCP 圖片。首屏主圖應正常載入；只有首屏以下、接近視窗才需要的圖片才考慮 lazy。
WooCommerce 已產生多個圖片尺寸，還需要檢查 srcset 嗎？
需要。WooCommerce 會按設定產生尺寸，但前台實際輸出受主題、頁面建構器與圖片外掛影響。應看實際 HTML 的 srcset、sizes 與 currentSrc，確認手機沒有下載遠大於顯示尺寸的版本。
字型 preload 是否越多越好？
不是。每個 preload 都會佔用頻寬與優先順序。只 preload 首屏、LCP 文字或品牌主標真正需要的字型；不要把所有字重、所有語言版本一起 preload。過多 preload 可能令真正關鍵資源更遲開始。
把圖片換成 WebP 或 AVIF 就會快嗎？
不一定。格式轉換可減少位元組，但若圖片本身過大、沒有 srcset、首屏被 lazy、或字型與第三方 script 才是瓶頸，單換格式不會解決。先量測 LCP 元素與資源，再看實際輸出格式與大小。
Lighthouse 分數高，是否代表客人一定覺得快？
不代表。Lighthouse 是實驗室環境；真實用戶的裝置、網絡、快取與地理位置不同。PageSpeed Insights 的 CrUX 數據通常更代表真實體驗，而且要看該頁面而非整個網域的數據。兩者不一致時，不要只看分數。
可以只裝一個圖片優化外掛處理嗎？
不建議未量測就裝。圖片外掛可能改寫 markup、產生新格式或改變 lazy loading 行為，與現有主題／畫廊 script 衝突。先在 staging 用同一產品頁比較 LCP、CLS、請求數與畫廊互動，再決定是否保留。
資料來源
WordPress Developer Resources — wp_get_attachment_image_srcset()
web.dev — How the Core Web Vitals metrics thresholds were defined
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊整理官方文件。五個訊號、量測流程與改動順序屬實務整理，不是 WooCommerce、WordPress、主題、外掛、主機、CDN 或瀏覽器的效能保證，也不構成任何 SLA。實際輸出、版本、設定與量測結果可能不同，應以 staging 及正式環境的實際數據為準。本文不指示修改核心檔案，也不承諾任何圖片格式、lazy loading 或字型策略必然改善分數。