延遲載入已成為現代 WordPress 網站必備的速度優化手段，但許多站長對這項功能的理解往往停留在「圖片延後載入」這個層面。事實上，除了圖片外，iframe 和影片也能設定延遲載入，而且還有一些使用情境根本不應該套用這項優化——這些細節往往決定了優化成敗。

深入了解原生 loading 屬性的瀏覽器支援狀況、各類元素的延遲載入方法，以及常見誤區，才能真正讓你的網站在保持快速的同時維持良好的使用者體驗。

原生 loading 屬性的瀏覽器支援現況

WordPress 5.5 在 2020 年 8 月引入了原生延遲載入支援，利用 HTML5 的 loading 屬性來控制圖片和 iframe 的載入時機。這項功能之所以重要，在於它完全不依賴第三方外掛或複雜的 JavaScript——瀏覽器在看到 loading=”lazy” 時，會自動延後載入，直到該元素距離視窗約 50 像素以內才下載。

從瀏覽器支援的角度，loading=”lazy” 已經達到全球主流覆蓋。Chrome、Firefox、Edge 和 Safari 都已實裝該特性，甚至連 Samsung Internet 也包含在內。移動端瀏覽器的支援率更高，因為行動用戶對頻寬敏感，瀏覽器開發商優先實裝了這項功能。簡單來說，如果你的讀者用的是近三年內的任何主流瀏覽器，延遲載入都能正常運作。

不過瀏覽器支援歸支援，WordPress 內部的實裝邏輯也一直在演進。早期版本（WordPress 5.5 到 5.8）對所有圖片和 iframe 都加上 loading=”lazy”，包括頁面上方、首屏內的圖片。這個做法後來被發現會拖累 Core Web Vitals 中最關鍵的指標——最大內容繪製（Largest Contentful Paint, LCP）。到了 WordPress 5.9，官方修正了這個問題，改為只對首頁的第一張圖片和前三個 iframe 排除延遲載入，讓這些重要元素能立刻載入。

圖片延遲載入的正確設定

在 WordPress 網誌的文章頁面上，應用延遲載入最直接的場景就是圖片。每篇文章通常會嵌入數十張配圖，其中大部分用戶永遠不會滑到看見，延遲載入能有效減少初始頁面載入的資源消耗。

WordPress 預設會自動為媒體庫上傳的所有圖片加上 loading=”lazy” 屬性。如果你用的是 5.9 以後的版本，系統已經聰明到不會讓首張圖片被延遲——這通常就是文章的特色圖片，往往是 LCP 候選。不過要確保這項保護真的生效，你需要檢查兩件事：一是你的主題確實有使用 WordPress 內建的圖片顯示函式（get_the_post_thumbnail 或 wp_get_attachment_image），而不是自訂的 HTML；二是特色圖片在首屏位置內，否則系統有可能仍會套用延遲載入。

某些情況下，你也可能想對特定圖片關閉延遲載入。比如說，如果你用了 Gutenberg 編輯器的圖片區塊，可以選中圖片後在右側設定面板找到「Advanced」——展開後有 Attributes 選項，能手動移除 loading=”lazy” 屬性。如果文章內容是用 HTML 直接編寫（而非區塊編輯器），你需要手動刪除 img 標籤裡的 loading=”lazy” 部分。

對於主題開發者來說，如果你要自訂某些圖片的載入行為，可以在呼叫圖片相關函式時帶上 filter，例如用 wp_img_tag_add_loading_optimization_attrs filter 來微調或停用特定圖片的延遲載入。但這通常不是站長級別需要操心的事——大部分情況下，WordPress 預設行為已經經過充分測試。

iframe 和嵌入影片的延遲載入

除了圖片，iframe 也是頁面載入時的重要資源消耗。最常見的 iframe 來自 YouTube、Google Maps、Vimeo 等第三方服務。WordPress 5.7 開始支援 iframe 的原生延遲載入，使用同樣的 loading=”lazy” 屬性。

不過 iframe 的延遲載入有個現實限制：許多嵌入式內容（特別是互動式地圖、實時聊天小工具）在被延遲載入後可能無法正常功能。舉例來說，如果你的頁面裡有 Calendly 或表單這類需要在頁面初始化時建立的 iframe，延遲載入可能會導致這些工具加載時機不對。因此，標準做法是對關鍵的 iframe 關閉延遲載入，只對純粹的媒體類 iframe（YouTube、Vimeo）套用。

針對 YouTube 影片，有個更進階的優化技巧稱為「YouTube 門面」（YouTube Facade）。某些快取外掛（如 WP Rocket）可以把 YouTube iframe 替換成靜態的影片縮圖和播放按鈕，只有用戶點擊時才真正載入 iframe。這種做法比單純的延遲載入更激進，能減少更多初始請求，但代價是增加了前端複雜性。

至於原生 HTML5 的 video 標籤，WordPress 本身不會自動加上 loading=”lazy”——video 元素的延遲載入需要用外掛或自訂程式碼來實現。如果你的網站大量使用自代管的影片（MP4 或 WebM 格式），可以考慮用 Lazy Load for Videos 這類外掛，或者直接在 video 標籤加上 loading=”lazy”（雖然這個屬性對 video 的支援不如 img 廣泛，需要視情況測試）。

首屏關鍵圖片的延遲載入誤區

最常見的優化誤踩的坑就是對首屏的主角圖片（LCP 候選）套用了延遲載入。LCP 代表的是用戶能看見的最大內容元素（通常是 hero banner、文章特色圖或大型展示圖）載入完畢的時間。如果這張圖片被標記為 loading=”lazy”，瀏覽器會延後載入，直到它滑進視窗邊界。結果就是 LCP 時間被硬生生拖長——對 Core Web Vitals 評分造成直接傷害。

Google 在 2021 年的研究發現，網站中大約 30% 的 LCP 圖片都被不當地延遲載入了。為了應對這個普遍問題，WordPress 從 5.9 版開始引入了一個啟發式演算法：預設不對頁面上的前三張圖片和第一個 iframe 套用延遲載入。這個數字是經過實驗選定的，適合大多數部落格和內容網站的版面配置。

不過這個預設並非萬靈丹。如果你的首頁用了非常規的版面設計，可能需要手動調整。比方說，如果你的特色圖片是用背景圖片（CSS background-image）而非 img 標籤實現的，WordPress 的自動豁免機制就失效了——你需要確保背景圖片用 fetch 優先提示（fetch-priority）或預載入（preload）來補償。

驗證首屏關鍵圖片是否被不當延遲載入的最簡單方式，就是用 Google 的 PageSpeed Insights 工具跑測試。如果檢測報告裡出現「Unsized images」或「Avoid deferring critical images」這類建議，就表示有問題。按照建議改正後，重新測試看 LCP 時間是否改善。

快取外掛與延遲載入的搭配

如果你用了 WP Rocket、LiteSpeed Cache 或其他快取外掛，這些工具通常也內建了自己的延遲載入功能。當外掛提供的延遲載入和 WordPress 原生的 loading=”lazy” 同時啟用時，有沒有可能造成衝突？

答案是通常沒問題，但要注意設定。大多數快取外掛的延遲載入是基於 JavaScript 的，會運行時檢測元素是否在視窗內。如果外掛看到圖片上已經有 loading=”lazy”，聰明的外掛會跳過該圖片的 JavaScript 處理，避免重複。但如果你同時啟用了外掛的延遲載入和原生 loading 屬性，且外掛的實裝不夠精良，可能會導致圖片被延遲兩次——先是瀏覽器延遲，再是外掛延遲，反而拖累效能。

最佳實踐是選其一：要嘛依賴 WordPress 5.9+ 的原生 loading，要嘛用外掛的 JavaScript 延遲載入。不過現實中大多數外掛已經能夠和諧共存，因為它們會自動偵測。如果你擔心，可以在測試環境禁用外掛的延遲載入選項，只保留原生 loading，然後用 Lighthouse 跑一次效能測試確認分數沒有下降。

驗證延遲載入是否正確套用

最後，你應該驗證延遲載入是否在你的網站上真的生效了。最直接的方式就是在瀏覽器開發者工具裡檢查元素。打開 DevTools，找到一張你預期應該被延遲載入的圖片（例如頁面下半部的配圖），右鍵選「Inspect Element」檢視 HTML 原始碼。如果看到 loading=”lazy” 屬性，就表示設定成功。反過來說，如果首屏的特色圖片也被標 loading=”lazy”，就有問題了——用前面提到的方式修正。

另一個檢查方法是用 Network 面板模擬低速網路（例如 3G）重新載入頁面，然後觀察圖片載入的時機。如果你往下滑時圖片才開始載入，延遲載入正常運作。如果圖片在你進入頁面時全部立刻開始載入，要嘛是延遲載入沒啟用，要嘛是首屏內的圖片被豁免了（這是正常的）。

對大多數 WordPress 站長來說，原生延遲載入已經夠用，無需額外外掛。只要確保 WordPress 版本足夠新（建議 5.9 以上），並避免對首屏關鍵圖片套用延遲，你的網站效能就能得到明顯提升，同時不會犧牲使用者體驗。