WooCommerce 的商品頁通常載入得還算可以。商店頁、分類清單和搜尋結果往往就不是了，而店主常常對此感到意外，因為單一商品看起來都沒問題。差別在於算術。商品頁顯示一張主圖。一個呈現二十四件商品的分類頁至少顯示二十四張，一旦把滑鼠移入效果與相簿預覽算進去，經常是兩倍。

正是這個乘法，讓目錄頁通常成為整間商店裡最慢的部分，也讓它們成為商業上最重要的頁面。它們恰好卡在訪客抵達與訪客找到可買之物這兩件事之間。

多數緩慢目錄背後的固定模式： 佈景主題請求了一個 WordPress 從未產生過的縮圖尺寸，於是瀏覽器下載完整尺寸的原圖，再在頁面裡縮小。二十四件商品，每件都送出一張兩百萬位元組的照片只為在三百像素上顯示，就是一個五千萬位元組的分類頁，無論你加多少快取，分數都好不了。

目錄頁為什麼表現不同

清單頁上有三件事會疊加，而商品頁上不會。

數量。 格線裡的每件商品至少產生一次圖片請求。WooCommerce 的預設常常每頁顯示十六或二十四件，規模更大的商店還會繼續調高，以減少翻頁。

滑鼠移入圖與相簿圖。 很多佈景主題會為每件商品預先載入第二張圖，用於移入切換。這會悄悄把頁面的圖片數量加倍，而且第二張圖在發生互動前從不可見，所以它對首屏繪製毫無貢獻，卻消耗同樣的頻寬。

版面不穩定。 沒有為圖片預留空間的格線，會隨著每張圖抵達而位移。在商品頁上，一次位移還能忍受。在二十四格的格線裡，累積的移動正是糟糕 Cumulative Layout Shift 分數的來源，體感上就是你想點擊時頁面在跳。

結果是，目錄頁因為商品頁所沒有的原因而在 Core Web Vitals 上失分，而最佳化商品範本對它們毫無作用。

造成大部分問題的尺寸不符

WordPress 在上傳時產生一組圖片尺寸。WooCommerce 在此之上註冊自己的尺寸。佈景主題再註冊更多。瀏覽器實際收到什麼，取決於範本請求了其中哪一個尺寸，以及那個尺寸是否存在。

失敗方式是安靜的。如果佈景主題請求的尺寸是在你的商品上傳之後才註冊的，WordPress 從未產生過它，於是退回完整尺寸的原圖。頁面看起來依然正確，因為瀏覽器把圖片縮小以配合版面。它只是為了顯示一張縮圖而搬運了好幾百萬位元組。

不用任何工具你也能發現這一點。開啟一個分類頁，打開網路面板，依大小排序圖片請求。如果傳輸大小接近原始上傳檔案的重量，而不是它的一小部分，那就是在提供錯誤的尺寸。把已載入圖片的原始尺寸和它在螢幕上占據的空間相比。一張以兩千像素寬度抵達、只為填滿三百像素方塊的照片，一次觀察就說明了全部問題。

修正辦法要麼是重新產生縮圖，讓被請求的尺寸確實存在；要麼是在傳遞時提供正確尺寸，讓這個問題根本不會出現。

延遲載入，以及它出錯的地方

WordPress 預設對圖片啟用延遲載入，這對目錄頁的幫助超過幾乎任何其他頁面類型，因為長格線的大部分都在首屏之下。

但有兩個錯誤會抵銷這份效益。

對第一列使用延遲載入。 開啟頁面時就可見的圖片應當立即載入。如果其中最大的那張被延遲載入，瀏覽器會很晚才發現它，而它通常正是 Largest Contentful Paint 元素，於是這項指標直接受損。多數佈景主題在這裡出錯，因為它們對每一個商品方塊一視同仁地套用延遲載入。

延遲載入外掛與瀏覽器原生實作打架。 在瀏覽器機制之上再疊一層外掛自己的延遲載入，會產生永遠不載入、載入兩次或者閃爍的圖片。如果你裝了效能外掛，檢查一下它是不是在重複瀏覽器已經做過的事。

傳遞：真正能擴展的那一部分

重新產生縮圖修好的是今天的目錄。它修不了下個月的，比如新供應商寄來不同長寬比的照片時，或者你換了佈景主題、所需尺寸又變了的時候。

在傳遞時轉換圖片可以避開這個原地打轉。原圖保持上傳時的樣子，而提供的尺寸由 URL 決定，而不是由幾個月前產生了什麼決定。改格線就改參數。沒有重新產生的過程，也沒有缺少尺寸退回完整原圖的風險。

這一點特別適合目錄，因為同一張商品照片通常以三種尺寸出現：格線方塊、商品頁圖片，以及放大或燈箱檢視。在按圖片計費的模式下，這是每件商品三筆費用。在 Cloudflare 的模式下，無論你有多少商品，這都是三個不同的變體，而同月內的重複請求不產生費用。

我們對 Cloudflare Image Transformations 與 WordPress 圖片外掛 的比較，談了計費模式的差異，以及哪一種適合哪種形態的媒體庫。

按順序該改什麼

按順序做這幾件事。每一件都能單獨衡量，順序亂了就很難判斷究竟是哪一步起了作用。

先弄清楚你是否存在尺寸不符，因為如果存在，在修好它之前其他都不重要。把格線圖片的傳輸大小和它們占據的空間相比。

然後減少頁面請求的圖片數量。如果佈景主題會預先載入移入圖，而你可以不要這個效果，就關掉它。再想一想每頁二十四件商品到底服務了誰，還是十六件配上更快的載入轉換更好。

然後修正延遲載入的邊界，讓第一屏可見的那一列立即載入，而它下面的都不載入。

然後處理傳遞，讓提供的尺寸與顯示的尺寸一致，並在目錄變動時依然正確。

只有在這一切之後，快取才會有實質幫助。快取一個緩慢的頁面只會讓它穩定地慢，而不是變快，而它偏偏是人們最先伸手去拿的一步，因為它最容易安裝。

關於圖片之外更廣的情況，WooCommerce 效能 一文談了資料庫查詢、外掛負擔和未快取的片段，這些同樣會拖慢商店。

找人把它測準

店主通常知道商店感覺很慢，卻不知道十幾種可能原因裡究竟是哪一個。猜測的代價很高，因為那些顯而易見的修正往往正是已經試過的。

Mecanik 提供的 WordPress 效能稽核 會專門測量目錄頁，而不是測一測首頁就算完事；當修正超出設定層面時，也會透過 WordPress 開發 工作承接實作。如果正在流失訪客的是你的分類頁，那麼測量就該從那裡開始。

相關文章: WooCommerce 為什麼慢：真正的四個原因 、網站遷移不掉流量：2026 年完整指南 、Image Transformations 與 WordPress 圖片外掛比較 、電商網站開發：Shopify與客製化開發比較 、電商 GEO：進入 AI 答案的商品資料 。

常見問題

為什麼 WooCommerce 分類頁比商品頁慢？ 商品頁載入一張主圖。分類頁每件商品載入一張，常常因移入圖而加倍，所以二十四件商品可能意味著四十八次圖片請求。同樣的圖片處理方式在商品頁上沒問題，在格線上卻會糟糕地累積。

我怎麼知道 WooCommerce 提供的圖片尺寸不對？ 開啟一個分類頁和瀏覽器網路面板，把格線圖片的傳輸大小與原始上傳檔案相比。如果兩者相近而不是只有一小部分，代表佈景主題請求了 WordPress 從未產生過的尺寸，完整原圖正在瀏覽器裡被縮小。

該重新產生縮圖，還是在傳遞時轉換？ 重新產生能修好目前的目錄，但每次尺寸或佈景主題變動都得重來一次。傳遞時轉換由 URL 決定尺寸，因此在換佈景主題和新上傳之後依然正確，不需要任何重新產生的過程。

延遲載入對 WooCommerce 目錄頁是幫助還是傷害？ 是幫助，因為長格線的大部分都在首屏之下，但第一屏可見的那一列應當立即載入。把可見的最大圖片設為延遲載入會直接延後 Largest Contentful Paint 的測量，而這正是很多佈景主題的預設行為。

每頁放多少商品對效能最好？ 圖片越少頁面越快，但翻頁越多瀏覽時就要點越多次。十六到二十四是常見的取值。這個數字遠不如每張圖片是否尺寸正確重要，因為尺寸得當的二十四張格線勝過尺寸過大的十二張。