遅延読み込み（Lazy Loading）は、重要でないリソースを必要になるまで読み込まず、最初の処理を減らす手法です。後回しにしたコンテンツは、見つけられ、使え、クローラーにも届く状態にしておきます。
待たせてよいものを選ぶ
遅延読み込みが向くのは、最初のビューポートからかなり下にあるコンテンツです。ギャラリー下部の画像、埋め込み、長いリストのサムネイルなどが当てはまります。ヒーロー画像、購入者がすぐに見る商品画像、最大のコンテンツ要素、キーボード操作に必要なコンポーネントには、初期設定として向きません。ファーストビューのリソースを後回しにすると、ページが使えるようになる瞬間そのものが遅れることがあります。
読み込み属性を付ける前に、一般的なモバイルとデスクトップの幅で、最初のビューポートに何があるかを洗い出します。LCPの候補になりそうな要素も、先に特定します。画像が届いた後に文章を押し下げないよう、widthとheight、または同等のアスペクト比で領域を確保します。
壊れにくいマークアップを使う
通常の画像なら、ブラウザーのネイティブなloading="lazy"で十分なことが多くあります。内容を伝える画像には意味のあるaltを付けます。空のaltは装飾のときだけにします。スクロールを検知するスクリプトがなくても使える、実在する画像ソースを残します。レスポンシブ画像には、適切なsrcsetとsizesを指定し、ブラウザーが必要以上に大きなリソースを標準でダウンロードしないようにします。
重要なリンク、見出し、商品情報を、クライアントサイドの遅延コンポーネントの中だけに置かないでください。スクリプトの実行に成功しなかったクローラーやユーザーでも、ページの中心となるコンテンツは見つけられる必要があります。特殊なウィジェットでは、Intersection Observerが役立つこともありますが、ネイティブのマークアップなら避けられる失敗要因が増えます。
ビューポートの境目をテストする
回線を絞ったモバイルのテストと、通常のブラウザーでの読み込みの両方を行います。メイン画像がすぐに読み込まれるか、スクロールしないと見えない位置のメディアが後回しになっているか、スクロールで各リソースが、空のプレースホルダーやレイアウトのずれなしに表示されるかを確認します。DOMとネットワークのウォーターフォールも調べます。lazyを指定したのにすぐ取得された画像は、ビューポートに近い位置にあるのでしょう。取得が遅すぎる画像は、後回しにしすぎている可能性があります。
導入部の後に図がある記事なら、その図がLCPの要素ではなく、寸法が確保されていれば、遅延読み込みは妥当です。商品ページでは、最初の判断の中心になるため、メインの商品画像は通常、遅延読み込みに向きません。
限界と検証
最初のリクエスト数が減っても、それだけでページが速くなった、良くなったとは言えません。ドキュメントのレスポンス、LCP、レイアウトの安定性、操作への反応は、それぞれ別に計測します。テンプレートを変更した後は、レンダリング後のHTMLとクローラーのサンプルを再チェックし、後回しにしたメディアに、意図した代替テキスト、正規ページとの関係、内部リンクが残っているかを確認します。