2026年版 画像遅延読み込み：LCPを損なわない高速ページ化の技術

最終更新日: June 28, 2026

Lazy loadingは、ブラウザが最初のレンダリング中にビューポート外の画像リクエストをスキップできるため、画像量の多いページを高速に感じさせるのに役立ちます。しかし、不注意に使用すると、ユーザーがすぐに必要とする単一の画像（ヒーロー画像、製品のメイン写真、または記事のカバーとなりLCP要素となるもの）の表示を遅延させる可能性もあります。

本ガイドでは、ネイティブなloading="lazy"を使用すべき場所、画像をエAGERに保つべき場所、そしてCore Web VitalsやSEO、CDN配信を損なうことなく、Lazy-loaded画像を公開する方法を紹介します。

クイックアンサー：画像はどのようにLazy loadすべきか？

Lazy loadingは、最初のビューポート外から始まる画像のみに使用してください。LCPとなる可能性の高い画像はEAGERに保ち、すべての画像に幅と高さを予約し、キャッシュ可能なCDN URLからレスポンシブなWebPまたはAVIFファイルを配信します。

プレーンなHTMLの場合、最も簡単な実装方法は、ビューポート外の<img>要素にloading="lazy"を適用することです。ヒーロー画像、製品のメイン画像、最初に表示される記事内の画像、またはユーザーがスクロールする前に必ず表示されなければならない画像には適用しないでください。

迷った場合は、LighthouseまたはChrome DevToolsでページをテストしてください。Lazyな画像がLCP要素として報告された場合は、その画像からlazy loadingを削除し、fetchpriority="high"の検討をしてください。

Lazy loadingは実際に何を変えるのか？

Lazy loadingはリクエストのタイミングを変更します。ブラウザは、ユーザーがそれを見るのに十分に近づくまで画像をダウンロードするのを待つことができます。これにより、長いページでの帯域幅の節約になり、初期のリクエスト負荷が軽減され、CSS、フォント、スクリプト、および可視な画像が先に完了する機会が増えます。

これは、巨大な画像を小さくするわけではありません。2400 pxのJPEGは、最終的にロードされた後も依然として無駄です。Lazy loadingを、最初からリサイズ、圧縮、レスポンシブなマークアップと組み合わせて使用してください。Image Compression Deep Diveではバイト削減について、Mobile Image Optimization Guideではsrcsetとモバイル表示サイズについて解説しています。

ネイティブブラウザ機能は、HTMLImageElement.loadingで画像とiframeのloadingプロパティとしてMDNに文書化されています。モダンなサイトでは、JavaScriptによるlazy-loadingライブラリを追加する前に、このブラウザ機能を優先してください。

どの画像をLazy loadすべきではないか？

ページの最初の印象を決定づける画像には、Lazy loadingを適用しないでください。一般的な間違いは、それが万能のパフォーマンス修正策のように見えるため、CMSテンプレート内のすべての画像にloading="lazy"を適用することです。

以下の画像はEAGERに保ってください：

1. メインのヒーロー画像。
2. 購入ボタンの上にある製品画像。
3. モバイルで記事の上部に近い位置に表示される最初の画像。
4. インタラクション前に可視である必要があるロゴまたはインターフェースのスクリーンショット。
5. ChromeがLCP要素として報告する任意の画像。

GoogleのCore Web Vitalsガイダンスでは、LCPをビューポート内の最大の可視コンテンツ要素のレンダリング時間として扱っています。詳細はLargest Contentful Paintを参照してください。この要素が画像である場合、そのリクエストを遅延させることは、指標を悪化させる最も簡単な方法の一つです。

テンプレートにはこのルールを使用してください：最初の画像スロットはデフォルトでEAGERとし、後続の繰り返し可能な画像ブロックはデフォルトでLAZYとします。その後、モバイルスクリーンショットが異なる最初のビューポートを示す場合は、ページタイプごとに上書きします。

HTMLでLazy loadingを実装する方法は？

まずネイティブなマークアップを使用してください：

<img
  src="/images/gallery-chair.webp"
  alt="Walnut chair photographed from the front for a product gallery"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
>

widthとheight属性は、loadingと同じくらい重要です。これらはファイルが到着する前にブラウザにレイアウトスペースを予約させるからです。予約されたスペースがない場合、遅延した画像がテキストをページの下に押し下げ、Cumulative Layout Shiftを引き起こす可能性があります。

レスポンシブな画像の場合、フォールバックの<img>にLazy loadingを残してください：

<picture>
  <source type="image/avif" srcset="/images/gallery-chair-800.avif 800w, /images/gallery-chair-1200.avif 1200w">
  <source type="image/webp" srcset="/images/gallery-chair-800.webp 800w, /images/gallery-chair-1200.webp 1200w">
  <img
    src="/images/gallery-chair-1200.webp"
    alt="Walnut chair photographed from the front for a product gallery"
    width="1200"
    height="800"
    sizes="(max-width: 700px) 92vw, 680px"
    loading="lazy"
  >
</picture>

LCPとなる可能性の高い画像には、反対のパターンを使用してください：

<img
  src="/images/product-hero.webp"
  alt="Walnut lounge chair with green cushion on a white studio background"
  width="1600"
  height="1000"
  fetchpriority="high"
>

Googleのbrowser-level image lazy loadingに関する記事では、ネイティブなLazy loadingを推奨し、最初の可視ビューポート内の画像は通常通りロードすべきだと警告しています。このアドバイスは、2026年の公開における最もクリーンなベースラインであり続けています。

Lazy loadingはSEOにどう影響するか？

重要なコンテンツがレンダリングされたページで発見可能である限り、Lazy loadingはSEOにとって安全です。Googleは最新のJavaScriptを処理できますが、最終的な画像URLがインタラクション、スクロールのみのスクリプト、クッキー、または壊れたプレースホルダーの背後に隠れている場合、画像SEOは弱くなります。

コンテンツ画像には通常の<img>または<picture>マークアップを使用してください。説明的なaltテキスト、クロール可能なCDN URL、そして画像を説明する周囲のコピーを維持してください。Image SEO Guide 2026には、より広範なクローリングとaltテキストのワークフローがあります。

Google Search CentralのLazy loadingに関するJavaScript SEOガイダンスでは、コンテンツはビューポート内で可視になったときにロードされるべきであり、クリックや入力などのユーザーアクションに依存すべきではないと述べています。詳細はFix lazy-loaded contentを参照してください。これは、画像ギャラリー、タブ、無限スクロールページにとって有用なガードレールです。

Lazy loadingはどれだけのパフォーマンスを節約できるか？

節約される量は、最初のビューポートの下に何枚の画像があり、それらのファイルがどれだけ大きいかによって異なります。長い記事では、ブラウザは初期ロード中にほとんどのボディ画像をダウンロードするのを避けるかもしれません。可視写真が1枚の短い製品ページでは、Lazy loadingによる節約はほぼゼロかもしれません。

この記事内の4つのグラフィックを、公開サイズでローカルWebPファイルとしてエンコードしました。最終的なアセットはそれぞれ25 KBから36 KBであり、ここでは大きなバイトの問題を隠しているわけではありません。より大きな利点はリクエストのタイミングから生じます。カバーはすぐに利用可能であり、後続の図は読者がスクロールするまで待つことができます。

Lazy loadingのせいにする前に、この順序を使用してください：

1. ソース画像を最大の実際の表示スロットにリサイズする。
2. 写真と混合グラフィックをWebPまたはAVIFに変換する。
3. モバイルレイアウトのためにsrcsetとsizesを追加する。
4. 画像の寸法またはアスペクト比を予約する。
5. LCP画像をEAGERに保つ。
6. ビューポート外の画像のみをLazy loadする。
7. 長期間キャッシュを持つCDNを通じて公開する。
8. 狭いモバイルビューポートでページをテストする。

より広範な手順が必要な場合は、Complete Image Optimization Checklistが、公開前の良い最終チェックとなります。CDNルールとキャッシュヘッダーについては、Image CDN Guideを使用してください。

公開前に何をテストすべきか？

コードだけでなく、レンダリングされたページをテストしてください。ネイティブなLazy loadingのブラウザのしきい値は実装の詳細であり、デスクトップで機能するページでも、390 pxのモバイルビューポートで誤った画像を遅延させる可能性があります。

この公開チェックを実行してください：

• カバーまたはヒーロー画像がEAGERにロードされる。
• LCPの可能性が高い画像がloading="lazy"としてマークされていない。
• すべての画像にwidthとheight、または安定したアスペクト比のコンテナがある。
• ビューポート外の画像はloading="lazy"を使用している。
• レスポンシブ画像には現実的なsizes値が含まれている。
• CDN画像URLがHTTP 200を返す。
• ファイル名が可視な画像を説明している。
• altテキストが具体的で、キーワードで詰め込まれていない。
• LighthouseまたはPageSpeed Insightsがlazy画像をLCPとしてフラグ立てしない。
• モバイルスクリーンショットに大きな空白やレイアウトのジャンプがない。

開発者チーム向けには、テンプレートルールを追加してください：繰り返し使用されるボディ画像コンポーネントのみをデフォルトでLazy loadすべきです。ヒーローコンポーネント、製品メインメディア、およびファーストビュー以上の編集用画像は、明示的な決定を必要とします。

2026年のLazy-loadingチェックリスト

Lazy loadingは、画像パイプラインの小さな一部として機能するのが最も効果的です。フォーマット、寸法、優先度、アクセシビリティ、CDNのチェックの後に行われるべきです。

出荷前に、最初のビューポートを検査し、一つの実用的な質問をしてください：すべてのビューポート外の画像がスクロールするまで待っても、ページはまだ意味を持つでしょうか？もしそうなら、Lazy loadingはおそらく役立っています。もしページが空のヒーロー枠から始まる場合は、他のものを触る前に優先度を修正してください。