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

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

Felix Arntz

Rick Viscomi

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

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

養子縁組

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

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

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

相関性のパフォーマンス

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

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

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

残念ながら、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 の回帰を完全に逆転させ、遅延読み込みを完全に無効にした場合にもわずかな改善となる可能性があります。遅延読み込みをまったくしないより早くできる方法はあるのでしょうか。たとえば、スクロールしなければ見えない範囲の画像が読み込まれないことで、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）