Web

ファーストビューに配置したLCP対象画像に loading=lazyはいらない?

投稿日:

1. はじめに

img タグ(画像を表示するHTMLタグです)に「lazy という値を指定した loading 属性」を指定すると、その画像はすぐにダウンロードされません。ブラウザで表示している領域 (viewport) に、画像が入ってきたときにダウンロードが開始され表示されます。この動作により、Webページの読み込み&表示が高速化されます。

ところが、ファーストビュー(最初に画面に表示される範囲)上の画像はすぐに表示される必要があるため、loading=”lazy” を指定すると却ってWebページが遅くなってしまいます。

この動作を確認しようというのが、本記事の目的になります。

2. 実験環境

大きめの画像を画面上部に配置した Webページを用意します。

PC、スマートフォンのどちらからアクセスした場合でも、ファーストビューにこの画像が表示されるようにレイアウトを調整します。また、ファーストビュー上に表示される中で一番サイズが大きい要素がこの画像になるようにします。こうすることで、この画像が LCP (Largest Contentful Paint) の対象となります。今回の解析においても、この画像が LCP (Largest Contentful Paint) の対象となっていることを確認しています。

この画像の img タグに指定する loading 属性値を “eager” (こちらが default値です)、”lazy” のそれぞれを指定した場合とで、それぞれ Performance を解析します。この解析には、Chrome ブラウザのデベロッパーツール (DevTools) に付属の [Performance] パネルを使います。

Chrome DevTools [Performance] パネルによる解析を利用

3. loading=”lazy” の場合

img タグに loading=”lazy” を指定した場合の解析結果です。

loading=”lazy” の場合

画像の中央左にある「Parse HTML (青い四角)」は、HTMLファイルを読み込んでDOMツリーを構築する処理を表しています。その右の「Layout (紫の四角)」は画面上に要素を表示する際のそれぞれのサイズを計算しています。更に右の方にある緑の四角は「Paint」という処理で、画面に各要素をレンダリングしています。

そして大切なのは、その後になってやっと landscape.jpg という画像ファイルに対して「Send Request」が行なわれる点です。

解析結果をより広い範囲で表示した以下の画像を見てください。

loading=”lazy” の場合(広域)

画面中央上あたりの濃い緑の四角が、landscape.jpg ファイルのダウンロード中であることを表しています。

画像ファイルのダウンロードが終わり画面に表示された時点で「LCP」というイベントが発生しています。LCP とは、「ファーストビュー上の一番大きな要素が画面に表示されるまでに掛かった時間」で、CWV (Core Web Vitals) という指標の1つです。CWV は Google検索のランキング要素にもなっているため、なるべく短い時間で表示されることが望まれます。

4. loading=”eager” の場合

img タグに loading=”eager” を指定した場合の解析結果です。 ちなみに、loading属性のデフォルト値がこの “eager” です。

loading=”eager” の場合

Parse HTML」の途中で、画像ファイルに対する「Send Request」が始まっています。画像ファイルのダウンロードをリクエストした後も、Parse HTML は続行されています(画像ファイルのダウンロードは、Parse HTML などをブロックしません)。

loading=”eager” の場合(広域)

広い範囲で見ると loading=”lazy” の場合と同様に、画像ファイルのダウンロードが終わって画面に表示されたタイミングで「LCP」イベントが発生しています。

先程と違い、「L(Load)」イベント(赤い四角)が画像ファイルのダウンロードの後ろになっていますが、このイベントのタイミングは CWV ではありませんので、あまり重要ではありません。

5. 比較する

比較して分かるのは、ファーストビュー上の LCP対象となる画像ファイルに、loading=”lazy” を指定すると、画像ファイルへのリクエストを送信するタイミングが遅くなってしまい、その結果 LCP が悪化してしまうということです。LCP の悪化は、CWV の悪化であり、Google 検索のランキングに対して悪影響 を与えます。

6. おわりに

「検索結果はどうでもよい」というサイト運営者もいると思いますが、画面上の画像表示が遅いということは、単純に「使いにくいページ」なので、どちらかといえば改善した方が良いということになります。但し、ページの表示がそれほど遅いのでなければ、対応する必要はないと思います。

WordPress はバージョン 5.5 から img タグに loading=”lazy” が自動追加されるようになりましたが、本記事でも示した現象のために、5.9 からは記事内の 1つ目の画像に対しては自動追加しなくなるそうです。

7. 参考

📂-Web

執筆者:labo


comment

メールアドレスが公開されることはありません。

関連記事

Web Vitals

Web Vitals patterns の Responsive Images を試してみました

Web Vitals patterns に載っている「Responsive Images」を実際に試してみました。

Google App Engine

Google App Engine にデプロイしてあるファイルをダウンロードする

Google App Engine にデプロイしてあるファイルをダウンロードする方法について説明します。

web development

HTTPレスポンスヘッダ COEP, COOP, CORP, CORS についてのメモ

HTTP Response Header である COEP, COOP, CORP, CORS についてのメモです。

Chrome

Chrome の「ピクチャー イン ピクチャー」機能を使って、YouTube の動画を最前面で再生する

目次1. Chrome の「ピクチャー イン ピクチャー」機能2. ピクチャー イン ピクチャーを行う方法3. プレイヤーの操作など3. おわりに 1. Chrome の「ピクチャー イン ピクチャー …

Web

AMP for WordPress プラグインを使って WordPressサイトをAMP対応する手順

目次1. AMP とは?なぜ、AMP が必要なのか?AMP フレームワーク1. AMP HTML2. AMP JS3. AMP キャッシュその他2. AMP for WordPress プラグインにつ …