遅延読み込み

TL;DR — 遅延読み込みは、画像や埋め込みコンテンツをスクロールして表示するまでダウンロードを保留するようブラウザに指示し、ページの初期読み込みを高速化します。簡単でコード不要の方法は、<img> や <iframe> に loading="lazy" を追加することです。覚えておくべきルールは1つだけ：ページ上部の大きな画像は遅延読み込みしないことです。そうすると、ページが遅く感じられるからです。

遅延読み込みとは

通常、ブラウザがページを開くと、ページ上のすべてのもの（すべての画像、埋め込まれた地図や動画）をすぐにダウンロードしようとします。画像が多い長いページでは、スクロールして見ることもないかもしれないもののために、大量のダウンロードが発生します。

遅延読み込み はこれを解決します。画面外の画像や埋め込みコンテンツの読み込みを、スクロールして表示されるまで延期します。ページは上部のコンテンツをすぐに表示し、残りはスクロールに応じて読み込まれます。最初に転送するデータが少ないほど初期表示が速くなり、帯域幅とバッテリーも節約できます。これはスマートフォンで特に重要です。

簡単な方法：loading 属性

以前はこれを行うためにJavaScriptライブラリが必要でした。もう必要ありません。最新のブラウザには組み込まれています。属性を1つ追加するだけです：

<img src="photo.jpg" loading="lazy" alt="…">

これだけです。これは主要なすべてのブラウザの <img> と <iframe>（埋め込みYouTube動画、Googleマップ、ソーシャルウィジェットなど）で機能し、JavaScriptは不要です。

避けるべき1つの間違い

ページ上部の大きな画像（ヒーロー画像、最初に目にするもの）は遅延読み込みしないでください。遅延読み込みはブラウザに「これは待ってもよい」と伝えるため、遅延読み込みされた上部の画像は本来より遅く読み込まれ、ページが遅く感じられます。Google自身のガイダンスでも、ページを開いたときにすぐ表示されるものには遅延読み込みをスキップするよう推奨しています。

簡単に言うと、スクロールしないと見えない部分は遅延読み込みし、最初に見える部分は通常どおり読み込みます。

SEOに悪影響はありますか？

それ自体は、ありません。Googleは、通常の方法で行われた遅延読み込み画像やコンテンツを問題なくインデックスできます。問題が始まるのは、ページがスクロールやクリックの背後にコンテンツを隠している場合だけです。検索エンジンはスクロールもクリックもしないからです。画像が単に loading="lazy" を使用しているだけなら、問題ありません。Googleがこれを実際にどのように見ているか、そしてそれを確認する方法の詳細を知りたいですか？ 詳細 タブに切り替えてください。

TL;DR — 遅延読み込みは、画面外の画像とiframeがビューポートに近づくまで読み込みを延期し、初期転送量（LCPの改善に有効）と読み込み開始時のメインスレッド処理（INPの改善に有効）を減らします。<img>/<iframe> のネイティブな loading="lazy" 属性は、ほとんどのJSライブラリに取って代わりました。意味のある値は lazy と eager のみです（auto は非推奨）。避けるべきなのは、LCP候補やファーストビューの画像を遅延読み込みしてLCP自体を遅らせることと、コンテンツをスクロールやクリックの操作後にしか読み込めないようにすることです。Googlebotはページを操作しないため、こうしたイベントを発生させません。遅延読み込みは直接のランキング要因ではなく、Core Web Vitalsとクロール可能性を介して影響します。Search ConsoleのURL検査ツールで、画像URLがレンダリング後のHTMLの src 属性に入っていることを確認してください。

遅延読み込みが実際に行うこと

考え方はシンプルです。すべてを一度に読み込むのではなく、必要なときにだけリソースを読み込むことです。メディアが多いページでは、すべての画像と埋め込みを事前にダウンロードすると、訪問者がスクロールして見ることもないかもしれないものを取得するためにブラウザが忙しくなり、帯域幅、メモリ、バッテリーを無駄に消費します。画面外のものを延期することで、ファーストビューのコンテンツをより早く描画できます。Martin Splitt氏は、Googleの Search Off the Record エピソード「Lazy loading demystified」 でまさにこの点を指摘しています。目標は、何も生み出さない作業を避けることです。ページがなくても問題ない重要でない画像は、ブラウザを占有し続けるだけだからです。

これは、多くの人が追い求めているCore Web Vitalsにつながります。ネットワークをめぐって最初に競合するバイト数が少なければ、Largest Contentful Paint要素をより早くレンダリングできます。iframe（広告、ソーシャルウィジェット、コメントセクション、マップ）の場合、それらを遅延させることで、起動時のメインスレッドの作業も削減され、これはLCPだけでなくInteraction to Next Paintの改善にもなります。Google自身のweb.devガイダンスでは、遅延読み込みのiframeをページ読み込み中のINP改善として位置づけています。

ネイティブ vs. JavaScript駆動の遅延読み込み

数年前にブラウザが画像とiframe向けのネイティブなloading属性へ対応し、JavaScript APIを組み込まなくても処理をブラウザに任せられるようになりました。Ahrefsの私のJavaScript SEOガイド でも同じ変化を取り上げています。私がその記事を最初に書いて以降、遅延読み込みの中心はJavaScriptによる制御からブラウザのネイティブ処理へ移りました。JSで制御する実装もまだあり、画像だけなら通常は問題ありません。私が確認するのは、画像だけでなく実際のコンテンツまで遅延読み込みしていないかです。そうした実装では、コンテンツが適切に認識されないことがあるためです。

ネイティブ版：

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

遅延画像には常に明示的なwidth/height（またはアスペクト比）を設定して、画像が読み込まれる前にブラウザがスペースを確保するようにしてください。これが遅延画像における最大のレイアウトシフトのリスクです。ただし、予約済みの寸法はCLSの絶対的な保証ではありません。周囲のレイアウトやレスポンシブなクロップが画像の読み込み後にまだ変更される場合、シフトが発生する可能性があります。固定された寸法だけで解決すると想定せず、実際のレイアウトシフトのトレースで確認してください。

遅延読み込みとiframeにはもう1つの区別が必要です。<iframe>のloading="lazy"は、埋め込みのフェッチと作成が行われるタイミングを遅らせるだけです。title、フォーカス動作、sandbox、allow/権限ポリシー、referrerpolicy、同意処理、または寸法を設定するわけではありません。これらはそれぞれ独自の注意が必要であり、埋め込みは読み込み可能になると（スクリプト、トラッキングピクセル、レイアウトなどの）作業を続けることができます。また、「フォールドの下」がどこでも同じように動作するとは想定しないでください。display: noneコンテンツ、画面外のカルーセルスライド、変換された要素、ネストされたスクロールコンテナは、プレーンなフォールド下の要素とは異なる方法でビューポートと交差する可能性があるため、同等性を想定せずに実際のレイアウトとナビゲーションコントロールをテストしてください。

loading属性の値

今日重要となる値は2つだけです：

• loading="lazy" — リソースがビューポートに近づくまで遅延させます。
• loading="eager" — すぐに読み込みます。これがデフォルトの動作です。フォールド上の画像について明示するために使用します。

古い記事ではloading="auto"を見かけるかもしれませんが、Chromeでは非推奨なので、使用しないでください。その必要はありません。属性を省略すれば、すでにデフォルト（eager）の動作が得られます。

「近い」とはどのくらい近いのでしょうか？loading="lazy"はヒントであり、実装者が距離を制御できる保証ではありません。仕様では、実際のビューポート近接の判定をブラウザに委ねています。Chromiumは、ユーザーがスクロールして到達するまでに表示準備が整うよう、遅延リソースを十分早く取得しようとします。トリガー距離はブラウザ、接続速度、リソースの種類によって異なり、ブラウザやバージョンをまたいで依存したり再現したりできる固定ピクセル値ではありません。「ビューポートのNピクセル手前で読み込む」といった特定の数値を公開したり信頼したりしないでください。ビューポート近傍の範囲は実装依存として扱い、定数を仮定せず、対象のブラウザと接続条件でNetworkトレースを取り、実際の動作を確認してください。

ネイティブの遅延読み込みは、レスポンシブ画像とも問題なく動作します。通常の src や srcset/sizes の選択にも適用されるため、loading="lazy" を追加しても レスポンシブ画像の動作が失われることはありません。代わりに、実際のURLを data-* 属性にのみ隠して 後でスクリプトに差し替えさせる場合、読み込みはそのスクリプトに依存するようになります。レンダリングされた HTMLと、スクリプトが失敗した場合の挙動をテストしてください（詳細は「スクリプト」および 「トラブルシューティング」タブを参照）。

最大の間違い：LCP / ファーストビュー画像の遅延読み込み

これは私が最もよく目にする失敗で、参照した情報源の見解も一致しています。ヒーロー画像やLCP要素になり得る画像を遅延読み込みすると、体感速度を左右する最も重要なピクセルをブラウザに待たせることになります。また、ブラウザは画像がページ上のどこに配置されるかを把握するまで遅延読み込みできないため、ファーストビューの遅延画像は、即時読み込みする画像よりも遅く表示される傾向があります。これはLargest Contentful Paintを直接遅らせます。GoogleはLCPを読み込み開始から2秒半以内に表示する ことを目標としています。

Splitt氏はSOTRエピソードでその逆を明確に述べています。遅延読み込みを使うべき場面で使っていない場合、それはおそらくCore Web Vitalsの何らかの側面（おそらくLCP）を損なうでしょう。つまり、これは両刃の剣です。ルールは次の通りです：

• 可能性が高い、または観測されたLCP候補 → 即時読み込み（loading="lazy" を省略するか、eager を設定）。LCP画像には fetchpriority="high" を検討してください。
• ファーストビュー外 → loading="lazy"。

ファーストビュー上のすべての画像がLCP候補であるとは限りません。実際のLCP要素を特定し（PerformanceトレースやPageSpeed Insightsで特定できます）、すべてのファーストビュー画像を同じように扱うのではなく、そのリクエストのタイミングを確認してください。また、これらは別々のヒントであり、1つの設定ではありません。loading="eager"（または loading を省略）は、ブラウザがリソースの発見を遅延させないという意味だけで、それ自体がフェッチの優先度を上げるわけではありません。fetchpriority はその上に重ねる、別個のアドバイザリーヒントです。同じリソースに <link rel="preload"> と loading="lazy" を併用すると、ブラウザに矛盾した意図を送ることになるため、組み合わせが期待通りに動作すると想定するのではなく、実際のネットワークウォーターフォールを確認してください。

包括的なアンチパターンは、サイト全体のすべての画像に対して遅延読み込みを有効にすることです。これは一般的なCMSのデフォルト設定です。Splitt氏が指摘したように、すべての画像が遅延読み込みされると、すぐに表示される（または表示されるべき）画像も遅延読み込みされることになり、これはまさに避けたいケースです。

Googlebotが遅延読み込みコンテンツをレンダリングする仕組み

ここで見落とされやすいクロール上の事実があります。Googlebotはスクロールもクリックもしません。 ヘッドレスブラウザでページをレンダリングしますが、ユーザー操作までは再現しません。Googleもこれを明記しています。Google検索はページを操作しない ため、Googleが推奨する遅延読み込み方法は、スクロールやクリックなどのユーザー操作に依存しません。

だからこそ、実装の方法が重要です。Googleのドキュメントには、安全と見なされる3つの実装が記載されています：画像とiframe用のブラウザ組み込みの遅延読み込み、IntersectionObserver API（ポリフィル付き）、またはビューポートに入る際にデータを読み込むJavaScriptライブラリです。これら3つはすべてビューポートとの交差に基づいており、Googlebotが決して発生させないスクロールやクリックイベントには依存していません。

高リスクのパターンは、カスタムまたはサードパーティ製のJS遅延読み込みライブラリです。ライブラリが誤動作し、画像URLがsrc属性に入らなければ、Googleはその画像を取得できません。Splitt氏はSOTRのエピソードで、まさにこの失敗例を説明しました。URLがなければ、インデックスに登録する対象もありません。これは私のJavaScript SEOガイド で指摘していることと同じです。画像の遅延読み込みは通常問題ありませんが、コンテンツそのものを遅延読み込みするとインデックス登録の問題が起きやすくなります。Googleが実際にレンダリングした内容を確認することが対処法です。

無限スクロールは別の問題です

基本的な画像/iframeの遅延読み込みを無限スクロールやページネーション読み込みと混同しないでください。画像の遅延読み込みは一つのことですが、ユーザーがスクロールするにつれて新しいコンテンツのチャンクを読み込むことは別のことであり、独自のアーキテクチャが必要です。Googleのガイダンス：各チャンクに永続的で一意なURLを割り当て、URLごとにコンテンツを安定させ（?date=yesterdayのような相対値ではなく、?page=12のような絶対ページ番号を使用）、各チャンクが主要な表示コンテンツになるにつれてHistory APIで表示URLを更新して、リフレッシュ、共有、リンクができるようにします。これを省略すると、無限スクロールの背後にあるより深いコンテンツが確実にクロールまたはインデックスされない可能性があります。

テスト方法

検証方法はGoogleのドキュメントと私自身の方法論で同じです：Search ConsoleのURL検査ツールを使用し、レンダリングされたHTMLを確認します。画像（または動画）のURLがそのレンダリングされたHTMLの<img>/<video>要素のsrc属性に表示されていれば、設定は機能しています。Googleはこれを明言しています — check the rendered HTML to make sure your content is in it (翻訳)「レンダリングされたHTMLを確認し、コンテンツが含まれていることを確かめてください」。URLがsrcにない場合、それが問題であり、通常はスクロール/クリックトリガーまたは壊れたライブラリに起因します。

遅延読み込みされる商品グリッドでは、この存在チェックだけで終わらせないでください。無限スクロールSEOテストマトリックスに沿って、標準と縦長のビューポート、新規ナビゲーションと読み込み後のリサイズ、操作なしと段階的スクロール、一意な商品リンク数、アクセシビリティツリーをそれぞれ検査します。初期化済みページのリサイズは、最終的なビューポートサイズで新規ナビゲーションする場合と同等ではありません。オブザーバーやバッチ計算が起動時にしか登録されないことがあるためです。 この主張の根拠 Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. 対象範囲： Google Search guidance for JavaScript-driven lazy loading. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Lazy-load content

ウェブパフォーマンスツールも活用できます。PageSpeed Insightsは、遅延読み込みすべき画面外画像を検出します。Ahrefsの私のPageSpeed Insightsガイド では、「オフスクリーン要素を遅延読み込みする」監査が画像の遅延読み込みを促していると説明しています。普段使っている診断結果を修正へ結び付けるのに便利です。

ランキングシグナルに関する正直さ

遅延読み込みが何であり、何でないかを明確にしてください。それを使用することは直接のランキング要因ではなく、使用しないことはペナルティでもありません。ランキングとの関連は間接的です：Core Web Vitals（主にLCP、iframeの場合はINP）とクロール可能性を通じて流れます。悪い実装がコンテンツを隠す場合です。Splitt氏は、Core Web Vitalsを通じたランキング効果をほとんどの場合、微小な要因と特徴付けました。したがって、ユーザーの読み込み体験とクリーンなインデックスのために遅延読み込みを最適化してください — 属性自体からのランキング向上を期待するからではありません。

位置づけ

遅延読み込みは、より広いウェブパフォーマンスツールキットの1つのレバーです。リソースヒント（早期に必要なリソースのプリロード/プリコネクト）、フォント読み込み戦略、キャッシュ、CDNと組み合わせて使用され、最終的にはCore Web Vitalsを通じて評価されます。above-the-fold/below-the-foldの分割を正しく行えば、利用可能な最も安価な勝利の1つです。

AIまとめ

Advancedバージョンの簡潔な見解:

• 遅延読み込み（Lazy loading） は、画面外の画像やiframeをビューポートに近づくまで読み込みを延期し、初期ページの重さと起動時の処理を削減します。ネイティブでJS不要の方法は、<img> と <iframe> に loading="lazy" を指定することです。これはJSライブラリをほぼ置き換えています。これはブラウザのヒントであり、保証された距離やタイミングではありません。トリガーポイントはブラウザ、接続、リソースの種類によって異なるため、固定のピクセル数に依存しないでください。
• 値: lazy と eager のみが重要です。auto はChromeで非推奨です。
• Core Web Vitalsとの関連: 初期バイト数を減らすとLCPに役立ちます。iframeの延期は起動時のメインスレッドの処理を減らし、INPに役立ちます。遅延画像がCLSを引き起こさないように width/height を設定してください。ただし、予約された寸法だけでは、周囲のレイアウトが変わるとゼロシフトを保証できません。
• 最大の間違い: ファーストビューの画像すべてではなく、可能性が高い、または観測されたLCP画像を遅延読み込みすることです。これによりLargest Contentful Paintが遅れます。Googleの目標は2秒半以内です。eager または loading の省略は発見にのみ影響し、それ自体がフェッチ優先度を上げるわけではありません。fetchpriority は別のヒントであり、同じリソースに preload と loading="lazy" を併用すると競合します。サイト全体への無差別な遅延読み込みは、一般的なCMSのアンチパターンです。
• iframeには独自の契約があります: loading="lazy" はフェッチ/生成のタイミングのみを延期します。title、sandbox、permissions policy、referrer policy、同意、寸法は個別に設定する必要があり、非表示/カルーセル/変換されたレイアウトは、単純なファーストビュー外の要素とは異なる方法でビューポートと交差する可能性があります。
• Googlebotはスクロールもクリックもしません。 スクロール/クリックイベントの背後にあるコンテンツは見られない可能性があります。Googleの安全な方法（ネイティブの遅延読み込み、IntersectionObserver、または適切に動作するJSライブラリ）はすべて、ビューポートの交差に基づいています。
• 最大のリスク: カスタム/サードパーティのJS遅延読み込みライブラリ。URLが src に含まれない場合、Googleは画像をインデックスしません（Martin Splitt氏による）。
• 無限スクロール は別物です。一意のページネーション付きURLとHistory APIが必要です。
• 確認 はSearch ConsoleのURL検査 → レンダリングされたHTML → src 属性に画像URLが存在することを確認します。
• 直接のランキング要因ではありません。 効果はCore Web Vitalsとクロール可能性を介した間接的なものであり、Splitt氏はCore Web Vitalsのランキング効果をわずかと呼びました。

公式ドキュメント

検索エンジンとGoogleのweb.devからの一次情報ガイダンス。

Google — Search Central

• 遅延読み込みされたウェブサイトコンテンツを修正する — 決定版ドキュメント：安全な実装方法、「Googleはページとやり取りしない」ルール、無限スクロール/ページネーション読み込みの要件、レンダリングされたHTMLでの確認方法。
• JavaScript SEOの基本を理解する — 帯域幅/パフォーマンスのベストプラクティスとして画像の遅延読み込みを推奨し、専用ガイドへのリンクを提供。
• Core Web Vitals — LCP要素の遅延読み込みがなぜ逆効果か（LCP目標は2秒半）。

Google — web.dev（パフォーマンスを学ぶ）

• 画像と<iframe>要素の遅延読み込み — いつ延期するか、遅延iframeのINP利点。
• ウェブ向けブラウザレベルの画像遅延読み込み — ネイティブ属性、ビューポート内/LCP画像を遅延読み込みしない理由。
• オフスクリーンiframeの遅延読み込みの時が来ました！ — iframe固有のケース（広告、ウィジェット、マップ）。
• CMS向けブラウザレベルの遅延読み込み — CMSプラットフォーム向けガイダンス。

Google — ポッドキャスト

• Search Off the Record — Ep. 98, “Lazy loading demystified” (2025年8月21日) — John Mueller氏とMartin Splitt氏が、遅延読み込み、レンダリング、インデックス、Core Web Vitalsについて語ります。GoogleのSearch Off the Recordページ からも参照できます。

開発者向けリファレンス（SEO専用ではありませんが、APIに関しては信頼できる情報源です）

• MDN — Lazy loading（パフォーマンスガイド）
• MDN — HTMLImageElement: loadingプロパティ
• caniuse — 画像とiframeの属性による遅延読み込み

Bing / Microsoft

• Bingは、遅延読み込みに特化したドキュメントを公開していません。一般的なWebマスターガイドライン で、クロールとJSレンダリングを広くカバーしています。BingbotはChromiumベースのヘッドレスブラウザでレンダリングし、Googlebotと同様にスクロールやクリックは行いません。そのため、Googleを満たすのと同じネイティブのloading="lazy" / IntersectionObserverアプローチでBingも満たせるはずです。この最後の点は、Bingbotの一般的なレンダリング動作からの推測であり、遅延読み込みに関するBingの公式見解に基づくものではありません。そのように扱ってください。

ソースからの引用

Googleの公式ドキュメントからの公式見解です。各リンクは、ソースページの引用箇所にジャンプするディープリンクです。

Google — Search Central「遅延読み込みされたウェブサイトのコンテンツを修正する」

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (翻訳) 「重要でない、または表示されていないコンテンツの読み込みを遅らせること（一般に「遅延読み込み」として知られる）は、一般的なパフォーマンスとUXのベストプラクティスです。」 引用にジャンプ
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (翻訳) 「ただし、正しく実装されていない場合、この手法は誤ってGoogleからコンテンツを隠してしまう可能性があります。このドキュメントでは、Googleが遅延読み込みされたコンテンツを確実にクロールしてインデックスできるようにする方法について説明します。」 引用にジャンプ
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (翻訳) 「前述の方法は、コンテンツを読み込むためにスクロールやクリックなどのユーザー操作に依存しません。これは、Google検索がページとやり取りしないため重要です。」 引用にジャンプ
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (翻訳) 「ユーザーがページを開いたときにすぐに表示される可能性が高いコンテンツには、遅延読み込みを追加しないでください。コンテンツの読み込みとブラウザでの表示に時間がかかり、ユーザーに非常に目立つ可能性があります。」 引用にジャンプ
• “Give each chunk its own persistent, unique URL.” — 無限スクロール/ページネーション読み込みについて。 (翻訳) 「各チャンクに、独自の永続的な一意のURLを付与してください。」 引用にジャンプ

遅延読み込みチェックリスト

遅延読み込みの変更を公開する前に、これを実行してください：

• ヒーロー画像 / LCP画像は遅延読み込みしない — 即時に読み込み（loading="lazy" を省略）、理想的には fetchpriority="high" を指定します。
• loading="lazy" は、画面外（below the fold） にある画像とiframeに適用します。
• 遅延読み込み画像には明示的な width/height（または aspect-ratio）を指定し、読み込み時のレイアウトシフト（CLS）を防ぎます。
• スクロールやクリック イベントでコンテンツを制限しない — Googlebotはそれらを発火しません。代わりにネイティブの遅延読み込みまたはIntersectionObserverを使用します。
• 非推奨の loading="auto" 値を使用しない — lazy/eager のみを使用します。
• 画面外の iframe（埋め込み、広告、マップ、ウィジェット）には loading="lazy" を使用して、起動時のメインスレッドの作業を削減します。
• 遅延読み込みされたiframeには、独自の title、sandbox、allow/権限ポリシー、referrerpolicy、明示的な寸法を引き続き指定します — loading="lazy" はフェッチのタイミングを遅らせるだけで、これらの属性は遅らせません。
• Search ConsoleのURL検査 → レンダリングされたHTML で、画像/動画のURLが src 属性に表示されることを確認しました。
• サードパーティのJS遅延読み込みライブラリ を使用する場合、レンダリングされたHTMLで src が最終的に設定されることを確認しました。
• 無限スクロール の場合、各チャンクに一意で永続的なページネーション付きURLがあり、History APIが表示中のURLを更新します。
• PageSpeed Insightsの「オフスクリーン画像の遅延」フラグに対処しました。

遅延読み込みのアンチパターン（誤解と間違い）

それぞれについて、よくある信念や習慣、なぜそれが間違っているのか、そして代わりに何をすべきかを説明します。

「遅延読み込みは常に良いので、すべての画像に適用すべきだ。」 なぜ間違いか：サイト全体に無差別に遅延読み込みを適用すると、ヒーロー画像やLCP画像も対象になり、Largest Contentful Paintが遅延します — これは意図した速度向上とは逆です。 代わりに：画面外だけを遅延読み込みし、画面内の画像は即時に読み込みます。

「Googleは遅延読み込みされたコンテンツをまったくインデックスしない。」 なぜ間違いか：ネイティブの遅延読み込み、IntersectionObserver、または適切に動作するライブラリを使用すれば、Googleは遅延読み込みされたコンテンツを問題なくクロールおよびインデックスします。リスクはスクロール/クリックで制限された設定や壊れた設定に固有のものです — Google自身の表現によれば、問題は「正しく実装されていない」場合です。 代わりに：ビューポート交差メソッドを使用し、レンダリングされたHTMLで確認します。

「loading='auto' は良いデフォルトだ。」 なぜ間違いか：auto はChromeで非推奨です。それを推奨するのは古いアドバイスです。 代わりに：画面外のリソースには lazy を、それ以外には eager（または何も指定しない）を使用します。

「遅延読み込みと無限スクロールは同じ修正だ。」 なぜ間違いか：これらは別物です。無限スクロールにはさらに、一意のページネーション付きURLとHistory APIの更新が必要です。そうしないと、より深いコンテンツが確実にクロールされない可能性があります。 代わりに：ページネーション/無限読み込みを、チャンクごとのURLを持つ独自のアーキテクチャとして扱います。

「loading='lazy' はどの要素でも機能する。」 なぜ間違いか：これは <img> と <iframe> に対して仕様化されています。他の要素のサポートは、コア仕様の一部ではありません。 代わりに：画像とiframeにはこの属性を使用し、他のメディアは適切な手法で処理します（動画の場合は、ビューポートに入ったときに動画を読み込むポスター画像を使用）。

「遅延読み込みはSEOに悪影響を与える。」 なぜ間違いか：遅延読み込み自体はペナルティではありません。ランキングに関連する影響はCore Web Vitalsを通じて発生し、小さいものです。悪いのは 実装 であり、手法そのものではありません。 代わりに：正しく実装し、LCP画像を除外し、レンダリングされる内容を確認します。

遅延読み込みのチートシート

loading 属性

対応要素

• <img> — 対応
• <iframe> — 対応
• その他の要素（動画/音声）— コア仕様の一部ではない。動画にはポスター画像 + ビューポート進入時の読み込みパターンを使用します。

ファーストビュー vs. ファーストビュー外

• ファーストビュー / LCP候補 → eager（決してlazyにしない）。LCP画像に fetchpriority="high" を追加する。
• ファーストビュー外 → lazy。

Core Web Vitalsへの影響

• 画面外の画像を遅延させる → LCPに有効（初期に競合するバイト数が減る）。
• 画面外のiframeを遅延させる → INPに有効（起動時のメインスレッドの作業が減る）。
• lazy画像に width/height がない → CLSに悪影響（読み込み時のレイアウトシフト）。

Googlebotが重視するルール

• Googlebotはスクロールやクリックをしない — スクロールやクリックで表示されるコンテンツは不可。
• 安全な方法: ネイティブの loading="lazy"、IntersectionObserver、適切に動作するJSライブラリ。
• 確認方法: URL Inspection → レンダリングされたHTML → src 属性内の画像URL。
• 無限スクロール ≠ 画像の遅延読み込み — 一意なページネーションURLとHistory APIが必要。

修正前 / 修正後

監査で遭遇する形に沿った具体的な修正例。

1. ヒーロー画像が遅延読み込みされている（LCPが遅延）

修正前:

<img src="hero.jpg" loading="lazy" alt="Product hero">

修正後:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

理由: ヒーロー画像はLCP要素です。eager読み込み（およびフェッチの優先化）により、 より早く描画されます。遅延読み込みはその逆です。

2. CMSのデフォルトによるサイト全体の一括遅延読み込み

修正前: テンプレート上のすべての <img> に loading="lazy" が付いており、ヘッダーの ロゴやページ上部の注目画像も含まれます。 修正後: テンプレートはファーストビューの画像をeagerで読み込み、loading="lazy" は 初期ビューポートより下に表示される画像にのみ適用します。 理由: 一括遅延読み込みは、すぐに表示される画像も対象にしてしまい、ユーザー（およびLCP）が 最初に見るものを遅らせます。

3. ページ読み込み時の画面外の埋め込み読み込み

修正前:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

修正後:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

理由: 地図はファーストビュー外です。遅延させることで起動コストがなくなり、INPに有効です。 埋め込みはページ読み込み中にメインスレッドの作業を行うためです。

4. カスタムJSの遅延読み込みでGooglebotに対して src が空になる

修正前: ライブラリが実際のURLを data-src に保存し、スクロールイベントで src に 入れ替えます — Googlebotはスクロールイベントを発生させないため、レンダリングされたHTMLでは src が空またはプレースホルダーのままです。 修正後: ネイティブの loading="lazy"（最初から src に実際のURLを入れる）、または IntersectionObserverベースのライブラリを使用し、URL Inspectionでレンダリングされた src に URLが存在することを確認します。 理由: レンダリングされたHTMLの src にURLがなければ、Googleは画像を取得できません。

遅延読み込みすべき（またはすべきでない）画像を見つける

任意のページに貼り付けて loading 属性を監査できるDevToolsコンソールスニペットです。 各画像の loading 値と、現在ビューポート内にあるかどうかを一覧表示します — ファーストビュー内なのに lazy とマークされた画像や、ファーストビュー外なのに 遅延読み込みされていない画像を見つけられます。

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

ソースをgrepして危険な遅延読み込みパターンを探す

テンプレートやビルド出力で、非推奨の auto 値と、data-src 方式のJS遅延読み込み （Googlebotに対して src が空になる可能性がある）を確認します。

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

注意: data-src は自動的に問題になるわけではありません — 実際のURLがレンダリングされた src に 入ることを確認するためのきっかけであり、Search ConsoleのURL Inspectionで検証します。

遅延読み込みを有効にした後、ヒーロー画像の開始が遅くなる

症状: LCPが遅くなり、ウォーターフォールでヒーロー画像のリクエスト開始が遅れる。

考えられる原因: グローバルなCMSルールが、ファーストビュー内またはLCP画像に loading="lazy" を追加した。

修正と確認: その画像からlazy属性を削除し、必要に応じて fetchpriority="high" を追加し、同一条件のトレースでリクエストがより早く開始されることを確認します。

遅延画像が表示されるが、ページがずれる

症状: 遅延画像がビューポートに入ると、コンテンツがジャンプします。

考えられる原因: 画像に明示的な寸法または予約済みのアスペクト比がありません。

修正と確認: width 属性と height 属性を追加するか、CSSで同じ アスペクト比を予約します。レイアウトシフト領域を有効にして再読み込みし、画像が周囲のコンテンツを 移動させなくなったことを確認します。

Googleが遅延コンテンツを認識しない

症状: レンダリングされた検査で、人間がスクロールした後に表示される画像URLまたはコンテンツが欠落しています。

考えられる原因: スクロール/クリックハンドラーがGooglebotに対して実行されないか、遅延読み込み ライブラリが実際のURLをレンダリングされた src ではなく data-src に残しています。

修正と確認: ネイティブの遅延読み込みまたはIntersectionObserverベースの 実装を使用し、レンダリングされたHTMLを検査して、最終的なURLとコンテンツが 操作なしで存在することを確認します。

画面外の埋め込みがすぐに読み込まれる

症状: 遅延読み込みの変更にもかかわらず、初期のウォーターフォールにファーストビュー外のiframeが表示されます。

考えられる原因: 属性がデプロイされたiframeに存在しないか、ラッパーが iframeを即座に作成するか、埋め込みがブラウザの読み込みしきい値に十分近い位置にあるためです。

修正と確認: ライブDOMとリクエストイニシエーターを検査し、コールドキャッシュで長い ページでテストし、リクエストがブラウザのビューポート近傍のしきい値まで遅延されることを確認します。

実装と証明のためのツール

• Chrome DevToolsのElementsパネルとNetworkパネル: デプロイされた loading 属性を確認し、iframeを作成したスクリプトを特定し、変更前後のリクエスト開始時間を比較します。
• Chrome DevToolsのPerformanceパネル: 読み込みを記録し、埋め込みの遅延が 起動時のメインスレッドの作業を減らし、LCP画像を遅延させないことを確認します。
• PageSpeed Insights: 画面外画像の診断を候補選定の出発点として使用し、 真のファーストビュー外の候補をヒーローやその他の即時コンテンツから分離します。
• Search ConsoleのURL検査: レンダリングされたHTMLを検査し、遅延された 画像URLが src に含まれ、遅延読み込みされたコンテンツがスクロールや クリックなしで存在することを確認します。
• ブラウザのビューポートとフィルムストリップ: 複数のビューポートサイズでテストします。デスクトップでファーストビュー外の画像が、 より小さいまたは異なる形状のデバイスではファーストビュー内にある場合があります。

ファーストビュー外の画像の遅延

実行するテスト: 初期ビューポートよりかなり下にある画像にネイティブの遅延 読み込みを追加する前と後で、コールドロードのNetworkトレースを記録します。

期待される結果: 画像リクエストは初期のクリティカルウォーターフォールに含まれず、 ビューポートが近づくにつれて開始されます。

失敗の解釈: デプロイされたマークアップに属性がないか、JavaScriptが 画像を即座に作成または取得するか、テスト画像がブラウザのビューポート近傍のしきい値内にあるためです。

監視期間: デプロイ直後に、代表的なモバイル およびデスクトップのビューポートサイズで確認します。

ロールバックのトリガー: 初期読み込み時に表示される画像が遅延される場合、または 画像がユーザーが到達する前に表示されないことが頻繁にある場合は、ロールバックします。

LCP画像の除外

実行するテスト: 包括的な遅延読み込みを削除した後、ページのLCP画像について、一致するパフォーマンストレースとリクエストウォーターフォールを比較します。

期待される結果: LCP画像は即座に読み込まれ、リクエストはより早く開始され、LCP は悪化しません。

失敗の解釈: 別のテンプレートまたは最適化レイヤーが属性を再追加するか、 CSS、JavaScript、またはマークアップによって発見が依然として遅延しています。

監視期間: すぐに繰り返しラボ実行を確認し、次のレポート期間中にフィールドLCPを監視します。

ロールバックのトリガー: 変更によって他の重要なリソースが遅れ、再現可能なLCPの悪化が生じる場合は、その変更を含む展開をロールバックします。

レンダリングされたコンテンツの可視性

実行するテスト: URL Inspection を使用して、ページを操作せずにレンダリングされた HTML を表示し、遅延読み込みされた画像 URL と関連コンテンツを検索します。

期待される結果: 最終的な URL が src に表示され、重要なコンテンツがレンダリングされた HTML に存在します。

失敗の解釈: 実装がスクロール/クリックイベントに依存しているか、遅延読み込みスクリプトがレンダリング中に失敗しました。

監視期間: リリース後、および遅延読み込みライブラリや CMS 画像パイプラインを変更した後は、影響を受けるすべてのテンプレートをテストします。

ロールバックのトリガー: インデックス可能なコンテンツや画像 URL がレンダリングされた出力から消えた場合は、ロールバックします。

自分でテスト: 遅延読み込み

Core Web Vitals やインデックスを損なわずに画像と iframe を遅延させる方法についての 5 つの簡単な質問です。各質問に回答を選び、確認してください。

時間をかける価値のあるリソース

関連する私の記事

• JavaScript SEO の問題とベストプラクティス — JS 駆動からブラウザネイティブの遅延読み込みへの移行と、遅延読み込みされたコンテンツ（画像だけでなく）がインデックスのリスクである理由について説明しています。
• SEO 担当者と開発者のための Google PageSpeed Insights — 「オフスクリーン画像の遅延読み込み」監査を遅延読み込みと関連付け、PSI レポートの残りの部分も説明しています。
• 技術 SEO の初心者向けガイド — パフォーマンスとレンダリングが全体像の中でどのように位置づけられるかを説明しています。

業界からの情報

• 遅延読み込みされたウェブサイトコンテンツを修正する （Google Search Central）— 実装とテストの決定版ドキュメント。
• ウェブ向けブラウザレベルの画像遅延読み込み （web.dev）— ネイティブ属性とLCPの注意点を、Googleのパフォーマンスチームが解説しています。
• オフスクリーンiframeを遅延読み込みする時が来ました! （web.dev）— iframeのケースと、読み込み開始時の処理量およびINPに関する利点。
• 遅延読み込みの謎を解く — Search Off the Record、エピソード98 （Google）— Mueller氏とSplitt氏による、遅延読み込み、レンダリング、インデックス登録、Core Web Vitalsについての全編。
• 遅延読み込みの説明: サイトとUXを高速化 （Search Engine Land）— CMS固有の注意点を含む詳細な業界ガイド。
• 遅延読み込み（パフォーマンスガイド） （MDN）— APIを開発者向けに説明したリファレンス。
• クロール可能性とインデックス登録のための遅延読み込み入門 （Oncrawl）— クロールとインデックス登録の観点を詳しく解説。

変更履歴