画像と <iframe> 要素の遅延読み込み

多くの場合、画像と <iframe> 要素は他の種類の帯域幅を消費します。 説明します。<iframe> 要素の場合、かなりの追加処理が必要 ページの読み込みとレンダリングにかかった時間です

画像の遅延読み込みの場合、読み込みに失敗した画像の読み込みを 帯域幅の競合を減らすのに役立ちます。 初期ビューポート内のより重要なリソースを確認できますこれにより ページの Largest Contentful Paint(LCP)で、ネットワーク接続が 再割り当てすることで、LCP 候補の読み込みと より速くペイントできるようになります。

<iframe> 要素が関係している部分で、ページの Interaction to Next Paint が (INP)は、遅延読み込みによって起動時に改善できます。これは、 <iframe> は、独自のサブリソースを持つ、完全に独立した HTML ドキュメントです。 <iframe> 要素は別のプロセスで実行できますが、珍しいことではありません。 他のスレッドとプロセスを共有できるようにして、 ユーザー入力に対するページの応答性が低下します

したがって、画面外の画像と <iframe> 要素の読み込みを延期すると、 かなり少ない労力でかなりの労力が必要になるため、 見積もることができますこのモジュールでは、これらの遅延読み込みについて 2 種類の要素を使用して、ページ エクスペリエンスの高速化とユーザー エクスペリエンスの向上を図ります。 クリティカル スタートアップ期間。

loading 属性を使用した画像の遅延読み込み

loading 属性<img> 要素に追加すると、ブラウザに対して 読み込む必要があります。

  • "eager" は、画像を直ちに読み込む必要があることをブラウザに通知します。 表示位置は最初のビューポートの範囲外でも 表示できますこれは、GKE でノードが loading 属性。
  • "lazy" は、指定された距離内になるまで、画像の読み込みを延期します。 表示ビューポートです。この距離はブラウザによって異なりますが、通常は ユーザーがスクロールした時点で画像を読み込むのに十分な大きさであること。
で確認できます。 <ph type="x-smartling-placeholder">

また、<picture> 要素を使用している場合、 loading 属性はその子 <img> 要素に適用する必要があり、適用しないでください。 <picture> 要素自体。これは、<picture> 要素が 異なる値を指す追加の <source> 要素を含むコンテナ ブラウザが選択した候補が直接適用され、 その子 <img> 要素に指定します。

最初のビューポートにある画像を遅延読み込みしない

loading="lazy" 属性は、次の条件を満たす <img> 要素にのみ追加してください。 最初のビューポートの外に配置されますしかし、その状態を把握するのが ページが表示される前のビューポート内の相対的な要素の正確な位置 表示されます。さまざまなビューポートのサイズ、アスペクト比、デバイスを 考慮する必要があります

たとえば、パソコンのビューポートはパソコンのビューポートとは スマートフォンは、画像に収まる可能性のある垂直方向のスペースをレンダリングするためです。 デフォルトのビューポート内には表示されないものの、 使用することもできます。縦向きで使用したタブレットにも表示される デスクトップのスペースよりもかなり大きい できます。

ただし、こうした特定の状況は避けるべきことが明らかな場合もあります。 loading="lazy"を適用しています。たとえば ヒーロー画像の場合は <img> 要素の loading="lazy" 属性。 や、<img> 要素が上部に表示される可能性が高い、その他の画像のユースケース レイアウトの上部付近に折りたたみますこれはさらに重要である (LCP の候補となる可能性が高い画像に対して)

遅延読み込みされる画像は、ブラウザがブラウザのレイアウトを完了するまで待つ必要があります。 画像の最終位置がビューポート内にあるかどうかを知ることができます。つまり 表示可能なビューポートの <img> 要素に loading="lazy" があると すべての CSS がダウンロード、解析され、 未加工マークアップのプリロード スキャナ

<img> 要素の loading 属性は、 ブラウザJavaScript を使用して画像の遅延読み込みを行う必要はありません。たとえば、 ブラウザにすでに用意されている機能を提供するため、追加の JavaScript をページに追加します。 INP など、ページ パフォーマンスの他の側面に影響する。

<ph type="x-smartling-placeholder">

画像の遅延読み込みのデモ

<iframe> 要素の遅延読み込み

<iframe> 要素がビューポートに表示されるまで遅延読み込みすることで、 重要なデータの処理を効率化し、重要なリソースの負荷を軽減 トップレベルページを読み込む必要がありますまた、<iframe> 要素が 基本的には、トップレベルのドキュメント内に読み込まれる HTML ドキュメント全体を、 多数のサブリソース、特に JavaScript が含まれるため、 ページの INP にかなりの影響を与えます。ただし、 大幅に短縮されます。

サードパーティの埋め込みは、<iframe> 要素の一般的なユースケースです。たとえば 埋め込み動画プレーヤーやソーシャル メディアの投稿では、一般的に <iframe> 要素が使用されています。 多数のサブリソースが必要になることが多く トップレベル ページのリソースの帯域幅競合が発生します。として たとえば、YouTube 動画の埋め込みを遅延読み込みすることで、再生中に 500 KiB 以上を節約できます。 最初のページ読み込みと、Facebook の [Like] ボタン プラグインの遅延読み込み 200 KiB 以上を節約できます。そのほとんどは JavaScript です。

いずれの場合も、ページのスクロールしなければ見えない範囲に <iframe> がある場合は、 前もって読み込むことが重要でない場合は、遅延読み込みを検討してください。 そうすることで、ユーザー エクスペリエンスが大幅に向上します。

<iframe> 要素の loading 属性

<iframe> 要素の loading 属性は、 できます。loading 属性の値とその動作は次のとおりです。 loading 属性を使用する <img> 要素の場合と同じです。

  • "eager" がデフォルト値です。<iframe> を読み込むようブラウザに通知します。 要素の HTML とそのサブリソースをすぐに確認できます。
  • "lazy" が、<iframe> 要素の HTML とそのサブリソースの読み込みを延期する。 ビューポートから所定の距離内に収まるまで、コンテナは移動しません。
で確認できます。 <ph type="x-smartling-placeholder">

iframe の遅延読み込みのデモ

ファサード

ページの読み込み中にすぐに埋め込みを読み込むのではなく、 ユーザーの操作に応じて需要を喚起できます。これを行うには、画像を表示することで、 または別の適切な HTML 要素を、ユーザーが操作するまで表示し続けます。完了後 サードパーティの埋め込みで置き換えることができます。 この手法はファサードと呼ばれます。

ファサードの一般的なユースケースは、サードパーティ サービスからの動画の埋め込みです。 埋め込みには多数の追加の読み込みが伴う可能性があり、場合によってはコストもかかります。 動画コンテンツ自体に加え、JavaScript などのサブリソースも追加されています。このような ケース(動画を自動再生する正当な必要性がない限り)- 動画の埋め込み ユーザーは再生前に再生ボタンをクリックして ] ボタンを離します。

これは、画像と似ている静止画像を表示する絶好の機会です 処理時の帯域幅を大幅に節約できますユーザーが 画像をクリックすると、実際の <iframe> 埋め込みに置き換えられます。 サードパーティの <iframe> 要素の HTML とそのサブリソースの開始をトリガーします。 ダウンロードします。

最初のページ読み込みを改善するほか ユーザーが動画を再生しないため、動画の配信に必要なリソースが ダウンロードされます。これは適切なパターンとして、ユーザーがダウンロードするものだけを モデルについて誤った思い込みをすることなく、 提供します

チャット ウィジェットもファサード テクニックの優れたユースケースです。ほとんど チャット ウィジェットは JavaScript を大量にダウンロードし、 ページの読み込みやユーザー入力に対する応答性に影響することがあります。ファイルを読み込む 読み込み時に料金が発生しますが 意図して操作するつもりがないからです

一方、ファサードを使用すると、サードパーティの「Starting チャット」フェイクボタンが付いていますユーザーが有意義に操作すると たとえば、そのアイコンの上に相応の時間、ポインタを置く、または クリック 1 つで、実際のチャット ウィジェットが 必要があります。

独自のファサードを構築することもできますが、オープンソースの 一般的なサードパーティ(lite-youtube-embed など)で利用可能なオプション YouTube 動画、lite-vimeo-embed(Vimeo)、React チャット チャット ウィジェットのローダ

JavaScript 遅延読み込みライブラリ

<video> 要素、<video> 要素の poster 画像を遅延読み込みする必要がある場合は、 CSS の background-image プロパティによって読み込まれた画像、またはその他サポートされていない画像 JavaScript ベースの遅延読み込みソリューションを使用します。たとえば、 lazysizes または yall.js(これらのタイプのリソースの遅延読み込みは 使用できます。

特に、音声トラックなしでの <video> 要素の自動再生とループ は、アニメーション GIF を使用するよりもはるかに効率的な代替手段です。アニメーション GIF を使用すると、 多くの場合、同等のビジュアルの動画リソースよりも数倍大きい 向上しますそれでもなお、帯域幅の面で有利な動画であることに変わりはありません。 遅延読み込みは追加の最適化で 無駄な帯域幅を減らすことができます。

これらのライブラリのほとんどは Intersection Observer API を使用して動作します。また、 また、変更後にページの HTML が変更された場合に、Mutation Observer API を 初期読み込み - 要素がユーザーのビューポートに入ると認識します。もし ビューポートに近づくと JavaScript ライブラリが 非標準属性(多くの場合は data-src または類似の属性)を置き換える。 正しい属性(src など)に置き換えます。

アニメーション GIF を置き換える動画を遅延読み込みしたいとします。 統合できますこれは yall.js で可能で、次のように指定されています。 マークアップ パターン:

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

デフォルトでは、yall.js は、すべての限定された HTML 要素を "lazy"。ページで yall.js が読み込まれて実行されると、動画が正しく実行されません。 ビューポートが表示されるまで読み込みます。この時点で、data-src <video> 要素の子 <source> 要素の属性が入れ替えられます src 属性に割り当てられ、動画をダウンロードするためのリクエストを送信し、 自動的に再生が開始されます。

理解度テスト

次の loading 属性のデフォルト値は、 <img> 要素と <iframe> 要素の両方ですか?

"eager"
"lazy"

JavaScript ベースの遅延読み込みソリューションを使用するのが妥当なのは、どのような場合ですか。

遅延読み込みが可能なリソースの場合。
loading 属性がないリソースの場合 たとえば、動画を置き換える目的で動画を自動再生する場合など、 アニメーション画像を作成したり、<video> 要素の ポスター画像。

ファサードが便利な手法であるケース

大量のデータを使用するサードパーティの埋め込みについては、 提供します。
読み込みに必要なリソースがない、サードパーティの埋め込みでは かなりの確率で発生し すべてのユーザーが やり取りできます。

次のステップ: プリフェッチと事前レンダリング

画像と <iframe> 要素の遅延読み込みを処理できるようになったので、 ページの読み込みを高速化すると同時に ユーザーのニーズを尊重しますただし、 リソースの投機的読み込みが望ましい場合があります。次のモジュールでは、 プリフェッチと事前レンダリングの詳細と、これらの手法を使用する場合 読み込みによって後続のページへの移動を大幅に高速化できます。 事前に通知を受け取れるようにすることです