遅延読み込みが多すぎる場合のパフォーマンスへの影響

Core Web Vitals を念頭に置いた画像の遅延読み込みに関するデータドリブンのアドバイス。

Felix Arntz

Rick Viscomi

遅延読み込みとは、重要なアセットのデータを保存し、ネットワーク競合を減らすために、必要になるまでリソースのダウンロードを延期する手法です。これは 2019 年にウェブ標準になり、現在では画像の loading="lazy" はほとんどの主要なブラウザでサポートされています。

このガイドでは、一般公開されているウェブの透明性に関するデータとアドホック A/B テストを分析して、ブラウザレベルの画像の遅延読み込みの採用とパフォーマンスの特性を理解する方法について説明します。遅延読み込みは不要な画像のバイト数を減らすうえで驚くほど効果的なツールであり、過剰に使用するとパフォーマンスに悪影響を及ぼすということがわかりました。具体的には、この分析により、最初のビューポート内で画像の読み込みを強めにし、残りをゆるやかに遅延読み込みすることで、両方の長所を活かせることがわかりました。読み込みバイト数が減り、Core Web Vitals が改善されています。

養子縁組

HTTP Archive の最新のデータによると、組み込みの画像遅延読み込みはウェブサイトの 29% で使用され、その導入は急速に増加しています。

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

HTTP Archive プロジェクトの元データをクエリすることで、導入を促進しているウェブサイトの種類をより明確に把握できます。ブラウザレベルの画像の遅延読み込みを使用するサイトの 84% は WordPress を使用し、2% は別の CMS を使用し、残りの 14% は既知の CMS を使用していません。これらの結果から、WordPress がどのように導入をリードしているかがよくわかります。

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

導入率も注目に値します。1 年前の 2020 年 7 月、遅延読み込みを使用している WordPress サイトは、約 600 万件（全体の 1%）のコーパスに数万のウェブサイトを構成していました。それ以来、WordPress だけでも遅延読み込みを導入したウェブサイトは 100 万を超えるウェブサイト（全体の 14%）にまで成長しています。

相関性のパフォーマンス

HTTP Archive を深く掘り下げて、Largest Contentful Paint（LCP）指標を使用して、ブラウザレベルの画像の遅延読み込みを行ったページと含まないページのパフォーマンスを比較できます。LCP データは、ラボの合成テストではなく、Chrome ユーザー エクスペリエンス レポート（CrUX）の実際のユーザー エクスペリエンスに基づいています。次のグラフは、箱ひげ図を使用して各ページの分布を可視化しています75 パーセンタイル LCP: 折れ線は 10 パーセンタイルと 90 パーセンタイルを表し、箱は 25 パーセンタイルと 75 パーセンタイルを表します。

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

遅延読み込みなしのページの 75 パーセンタイル LCP は 2,922 ミリ秒で、遅延読み込みありのページの中央値は 3,546 ミリ秒です。全体的に、遅延読み込みを使用しているウェブサイトは LCP のパフォーマンスが低下する傾向があります。

これらは相関的な結果であり、必ずしも遅延読み込みがパフォーマンス低下の原因であるとは限らないことに注意してください。仮に、WordPress のサイトが少し遅くなる傾向があり、遅延読み込みコホートにどれほど多く含まれているかを考えれば、それが違いの原因である可能性があります。このばらつきを取り除くために、特に WordPress サイトに焦点を絞ることができます。

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

残念ながら、WordPress ページにドリルダウンしても同じパターンが現れます。遅延読み込みを使用すると LCP パフォーマンスが低下する傾向にあります。遅延読み込みなしの WordPress ページの中央値は 75 パーセンタイル 3,495 ミリ秒で、遅延読み込みありのページの中央値は 3,768 ミリ秒です。

これでは、遅延読み込みによってページの読み込みが遅くなることは証明されませんが、遅延読み込みを使用するとパフォーマンスが低下することがあります。因果関係の問いに答えるために、ラボベースの A/B テストを設定しました。

因果的パフォーマンス

A/B テストの目標は、WordPress コアに実装された組み込みの画像遅延読み込みにより、LCP パフォーマンスが低下し、画像バイト数が減少するという仮説を証明または反証することでした。手法としては、twentytwentyone テーマで WordPress ウェブサイトのデモをテストしました。ホームページや記事ページのようなアーカイブ タイプと単一ページ タイプの両方を、パソコンとエミュレートしたモバイル デバイスで WebPageTest を使用してテストしました。遅延読み込みを有効にした場合と無効にしたページの組み合わせをテストし、各テストを 9 回実行して LCP 値と画像のバイト数の中央値を取得しました。

この結果では、アーカイブと単一ページのテストで、パソコンとモバイルで LCP の中央値をミリ秒単位で比較しています。アーカイブ ページで遅延読み込みを無効にした場合、LCP は大幅に改善されました。一方、単一ページでは、それほど大きな違いはありません。

遅延読み込みを無効にすると、1 つのページがわずかに速くなるようです。しかし、パソコンとモバイルのテストの両方で LCP の差は 1 標準偏差未満であるため、これは分散に起因する可能性があり、全体的に変化とは無関係であると考えられます。比較すると、アーカイブ ページの場合、標準偏差は 2 ～ 3 に近くなります。

これらの結果では、各テストの画像バイト数の中央値（KB 単位）が比較されます。予想どおり、遅延読み込みは画像のバイト数を減らすうえで非常に明確な効果があります。実際のユーザーがページ全体をスクロールした場合、ビューポートに横切ってすべての画像が読み込まれます。しかし、これらの結果から、最初のページ読み込みのパフォーマンスが向上しています。

A/B テストの結果をまとめると、WordPress で使用されている遅延読み込みの手法は、LCP の遅延と引き換えに画像のバイト数を減らすのに非常に役立ちます。

修正のテスト

「WordPress」で最も重要な点は、このテストでの現在の遅延読み込みの実装は、ビューポート内（スクロールせずに見える範囲）の画像の遅延読み込みです。CMS のブログ投稿では、これを回避するためのパターンとして認めていますが、その時点での実験的なデータによると、LCP への影響は最小限であり、WordPress コアへの実装を簡素化する価値があることがわかりました。

この新しいデータに基づき、スクロールせずに見える範囲の画像の遅延読み込みを回避する実験的な修正を作成し、最初の A/B テストと同じ条件で修正をテストしました。

この結果はずっと前途有望です。スクロールしなければ見えない範囲の画像のみに遅延読み込みを行うことで、LCP の回帰を完全に逆転させ、遅延読み込みを完全に無効にすることによる改善をわずかに実現できる可能性もあります。遅延読み込みをまったくしないより早くできる方法はあるのでしょうか。説明の 1 つは、スクロールしなければ見えない範囲の画像を読み込まないことで、LCP 画像とのネットワーク競合が減り、より迅速に読み込めることです。

画像のバイト数については、デフォルトの動作と比べると、修正による変化はまったくありません。これが現在のアプローチの強みの一つであったため、これは素晴らしいことです。

この修正にはいくつかの注意点があります。WordPress は、サーバー側でどの画像を遅延読み込みするかを決定します。つまり、ユーザーのビューポートのサイズや、画像が最初に読み込まれるかどうかについては、WordPress は把握していません。修正には、画像のヒューリスティックがマークアップ内の相対位置を使用して、ビューポートに読み込まれるかどうかを推測します。具体的には、画像がページの最初の注目画像またはメイン コンテンツの最初の画像である場合は、スクロールせずに見える範囲またはそれに近い位置にあるとみなされ、遅延読み込みは行われません。

見出しの単語数やメイン コンテンツの初期の段落テキストの量など、ページレベルの条件は、画像がビューポート内に表示されるかどうかに影響します。また、ヒューリスティックの精度に影響を与える可能性のあるユーザーレベルの条件もあります。特にビューポートのサイズや、ページのスクロール位置を変更するアンカーリンクの使用などです。

そのため、この修正は一般的なケースで優れたパフォーマンスを発揮するように調整されているだけであり、これらの結果をすべての現実のシナリオに適用するためには微調整が必要になる可能性があることを認識しておくことが重要です。

実装 (:#implementation)

画像を遅延読み込みするより良い方法が特定され、画像の削減と LCP パフォーマンスの高速化が実現しました。これをサイトで利用を開始するにはどうすればよいでしょうか。最も優先すべき変更は、WordPress のコアにパッチを送信して試験運用版の修正を実装することです。また、ブログ投稿「CMS のブラウザレベルの遅延読み込み」のガイダンスも更新され、スクロールせずに見える範囲の遅延読み込みによる悪影響と、CMS がヒューリスティックを使用してこれを回避する方法が明確化されます。

ここで紹介するベスト プラクティスはすべてのウェブ デベロッパーに当てはまるため、Lighthouse などのツールで遅延読み込みのアンチパターンにフラグを立てるのもおすすめです。監査の進捗状況を確認したい場合は、GitHub の機能リクエストを参照してください。それまでは、遅延読み込みされている LCP 要素のインスタンスを見つけるために、フィールド データにより詳細なロギングを追加することをおすすめします。

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

上記の JavaScript スニペットは、最新の LCP 要素を評価し、遅延読み込みされた場合は警告をログに記録します。

これはまた、遅延読み込み手法の鋭いエッジと、プラットフォーム レベルでの API の改善の可能性も浮き彫りにしています。たとえば、Chromium には未解決の問題があり、loading 属性にかかわらず、最初のいくつかの画像をネイティブに積極的に読み込むことをテストしています。

まとめ

ブラウザレベルの画像の遅延読み込みを使用しているサイトでは、実装方法を確認し、A/B テストを実施してパフォーマンス コストを詳しく把握します。スクロールせずに見える範囲に、積極的に画像を読み込むと効果的です。WordPress サイトをお持ちの場合、まもなく WordPress コアにパッチが提供される予定です。別の CMS を使用している場合は、ここで説明する潜在的なパフォーマンスの問題を認識するようにしてください。

比較的新しいウェブ プラットフォーム API を試すことは、リスクと恩恵の両方を伴います。最先端の機能と呼ばれるのには理由があります。ブラウザレベルの画像遅延読み込みには細かな面があるという認識が広まりつつある一方で、これを使用してパフォーマンスを向上させる方法にも利点が見えてきています。

写真撮影: Frankie Lopez（出典: Unsplash）