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

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

Felix Arntz

Rick Viscomi

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

この投稿では、ネイティブ イメージの遅延読み込みの採用とパフォーマンスの特性を把握するために、一般公開されているウェブの透明性データとアドホックの A/B テストを分析した方法についてまとめます。遅延読み込みは、不要な画像のバイト数を減らすのに非常に効果的なツールであることがわかりましたが、過度に使用するとパフォーマンスに悪影響を及ぼす可能性があります。具体的には、最初のビューポート内で画像の読み込みを頻繁に行う一方、残りの画像については余裕を持って遅延読み込みを行うことで、読み込みバイト数が減り、Core Web Vitals が改善されます。

養子縁組

HTTP Archive の最新のデータによると、ネイティブ画像の遅延読み込みはウェブサイトの 17% で使用されており、その導入は急速に進んでいます。このエコシステムにおける足がかりとなるのは、比較的新しい API にとっては驚くべきことです。

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 パーセンタイルの LCP が 3,495 ミリ秒であるのに対し、遅延読み込みありのページの中央値は 3,768 ミリ秒です。

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

因果的パフォーマンス

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

上記の結果では、アーカイブ テストとパソコン版とモバイル版の単一ページのテストについて、LCP の中央値（ミリ秒単位）を比較しました。アーカイブ ページで遅延読み込みを無効にしたところ、LCP が大幅に改善されました。一方、単一ページでは、差はよりどちらとも言えません。

遅延読み込みを無効にすると、実際には単一ページがわずかに高速化されることは注目に値します。ただし、パソコンテストとモバイルテストの両方で、LCP の差は標準偏差 1 未満であるため、ばらつきによるものとし、全体としては変化に中立的なものと見なします。比較すると、アーカイブ ページと標準偏差の差は 2 ～ 3 程度です。

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

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

修正のテスト

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

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

より有望な結果が得られます。スクロールしなければ見えない範囲の画像のみを遅延読み込みすると、LCP 回帰が完全に元に戻り、LCP を完全に無効にした場合よりもわずかに改善されることもあります。遅延読み込みを一切行わない場合と比べて、どのように高速化できるでしょうか。1 つの説明として、スクロールしなければ見えない範囲の画像を読み込まないことで、LCP 画像とのネットワーク競合が減り、より迅速に読み込めることが挙げられます。

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

この修正には注意点があります。WordPress は、どの画像をサーバーサイドで遅延読み込みするかを決定します。つまり、ユーザーのビューポート サイズや、画像が最初に内部で読み込まれるかどうかについては、何も認識していません。そのため、修正では、マークアップ内の画像の相対位置に関するヒューリスティックを使用して、画像がビューポート内にあるかどうかを推測します。具体的には、画像がページの最初の注目画像、またはメイン コンテンツの最初の画像である場合、スクロールせずに見える範囲（またはその近く）にあるとみなされ、遅延読み込みは行われません。見出しの単語数やメイン コンテンツの最初の段落テキストの量などのページレベルの条件が、画像がビューポート内にあるかどうかに影響することがあります。また、ヒューリスティックの精度（特にビューポートのサイズと、ページのスクロール位置を変更するアンカーリンクの使用）に影響するユーザーレベルの条件もあります。このような理由から、修正は一般的なケースで優れたパフォーマンスを提供するためにのみ調整されていること、また、これらの結果を実際のすべてのシナリオに適用できるようにするには、微調整が必要になる場合があることを認識することが重要です。

ロールアウト

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

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

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 を試すと、リスクとメリットの両方が伴います。この API は、最先端の機能と呼ばれるのには理由があります。ネイティブ イメージの遅延読み込みの使い勝手がわかり始めていますが、それを使用してパフォーマンスを向上させる方法にもメリットが見られます。

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