Googleデベロッパーが解説、Webページに画像の遅延読み込みを使いすぎるとパフォーマンスに悪影響を与える

Post on:2021年8月5日

はじめに

遅延読み込み（lazy-loading）とは、リソースのダウンロードをそのリソースが必要になるまで延期（遅延）させるテクニックです。これにより最初に読み込むデータ量が少なくなり、重要な資産に対するネットワークの競合を減らすことができます。

このテクニックは2019年にWeb標準となり、現在ではloading="lazy"はほとんどのブラウザでサポートされています。そのことは素晴らしいですが、遅延読み込みが多すぎるということはないでしょうか？
参考: lazy-loadingのサポートブラウザ

この記事では、ネイティブ画像の遅延読み込みの採用とパフォーマンスを理解するために、Web透過性データとアドホックABテストを分析した方法を解説します。

先に結果をお伝えしておくと、遅延読み込みは不要な画像のバイト数を減らすために非常に効率的なツールですが、使いすぎるとパフォーマンスに悪影響を与えることがわかりました。具体的には、最初のビューポート内では画像を懸命に読み込みますが、それ以外は遅延読み込みさせることでロードするバイト数の削減とCore Web Vitalの向上という両方の利点が得られることが分析からわかりました。

遅延読み込み（lazy-loading）についての基礎知識や最大限のパフォーマンスを発揮させる実装方法については、先日の記事も参考にどうぞ。

遅延読み込みを採用しているサイトは増加している

HTTP Archiveの最新調査によると、ネイティブ画像の遅延読み込みは17%のWebサイトで使用されており、採用率は急速に増加しています。比較的新しいAPIでありながら、これほどまでにエコシステムに定着しているのは注目に値します。

ネイティブ画像の遅延読み込みを使用しているサイトの種類の内訳（ソース）

HTTP Archiveプロジェクトの生データをクエリすると、どのような種類のWebサイトが採用を促進しているかを明確に理解することができました。

ネイティブ画像の遅延読み込みを使用しているサイトの84%はWordPressで、2%は他のCMSで、残りの14%はCMSを使用していませんでした。これらの結果から、WordPressがいかに普及をリードしているかが明らかになりました。

遅延読み込みを使用しているサイト数の変移（ソース）

採用率の変移も注目に値します。
1年前の2020年7月では遅延読み込みを採用しているWordPressのサイトは約600万の中で数万（全体の1%）だけでした。その後、WordPressだけでも遅延読み込みを採用しているサイトは100万以上（全体の14%）にまで成長しています。

相関性の高いパフォーマンス

HTTP Archiveでさらに詳しく調べてみると、ネイティブ画像の遅延読み込みがあるページとないページのパフォーマンスをLargest Contentful Paint（LCP）メトリクスを使って比較できます。LCPのデータはラボでの総合的なテストではなく、Chrome User Experience Report（CrUX）の実際のユーザーエクスペリエンスに基づいています。

下記のグラフは箱ひげ図を用いて、各ページの75パーセンタイルLCPの分布を視覚化したものです。ひげの部分は10パーセンタイルと90パーセンタイルを表し、箱は25パーセンタイルと75パーセンタイルを表します。
※パーセンタイルとは、データを小さい順にならべて100個に区切り、小さいほうから数えてどの位置にあるかを見るものです。

全ページの75パーセンタイルのLCPエクスペリエンスの分布。
ネイティブ画像の遅延読み込みを使用しているかどうかで分類しています。（ソース）

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

ここで重要なのは、この結果は相関関係にあるということで、必ずしも遅延読み込みがパフォーマンス低下の原因であるとは言えないということです。仮に、WordPressサイトがやや遅くなる傾向があり、遅延読み込みコホートに占める割合が高いとすれば、その違いを説明できるかもしれません。そこで、WordPressサイトだけを対象にして、そのばらつきをなくしてみます。

WordPressページの75パーセンタイルLCPエクスペリエンスの分布。
ネイティブ画像の遅延読み込みを使用しているかどうかで分類しています。（ソース）

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

この結果は、遅延読み込みがページの表示速度を低下させる原因であることを証明するものではありませんが、遅延読み込みを使用するとパフォーマンスが低下するのと同時に発生します。
因果関係を明らかにするために、ラボベースでABテストをしてみました。

因果関係を調べる

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

表は左から、ページの種類、デフォルト、無効、デフォルトとの違い

上記の結果は、デスクトップとスマホのアーカイブページとシングルページのテストにおけるLCPの中央値をミリ秒単位で比較したものです。アーカイブページで遅延読み込みを無効にすると、LCPが大幅に改善していることがわかります。しかし、シングルページではその差はほとんどありませんでした。

注目すべきは、遅延読み込みを無効にしたことにより、シングルページがわずかに速くなったように見えることです。しかし、LCP の差はデスクトップとスマホの両方のテストで1標準偏差未満であるため、これは分散によるものとし、全体的には中立的な変化であると考えます。それに比べて、アーカイブページの差は2-3標準偏差になっています。

続いて、ネイティブ画像の遅延読み込みを無効にした場合の画像のバイト数（Kb）を見てましょう。

表は左から、ページの種類、デフォルト、無効、デフォルトとの違い

上記の結果は、画像のバイト数（Kb）の中央値を比較したものです。予想通り、画像のバイト数を減らす目的で遅延読み込みは非常に明確なプラス効果があります。実際のユーザーがページ全体を下にスクロールした場合、すべての画像はビューポートに交差したときに読み込まれますが、この結果は最初のページ読み込みのパフォーマンスが向上していることを示しています。

ABテストの結果をまとめると、WordPressで採用されている遅延読み込みの技術は画像バイトの削減に非常に明確な効果がありますが、その代償としてLCPの遅延が発生します。

修正して再テスト

修正がどのように実施されたかを説明する前に、現在のWordPressでの遅延読み込みがどのように機能するかを見てみましょう。最も重要な点は、折り目の上（ビューポート内）の画像を遅延読み込みすることです。CMSの記事では、これは避けるべきパターンとして認めていますが、当時の実験データではLCPへの影響は最小限であり、WordPressコアでの実装を簡素化する価値があるとされていました。

この新しい情報を考慮して、折り目より上にある画像の遅延読み込みを回避する実験的な修正案を作成し、最初のABテストと同じ条件でテストをしました。

表は左から、ページの種類、デフォルト、無効、修正、デフォルトとの違い、無効との違い

この結果は、はるかに有望です。折り目の下の画像のみを遅延読み込みすると、LCPの後退が完全に逆転し、LCPを完全に無効にするよりもわずかに改善する可能性があります。遅延読み込みを全くしないよりも速くなるとはどういうことでしょうか？ 1つの説明としては、折り目の下の画像を読み込まないことで、LCP画像とのネットワーク競合が少なくなり、LCP画像がより早く読み込むことができるということです。

表は左から、ページの種類、デフォルト、無効、修正、デフォルトとの違い、無効との違い

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

この修正にはいくつかの注意点があります。WordPressはどの画像を遅延読み込みするかをサーバーサイドで決定します。つまり、ユーザーのビューポートサイズや画像がビューポート内に最初に読み込まれるかどうかについては何も知らないということです。

そのため、この修正ではマークアップ内の画像の相対的な位置に関するヒューリスティック手法を用いて、画像がビューポート内にあるかどうかを推測します。具体的には、画像がページの最初の打ち出し画像またはメインコンテンツの最初の画像である場合、その画像は折り目の上（またはそれに近い位置）にあると見なされ、遅延読み込みはおこなわれません。見出しの語数やメインコンテンツの最初の段落テキストの量などのページレベルの条件は、画像がビューポート内にあるかどうかに影響を与える可能性があります。また、ビューポートサイズやページのスクロール位置を変更するアンカーリンクの使用など、ヒューリスティックの精度に影響を与えるユーザーレベルの条件もあります。

これらの理由から、この修正は一般的なケースで良好なパフォーマンスを提供するためにのみ調整されているだけであり、この結果をすべてのシナリオに適用するためには微調整が必要であることを認識することが重要です。

ロールアウト

画像を遅延読み込みするためのより良い方法、すべての画像の制約、LCPパフォーマンスの高速化が判明した今、サイトで実際に使用するにはどうすればよいと思いますか？

最も優先度の高い変更点は、実験的な修正を実装するパッチをWordPressコアに送信することです。また、ブログ記事「Browser-level lazy-loading for CMSs」のガイダンスを更新して、折り目を超える遅延読み込みの悪影響とCMSがヒューリスティックを使用してそれを回避する方法を明確にする予定です。

これらのベストプラクティスはすべてのWeb開発者に当てはまるので、Lighthouseなどのツールで遅延読み込みのアンチパターンを指摘することも価値があるでしょう。この監査の進捗状況を知りたい方は、GitHubのfeature requestを参照してください。それまでは、開発者がLCP要素の遅延読み込みの事例を見つけるためにできることは、フィールドデータにさらに詳細なログを追加することです。

webVitals.getLCP(lcp => {
  const latestEntry = lcp.entries[lcp.entries.length - 1];
  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
});

webVitals.getLCP(lcp => {

const latestEntry = lcp.entries[lcp.entries.length - 1];

if (latestEntry?.element?.getAttribute('loading') == 'lazy') {

console.warn('Warning: LCP element was lazy loaded', latestEntry);

}

});

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

これにより、遅延読み込みの技術とプラットフォームレベルでのAPI改善の可能性も浮き彫りになりました。例えば、Chromiumでは、loading属性があるにもかかわらず、今回の修正と同様に最初の数枚の画像をネイティブに読み込んでしまうという未解決の問題があります。
参考: Issue 996963: LazyLoad

おわりに

サイトでネイティブ画像の遅延読み込みを使用している場合は、その実装方法を確認し、ABテストを実施してパフォーマンスを把握しておいてください。折り目の上にある画像をより熱心に読み込むことでメリットが得られる場合があるかもしれません。WordPressを使用している場合は、近日中に修正がリリースされることを願っています。また、他のCMSを使用している場合は、ここで説明した潜在的なパフォーマンスの問題を認識していることを確認してください。

比較的新しいWebプラットフォームのAPIを試すことには、リスクとリターンの両方を伴います。それらのAPIが最先端の機能と呼ばれるのには理由があります。ネイティブ画像の遅延読み込みの懸念事項がわかってきた一方で、それを利用してパフォーマンスを向上させる方法もわかってきました。