「オフスクリーン画像の遅延読み込み」を修正する：Core Web Vitalsのためのlazy loadingガイド

「Defer offscreen images」とは？

defer offscreen imagesの警告は、lazy load可能な画像を含むページを検出するLighthouseの監査項目でした。Lighthouseは以下のすべての条件を満たす画像をフラグ付けしていました。

• 画像の下端がviewportの高さの3倍よりも下にある。
  画像がlazy loadされておらず、表示領域の3倍より下で終わり、かつ表示領域より下から始まっている場合です。
• 画像のサイズが0.02 MBより大きい、または読み込みに50ms以上かかる。
  サイズが小さい画像やインライン画像は無視されます。lazy loadingスクリプトは、このしきい値を下回る小さなプレースホルダー画像をよく使用します。
• 画像にloading属性が定義されていない。
  Lighthouseはloading="lazy"またはloading="eager"属性を持つ画像を無視します。

この監査はLighthouse 13で削除されました

Lighthouse 13（2025年10月）をもって、この監査は完全に削除されました。Chromeチームは、最新のブラウザはすでにオフスクリーン画像の優先度を下げているため、この監査は有用なフィードバックよりもノイズを生むと判断しました。

しかし、最適化自体は依然として重要です。オフスクリーン画像をlazy loadすることで、帯域幅を削減し、重要なリソースのためにネットワーク接続を解放し、Largest Contentful Paint（LCP）を改善できます。Lighthouseがフラグを立てなくなったため、自分で確認する必要があります。Real User Monitoringを使用するか、loading="lazy"なしで読み込まれる画像がないかページを手動で監査してください。

復習：lazy loadingとは？

lazy loadingとは、ページの表示領域外にある画像を後から読み込むことです。通常はスクロールして表示される直前に読み込まれます。ユーザーが画像に近づいたときにのみ、ブラウザは画像を取得します。これにより帯域幅を節約し、ブラウザは初期レンダリングに不可欠なリソースに集中できます。

オフスクリーン画像がeager loadされる原因は？

デフォルトでは、画像の読み込みは遅延されません。loading属性が欠落しているか、画像がlazy loadingライブラリで処理されていない場合、オフスクリーン画像は遅延されずにページに配置されます。一般的な原因は以下の通りです。

• CMSのコーディングが不適切なプラグイン。
• ネイティブのlazy loadingを無効にするプラグイン。
• 背景画像（これらにはloading="lazy"とは異なるアプローチが必要です）。
• 不適切なHTMLを生成するページビルダー（例：ElementorやWP Bakery）。
• WYSIWYGエディタ（TinyMCEなど）にコピー＆ペーストされたテキスト。
• 不適切なテンプレートのコーディング。

オフスクリーン画像はCore Web Vitalsにどう影響するか？

オフスクリーン画像がLighthouseの指標に直接影響することはありません。しかし、Webページのレンダリングを不必要に複雑にします。ページを画面に表示する前に、ブラウザはより多くのリソースをダウンロードする必要があります。eager loadされたオフスクリーン画像には、以下の3つの問題があります。

• レンダリング前のダウンロードが増加。ユーザーがまだ見ることができない画像を、ブラウザがダウンロードすることになります。
• クリティカルなリソースの優先度が低下。CSSやLCP画像など、レンダリングに実際に必要なリソースと画像が帯域幅を奪い合います。
• メモリ使用量の増加。ユーザーがまだスクロールしていない画像をデコードすると、特に低スペックのモバイルデバイスでメモリを無駄に消費します。

2025 Web AlmanacのPage Weightの章によると、モバイルページの中央値では15枚の画像が読み込まれます。90パーセンタイルではこの数は52枚に跳ね上がります。画像が多いページでは、オフスクリーン画像のlazy loadingが大きな効果を発揮します。CoreDashで監視しているサイトでは、オフスクリーン画像を適切にlazy loadしているページの76%がLCPの基準を満たしているのに対し、そうでないページは59%にとどまっています。

「Defer offscreen images」の修正方法

eager loadされたオフスクリーン画像を修正するには、ファーストビュー以下のすべての画像にloading="lazy"を追加します。ネイティブのlazy loadingは現在、Chrome、Firefox、Safari、Edgeを含め、世界中の95%のブラウザでサポートされています。このためにライブラリは必要ありません。

<img 
     src="image.webp"
     alt="a native lazy loaded image"
     width="300" height="300">

eager loadされている画像の発生源を特定してください。loading属性なしで読み込まれている画像を確認し、何がそれらをページに配置しているのかを突き止めます。よくある原因は以下の5つです。

1. CMSのコーディングが不適切なプラグイン。
   一部のプラグインはHTMLを直接ページに追加し、lazy loadingを有効にする正しいフックを使用しません。
2. ネイティブのlazy loadingを無効にするプラグイン。
   デフォルトでネイティブのlazy loadingを無効にするプラグインもあります。プラグインの設定を確認してください。
3. 不適切なHTMLを生成するページビルダー。
   ElementorやWP Bakeryなどのページビルダーは、無駄が多く完璧とは程遠いコードを生成しがちです。簡単な解決策はありません。コードをクリーンアップし、ワークフローを変更する必要があります。
4. WYSIWYGエディタにコピー＆ペーストされたテキスト。
   TinyMCEのようなほとんどのWYSIWYGエディタは、ペーストされたコードのクリーンアップが苦手です。特にMicrosoft Wordのような他のリッチテキストソースからペーストされた場合は顕著です。これらのエディタは画像にlazy loadingを追加しない可能性があります。
5. 不適切なテンプレートのコーディング。
   lazy loadingが有効になっていても、テンプレートにハードコードされた画像はlazy loadされない場合があります。テンプレート内のオフスクリーン画像を確認し、lazy loadするようにしてください。

LCP画像をlazy loadしない

これはlazy loadingの最も重要なルールです。Largest Contentful Paint画像にloading="lazy"を適用してはいけません。LCP画像は、ほぼ常にヒーロー画像やviewport内で最大の可視要素です。2025 Web Almanacによると、モバイルページの16%が依然としてLCP画像をlazy loadしています。その1つの属性だけで、LCPが200〜500ミリ秒遅延する可能性があります。

代わりに、LCP画像には真逆のアプローチを取ります。fetchpriority="high"を使用して、できるだけ早く読み込まれるようにしてください。

<img 
     loading="eager"
     src="hero.webp"
     alt="Hero image"
     width="1200" height="600">

誤ってLCP画像をlazy loadしてしまった場合は、lazy loadされたLCP画像の修正方法を読んでください。画像の最適化に関する完全なガイドについては、Core Web Vitalsのための画像最適化を参照してください。

画像読み込みのチートシート

すべての画像を同じように扱うべきではありません。最も一般的な4つのシナリオの対処法を以下に示します。

ネイティブlazy loading vs lazy loadingスクリプト

ネイティブのloading="lazy"を使用してください。2026年現在、標準の<img>要素に対してJavaScriptのlazy loadingライブラリを追加する理由はありません。ネイティブのlazy loadingは、Safari（バージョン15.4以降）を含むすべての主要ブラウザでサポートされ、世界中のユーザーの95%をカバーしています。JavaScriptを一切必要とせず、オーバーヘッドもなく、そのまま機能します。

ブラウザがネイティブのlazy loadingをサポートする前は、lazysizesのようなライブラリが不可欠でした。現在これらはメンテナンスされておらず、ほとんどのサイトで不要になっています。JavaScriptのソリューションが依然として必要なシナリオは以下の通りです。

• CSS背景画像。ネイティブのlazy loadingは<img>と<iframe>要素でのみ機能します。背景画像にはIntersectionObserverかcontent-visibility: autoが必要です。
• カスタムの読み込みしきい値。Chromeは、高速回線ではviewportの約1250px下、低速回線では2500px下にある「lazy」画像の読み込みを開始します。この距離をカスタマイズすることはできません。より厳密な制御が必要な場合は、カスタムのrootMarginを設定したIntersectionObserverを使用します。

どうしてもライブラリが必要な場合は、lazysizesではなくvanilla-lazyloadを使用してください。積極的にメンテナンスされており、IntersectionObserverを使用し、背景画像をサポートしています。

lazy loadされる画像のレイアウトシフトを防ぐ

lazy loadされる画像には必ずwidthとheight属性を含めてください。明示的な寸法がないと、ブラウザはどれだけのスペースを確保すべきかわかりません。画像が最終的に読み込まれたときに周囲のコンテンツを押し下げ、Cumulative Layout Shift（CLS）を引き起こします。2025 Web Almanacによると、モバイルページの62%には寸法のない画像が少なくとも1つ存在します。

<!-- Bad: causes layout shift -->
<img loading="lazy" src="photo.webp" alt="Photo">

<!-- Good: dimensions reserve space -->
<img loading="lazy" src="photo.webp" alt="Photo" >

lazy loadできない場合の回避策

オフスクリーン画像を遅延させることが不可能な場合もあります。テンプレートにアクセスできない、あるいはCMSがlazy loadingをサポートしていないかもしれません。影響を軽減するための回避策がいくつかあります。これらは決して完璧ではなく、新たな課題を生む可能性もあります。

• 画像を圧縮する。サイズの小さい画像は、大きな画像に比べて読み込みパフォーマンスへの影響が少なくなります。ファイルサイズを減らすには、最新の圧縮手法を使用してください。
• より高速な画像フォーマットを使用する。PNGやJPEGからWebPやAVIFに切り替えます。2024 Web AlmanacのMediaの章によると、WebPはJPEGのピクセルあたり2.0ビットに対し、約1.3ビットに圧縮されます。
• 大きなページを複数に分割する。大きなページを分割することで、一度に読み込む必要がある画像の数を減らします。
• 無限スクロールを実装する。無限スクロールは基本的にlazy loadingであり、画像だけでなくWebページの特定の領域全体に対して行います。繰り返し要素が多いページ（Pinterestなど）では、無限スクロールによって初期読み込みを大幅に高速化できます。

モバイル特有の考慮事項に触れると、オフスクリーン画像はさらに深刻な問題です。モバイル回線は遅く、viewportも小さいため、より多くの画像がオフスクリーンになるからです。

どのアプローチを取るにしても、実際のユーザーで機能するか検証してください。Real User Monitoringを設定し、変更が実際に本番環境のLCPや全体的なCore Web Vitalsを改善しているかをトラッキングします。