<iframe>
元素延遲載入會延遲載入畫面外 iframe,直到使用者捲動接近元素附近為止。這樣可以節省資料、加快頁面其他部分的載入速度,並降低記憶體用量。
瀏覽器支援
- 77
- 79
- 121
- 16.4
向瀏覽器指定要使用 loading
屬性延遲載入 iframe,方法與指定圖片延遲載入的方式相同。
<iframe src="https://example.com"
loading="lazy"
width="600"
height="400"></iframe>
這個 <iframe loading=lazy>
的示範會顯示延遲載入影片嵌入:
為何要採用延遲載入 iframe?
第三方嵌入內容涵蓋各式各樣的用途,包括影片播放器、社群媒體貼文和廣告。這類內容通常不會立即顯示在使用者的可視區域中。相反地,只有在使用者向下捲動頁面時,才能看到這項指標。不過,即便使用者未捲動至畫面,使用者仍須支付下載資料的費用和付出的 JavaScript 費用。
根據 Chrome 的研究,為數據節省模式使用者自動延遲載入畫面外 iframe 的研究顯示,延遲載入 iframe 可使資料量中位數減少 2% 到 3%,首次顯示內容所需時間降低 1% 至 2%,首次輸入延遲時間 (FID) 則在第 95 個百分位數縮短了。
此外,延遲載入畫面外 iframe 可突顯最大內容繪製 (LCP) 的優點。LCP 候選項目,例如取決於網頁字型才能轉譯的圖片或文字。由於 iframe 通常需要大量頻寬,才能載入所有子資源,因此延遲載入螢幕外 iframe 可以大幅減少網路受限裝置的頻寬爭用,為載入資源而產生更多頻寬,進而成為頁面 LCP。
內建 iframe 的延遲載入功能如何運作?
loading
屬性可讓瀏覽器延遲載入畫面外的 iframe 和圖片,直到使用者將畫面捲動到附近為止。loading
支援兩個值:
lazy
:非常適合延遲載入。eager
:不適合延遲載入。立即載入。
在 iframe 上使用 loading
屬性的運作方式如下:
<!-- Lazy-load the iframe -->
<iframe src="https://example.com"
loading="lazy"
width="600"
height="400"></iframe>
<!-- Eagerly load the iframe -->
<iframe src="https://example.com"
width="600"
height="400"></iframe>
如果不指定屬性,效果會與明確載入資源相同。
如果您需要透過 JavaScript「動態」建立 iframe,系統也會支援在元素上設定 iframe.loading = 'lazy'
:
var iframe = document.createElement('iframe');
iframe.src = 'https://example.com';
iframe.loading = 'lazy';
document.body.appendChild(iframe);
延遲載入熱門 iframe 嵌入會造成什麼影響?
如果網頁變更,將延遲載入畫面外 iframe 的設定成為預設,程式碼看起來會像這樣:
延遲載入 YouTube 影片嵌入 (在初次載入時可節省約 500 KB 的內容):
<iframe src="https://www.youtube.com/embed/YJGCZCaIZkQ"
loading="lazy"
width="560"
height="315"
frameborder="0"
allow="accelerometer; autoplay;
encrypted-media; gyroscope;
picture-in-picture"
allowfullscreen></iframe>
Anecdote:我們改用延遲載入的 YouTube 嵌入 Chrome.com 嵌入影片後,縮短了 10 秒的時間,網頁可以在行動裝置上進行互動。我與 YouTube 聯絡時遇到內部錯誤,討論在嵌入程式碼中加入 loading=lazy
的做法。
延遲載入 Instagram 嵌入內容 (在初始載入時可節省約 100 KB 的 gzip 空間):
Instagram 內嵌程式碼和指令碼可提供一個區塊,其可將 iframe 插入您的網頁。延遲載入這個 iframe,可避免載入嵌入所需的所有指令碼。由於這類嵌入通常會顯示在大多數文章的可視區域下方,因此這對 iframe 的延遲載入來說似乎是合理的選擇。
Spotify 內嵌影片 (在初始載入時可節省 514 KB):
<iframe src="https://open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3"
loading="lazy"
width="300"
height="380"
frameborder="0"
allowtransparency="true"
allow="encrypted-media"></iframe>
雖然上述的嵌入說明瞭媒體內容延遲載入 iframe 可能的優點,但廣告或許也能感受到這些好處。
個案研究:延遲載入 Facebook 社交外掛程式
Facebook 社交外掛程式可讓開發人員在他們的網頁中嵌入 Facebook 內容。這些外掛程式有很多種,例如內嵌訊息、相片、影片、留言等等。最熱門的外掛程式是「喜歡外掛程式」,能夠顯示對該頁面「喜歡」的人數。根據預設,在網頁中嵌入類似外掛程式 (使用 Facebook JSSDK) 會提取約 215 KB 的資源 (197 KB 為 JavaScript)。在多數情況下,外掛程式可能會顯示在文章結尾或靠近網頁結尾,因此如果你未開啟螢幕,便可能無法立即載入外掛程式。
感謝工程師 Stoyan Stefanov,Facebook 的所有社交外掛程式現在都支援標準化 iframe 延遲載入。如果開發人員選擇透過外掛程式的 data-lazy
設定選擇延遲載入,現在可以避免在使用者將畫面捲動到附近時載入。這樣一來,如有使用者需要嵌入,嵌入內容仍可完全正常運作,同時對於不需將頁面往下捲動的使用者提供節省資料的時間。我們希望這是其中第一批探索實際工作環境中標準化 iframe 延遲載入的嵌入。
我可以跨瀏覽器延遲載入 iframe 嗎?可
iframe 延遲載入可採用漸進式強化。支援在 iframe 上使用 loading=lazy
的瀏覽器將延遲載入 iframe,但不支援 loading
屬性的瀏覽器則會安全忽略。
您也可以使用 lazysizes JavaScript 程式庫延遲載入螢幕外 iframe。以下情況可能適合您:
- 相較於現有的標準化延遲載入功能, 需要更多種自訂延遲載入門檻
- 希望為不同瀏覽器的使用者提供一致的 iframe 延遲載入體驗
<script src="lazysizes.min.js" async></script>
<iframe frameborder="0"
class="lazyload"
allowfullscreen=""
width="600"
height="400"
data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>
請使用以下模式,在不可用的情況下偵測延遲載入功能,並擷取延遲:
<iframe frameborder="0"
class="lazyload"
loading="lazy"
allowfullscreen=""
width="600"
height="400"
data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>
<script>
if ('loading' in HTMLIFrameElement.prototype) {
const iframes = document.querySelectorAll('iframe[loading="lazy"]');
iframes.forEach(iframe => {
iframe.src = iframe.dataset.src;
});
} else {
// Dynamically import the LazySizes library
const script = document.createElement('script');
script.src =
'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.2.2/lazysizes.min.js';
document.body.appendChild(script);
}
</script>
是否仍會載入包含 loading=lazy
的螢幕外 iframe?
進行早期實驗,針對 Chrome 數據節省模式使用者採用自動延遲載入 iframe 的早期實驗,隱藏 iframe 的例外狀況 (通常用於通訊或分析) 除外。這些方法可避免延遲載入並隨時載入,以免破壞這些功能。
只要使用 loading
屬性,開發人員即可選擇此屬性,這樣開發人員就不會套用這類經驗法則,而且 loading
屬性應一律遵循距離限制和其他瀏覽器選擇 (例如列印) 選項。
結語
請參閱 web.dev 的圖片和影片延遲載入集合,瞭解更多延遲載入的靈感。
感謝 Dom Farolino、Scott Little、Houssein Djirdeh、Simon Pieters、Kayce Basques、Joe Medley 和 Stoyan Stefanov 進行評論。