遅延読み込みが多すぎるとパフォーマンスに影響する

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 パーセンタイルの 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 の低下が完全に解消され、遅延読み込みを完全に無効にした場合よりもわずかに改善される可能性があります。遅延読み込みをまったく行わない場合よりも高速になるのはなぜでしょうか。1 つの説明として、スクロールしなければ見えない範囲の画像を読み込まないことで、LCP 画像とのネットワーク競合が減り、より高速に読み込むことができるようになります。

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

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

見出しの単語数や、メイン コンテンツの冒頭にある段落テキストの量など、ページレベルの条件によって、画像がビューポート内に収まるかどうかが変わる可能性があります。また、ユーザーレベルの条件（特にビューポートのサイズや、ページのスクロール位置を変更するアンカーリンクの使用）が、ヒューリスティックの精度に影響する可能性があります。

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

実装

画像の遅延読み込みを改善する方法、画像の節約、LCP パフォーマンスの高速化が確認されたところで、サイトでどのように使用を開始すればよいでしょうか。最優先の変更は、WordPress コアにパッチを送信して、試験運用版の修正を実装することです。ブログ投稿「Browser-level lazy-loading for CMSs」のガイダンスも更新され、スクロールせずに見える範囲の遅延読み込みの悪影響と、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 を使用している場合は、ここで説明するパフォーマンスの問題が発生する可能性があることを CMS の提供元に確認してください。

比較的新しいウェブ プラットフォーム API を試すことには、リスクとメリットの両方が伴います。これらは、最先端の機能と呼ばれる理由があります。ブラウザレベルの画像の遅延読み込みの難しさを理解しつつ、パフォーマンスを向上させるためにどのように使用すればよいかというメリットも確認しています。