多數人推動網站效能優化的第一步，就是把所有圖片統一掛上 loading="lazy"，覺得延遲載入用得越普遍，頁面就跑得越快。這個假設放到網站最重要的首屏上，答案卻剛好相反——有研究團隊拿真實使用者的瀏覽資料回頭檢驗，結果是有用延遲載入的網頁，LCP 的中位數反而比沒用的網頁慢。
延遲載入本身沒有錯，問題出在「無差別」三個字。第一眼看到的畫面，尤其是決定 Largest Contentful Paint（LCP，Google 用來評估網頁體驗的核心指標之一）的那張圖，如果也被延遲載入，瀏覽器反而要多等一輪版面確認才肯開始下載，首屏因此變慢，還可能拖累 Core Web Vitals 這項指標的分數。我們的立場很清楚，不是延遲載入該不該用，是首屏與 LCP 候選圖片這條線，不該被畫進「全部延遲」的那一邊。
首屏內容不套用延遲載入是我們的立場
延遲載入的技術定義很簡單，但常被誤解。根據 MDN 的說明，它是 HTML 一個叫 loading 的屬性，可以加在 <img>、<iframe>、<video>、<audio> 這幾種標籤上，用來告訴瀏覽器，當一個元素還落在畫面外，先別急著下載它連結的資源，等使用者捲動到附近再觸發載入。這個機制已經寫進 HTML 標準，目前主流瀏覽器都支援圖片與 iframe 的延遲載入。
有一個常被忽略的限制，延遲載入不適用於 CSS 背景圖片，只能用在 <img> 標籤本身。不少網站用 CSS background-image 呈現橫幅或裝飾圖，不管加幾次 loading="lazy" 都救不了它，這也是實務上常見的誤用。
搞懂技術定義之後，我們的立場才講得清楚，全站無差別套用 loading="lazy"，尤其是連首屏、連 LCP 候選元素都一起延遲，是做過頭。正確的做法應該是，只對確定落在初始可視區域以外的圖片或 iframe 用延遲載入；可視區域內，尤其是 LCP 候選元素，維持瀏覽器預設的急切載入，真的需要加速時再用 fetchpriority="high" 明確告訴瀏覽器「這張最重要」。
這裡要先講清楚一件事，我們的立場不是「別用延遲載入」，是「別對首屏、LCP 元素用延遲載入」。這條界線才是判斷延遲載入該不該用的關鍵，不是用不用，是畫在哪裡。
全站延遲載入讓多數網站中位數 LCP 明顯變慢
第一個依據來自大規模的真實使用者資料。Google Chrome 團隊的 Felix Arntz 與 Rick Viscomi 拿 HTTP Archive 的資料庫做過一次比對，找出跑得到 LCP 量測的網站，再依「有沒有用延遲載入」分成兩組看中位數。結果是，以各網站真實使用者第 75 百分位的 LCP 來比，沒有用延遲載入的網站，中位數是 2,922 毫秒；有用延遲載入的網站，中位數是 3,546 毫秒，慢了超過 600 毫秒。
把樣本縮小到只看 WordPress 網站，這個落差依然存在。沒有延遲載入功能的 WordPress 網頁，中位數 LCP 是 3,495 毫秒；有延遲載入功能的，中位數 LCP 是 3,768 毫秒。之所以特別把 WordPress 抽出來看，是因為它牽動的範圍很大，同一份資料顯示，使用瀏覽器層級圖片延遲載入的網站裡，高達 84% 是 WordPress，只有 2% 用其他 CMS，剩下 14% 沒有偵測到已知的 CMS。換句話說，延遲載入這個功能，絕大多數是透過 WordPress 內建機制或外掛在跑，它的表現好壞，直接影響的是一大票 WordPress 網站的效能。
不過，Arntz 與 Viscomi 在報告裡明講這只是相關性資料，不代表延遲載入就是效能變慢的原因，就算縮小到 WordPress 網站、排除平台本身快慢的差異，看到的仍然只是兩者同時發生，不等於互為因果。真正能證明因果關係的，是這組 A/B 測試。
只延遲首屏以下的圖片，效果反而優於全面停用
第二個依據是真正的因果證明。Google Chrome 團隊直接拿 WordPress 內建的 twentytwentyone 佈景主題做 A/B 測試，比較三種狀態的表現：預設（所有圖片一律延遲）、停用（所有圖片都不延遲）、修正（只有第一張精選圖片或主要內容的第一張圖不延遲，其餘照常延遲）。
在文章列表頁，桌面版的中位數 LCP，預設是 2,029 毫秒、停用是 1,759 毫秒（比預設快 13%）、修正是 1,749 毫秒（比預設快 14%，比停用又再快 1%）。行動版的落差更明顯，預設是 1,657 毫秒、停用是 1,403 毫秒（比預設快 15%）、修正是 1,352 毫秒（比預設快 18%，比停用又再快 4%）。修正方案不只追上完全停用延遲的效果，還更快一點。
真正關鍵的地方在圖片位元組數，修正版跟預設版完全一樣，沒有任何增加。也就是說，「只延遲首屏以下的圖片」同時拿到兩種好處，流量沒有變多，LCP 卻比完全停用延遲還快。這不是省流量與速度只能二選一的取捨，是能同時拿到的結果。
WordPress 判斷「要不要延遲某張圖片」的邏輯，其實是一套伺服器端的經驗法則，不是真的量測使用者的螢幕。如果這張圖是網頁上第一張精選圖片，或是主要內容裡的第一張圖，系統就假設它落在可視區域內、不延遲載入；除此之外的圖片，一律照常延遲。Arntz 與 Viscomi 也坦承這只是經驗法則，像標題字數多寡、主要內容前段的文字量這類網頁層級的條件，都可能影響一張圖實際上會不會出現在可視區域內；使用者層級的條件，例如螢幕大小、或使用錨點連結改變捲動位置，同樣會讓判斷失準。正因為這套推論不是萬無一失，才更需要人工檢查首屏附近的圖片有沒有被誤判。
首屏圖片應維持瀏覽器預設的急切載入順序
第三個依據，是 Google 在 web.dev 給開發者的直接建議，也是背後的技術機制解釋。web.dev 的建議很直接，第一個可視區域中顯示的圖片，尤其是 LCP 圖片，一律用瀏覽器的預設急切載入，確保能立即開始下載；延遲載入只該用在初始可視區域外的圖片。
技術機制上，圖片本來就不是會阻擋瀏覽器算繪的資源，所以瀏覽器預設不會把圖片放在最優先的等級。以 Chrome 為例，圖片預設從低優先權開始，要等版面配置完成、確認圖片落在可視區域內，才會把它拉高到高優先權。如果同時又幫這張圖加上 loading="lazy"，等於疊加了兩重延遲，瀏覽器要等到版面配置確認圖片落在可視區域內，才會開始載入這個資源，對決定 LCP 分數的那張圖尤其不利。
遇到判斷得出來的 LCP 候選圖片，web.dev 建議直接加上 fetchpriority="high"，讓瀏覽器一開始就把這張圖放進高優先權佇列，不用等版面配置確認、提早開始下載。但這個屬性不是萬靈丹，web.dev 也明講，如果同一頁把超過一、兩張圖片都設成高優先權，等於每一張都最重要，結果是沒有一張真的優先，優先順序機制就無法有效改善 LCP。換句話說，fetchpriority="high" 該用在真正判斷得出來的 LCP 候選圖片上，不是能加的地方都加。
圖片與嵌入內容多的長頁面，延遲載入仍然值得做
轉到另一面看，如果整頁內容本來就長、圖片多，或是嵌入很多第三方內容，像社群貼文、影片、音樂播放器，延遲載入省下來的資料量非常可觀，不該因為擔心誤傷首屏就整頁棄用。
同一組 A/B 測試裡，完全停用延遲載入之後，圖片位元組數暴增。文章列表頁桌面版，圖片資料量從 577 KB 增加到 1,173 KB，多了 103%；行動版從 172 KB 增加到 378 KB，多了 120%。單篇文章頁的落差更大：桌面版從 301 KB 增加到 850 KB，多了 183%；行動版從 114 KB 增加到 378 KB，多了 233%。對用行動網路、流量有限的讀者來說，這個差距直接反映在能不能順利把頁面看完。
iframe 的延遲載入更值得做，因為它牽涉的資料量常常比一張圖片大得多。Google Chrome 團隊的 Addy Osmani 與 Barry Pollard 整理過幾個真實案例：延遲載入 YouTube 影片嵌入，能在初始載入時省下約 500 KB；延遲載入 Spotify 嵌入，能省下 514 KB；延遲載入 Instagram 嵌入，能省下約 100 KB，還能避免多載入一整批不必要的指令碼；用 Facebook 自家 JSSDK 嵌入的「讚」外掛，單獨就會拉進約 215 KB 資源，其中 197 KB 是 JavaScript。
Chrome 團隊也針對開啟省資料模式的使用者做過研究，自動延遲畫面外的 iframe，資料量的中位數能省下 2% 到 3%，中位數的首次內容繪製改善 1% 到 2%，第 95 百分位的首次輸入延遲改善 2%。iframe 延遲載入對 LCP 也有幫助，原因是 iframe 通常需要大量頻寬才能載入所有子資源，把它們延後，能讓更多頻寬留給真正影響 LCP 的資源。
為了規避風險而整頁停用延遲載入，同樣是做過頭
看到這裡，另一種常見的反應是反過來走向另一個極端，因為怕延遲載入誤傷 LCP，乾脆整頁圖片都不延遲，或是把整頁圖片全部設成 fetchpriority="high"。這同樣是無差別處理，只是換了個方向做過頭。
web.dev 講得很明白，如果一頁裡有超過一、兩張圖片同時設成高優先權，優先順序機制本身就會失效，無法有效改善 LCP，等於白白多加了一個屬性卻沒有效果。而整頁都不延遲載入，又會失去前一節列出的那些位元組節省，單篇文章頁最多會多出 233% 的圖片資料量，對行動網路使用者尤其吃力。
iframe 也有類似的例外要注意。Chrome 團隊早期在為省資料模式使用者自動延遲 iframe 的實驗中就發現，用於通訊或分析用途的隱藏 iframe，必須排除在自動延遲之外，一律照常載入，否則會破壞這些功能原本該有的運作方式。loading 屬性本身不會自動套用這種例外判斷，一個 iframe 要不要延遲，仍然要由開發者自己判斷。
問題從來不是要不要用延遲載入，是有沒有分清楚哪些內容該延遲、哪些不該。首屏與 LCP 候選元素給瀏覽器預設的急切載入，必要時用 fetchpriority="high" 加速，但只給真正的 LCP 元素，不是見圖就加；首屏以下、頁面後段、大量嵌入內容，維持延遲載入不變。兩個方向的「全站一刀切」都不對，能不能分清楚這條界線，才是判斷一個網站延遲載入用得好不好的關鍵。
延遲載入從來不是「用」或「不用」的二選一問題，是分寸的問題。首屏與 LCP 候選圖片，交給瀏覽器的預設行為去處理；首屏以下的內容，放心延遲，把流量留給真正決定使用者第一眼觀感的那幾個資源。真的想知道自己的網站有沒有做對，不必用猜的，直接打開瀏覽器的開發人員工具看一次網路面板，找出首頁載入時最先出現的那張圖，確認它有沒有被誤標成延遲載入。這一個檢查動作，往往比讀完整套規則更快看出問題在哪裡。