レイジーローディング ページの起動やデータ量を減らせるけど、使い方を間違えると表示されるコンテンツが遅くなって、コアメトリクスが悪くなっちゃうんだ。この記事では、レイジーローディングがウェブパフォーマンスを下げちゃう理由、LCPが影響を受ける理由、そして実際に画像の表示を速くする具体的な設定について紹介するよ。.
中心点
はじめに以下の重要なポイントを知っておくと、画像を読み込むときの落とし穴をすぐに見つけられるよ。.
- 折り込み広告 レイジーロードは絶対にしないでください。そうしないと、LCPが低下します。.
- 優先順位付け リクエストはヒーローのイメージを決定づける重要な要素です。.
- 寸法 設定（幅/高さ）により、CLS が大幅に低下します。.
- プレースホルダー スクロール時の視認性を向上させます。.
- 見本市 推測する代わりに：LCP画像を特定してテストする。.
レイジーローディングが可視画像を遅くする理由
多くの ページは、最初の最大の画像を誤って loading="lazy" これにより、ダウンロードの開始が延期されます。ブラウザは、より緊急性が高いと判断したリソースをロードし、ヒーロー画像については、ビューポートに近づいた時点でロードを待機します。しかし、この画像こそが、速度の知覚に影響を与える LCP 要素であることが多いのです。 Martin Splitt は、Largest Contentful Paint が測定可能になるほど遅れるため、この慣行を明確に警告しています（出典：[3]）。そのため、私は、レンダリングをブロックする代わりに、Above-the-Fold 画像をすべて Eager Loading に設定しています。.
ネットワークの優先順位付けの実践
ブラウザ 通常、表示されているコンテンツは自動的に優先されますが、レイジーローディングはこの順序を無効にします。重要な画像にレイジーを設定すると、その画像の読み込みは後回しにされ、CSS、JS、または重要度の低いメディアが帯域幅を占有します。これは、特に CPU や接続が弱いモバイルデバイスで速度低下の原因となります。 DevTools でリクエストの順序を確認し、必要に応じてプリロードや優先順位を正しく設定します。詳細については、以下をご覧ください。 リクエストの優先順位付け ボトルネックを的を絞って解決するのに役立ちます。.
データ状況：LCPの比較
数字 HTTP Archive のデータによると、レイジーローディングを採用しているページは、採用していないページよりも平均して LCP 値が低いことがわかります（出典：[1]）。 75 パーセンタイルの平均値は、レイジーローディングを使用しない場合は 2.922 ミリ秒、レイジーローディングを使用する場合は 3.546 ミリ秒で、約 624 ミリ秒の差がありました。特に注目すべきは、WordPress ページの場合、レイジーローディングを使用しない場合は 3.495 ミリ秒、使用する場合は 3.768 ミリ秒という結果でした。 web.dev での A/B テストにより、アーカイブページでレイジーローディングを無効にすると、LCP がデスクトップで約 4 %、モバイルで約 2 % 改善されることが確認されています（出典：[1]）。この効果は、測定誤差として無視できるほど大きなものです。.
| シナリオ | LCP（75パーセンタイル） | 備考 |
|---|---|---|
| レイジーローディングなし | 2.922 ミリ秒 | より良いHTTP Archive [1] による中央値 |
| レイジーローディングで | 3.546 ミリ秒 | 悪い中央値 (+624 ミリ秒) [1] |
| WordPress レイジーなし | 3.495 ミリ秒 | より低い Lazy [1] よりも |
| WordPress と Lazy | 3.768 ミリ秒 | より高いLCP は Lazy [1] なしとして |
| TwentyTwentyOne A/B (デスクトップ) | -4 % | 改善 無効化後 [1] |
| TwentyTwentyOne A/B (モバイル) | -2 % | 利益 バイト数が多いにもかかわらず [1] |
欠落している次元とCLS
なし 固定幅と固定高さの場合、画像が表示されるとレイアウトがずれてしまいます。これにより累積的なレイアウトシフトが発生し、操作に支障をきたし、さらなるリフローを引き起こします。そのため、私は常に幅と高さの属性を設定するか、CSSのアスペクト比を使用しています。これにより、データが到着する前にブラウザがスペースを確保します。ページはより落ち着いた印象になり、表示されるコンテンツは計画的に構築されます（出典：[5]）。.
モバイルシナリオと低速ネットワーク
時点では モバイルデバイスでは、起動時のダウンロードの遅延がより大きな影響を与えます。JavaScript の CPU 時間、変動するレイテンシ、および省エネは、遅い画像リクエストのコストを増加させます。レイジーローディングは、リクエストをまさにこの弱い段階に延期します。 そのため、私は重要なリソースを優先し、JS を削減し、チェーンを短くすることに注意を払っています。そうすることで、デバイスは最初のビューを処理し、最も重要な画像が後回しにされることはありません。.
Above-the-Fold のイージアーローディング
仝 簡単なルール：ユーザーがすぐに目にするものは、すぐに読み込む。LCP画像については、 loading="eager" または、Lazy 属性を完全に削除してください。さらに、 rel="preload" 適切な場合、さらに早い段階での呼び出し開始を支援します。私は Lighthouse と Core Web Vitals のメトリクスを使用してその効果を監視しています。より詳しく知りたい方は、こちらの優れた入門記事をご覧ください。 Core Web Vitals を正しく読み取る.
Intersection Observer を効果的に活用する
のために 折り目の下のコンテンツについては、引き続きレイジーローディングを使用しますが、それは慎重に行います。Intersection Observer を使用すると、オフスクリーン画像が少し早くロードされるしきい値を設定することができます。これにより、ユーザーが素早くスクロールしても、表示がちらつくことを防ぐことができます。これをデータバインディングと組み合わせて、必要に応じて画像ソースを設定し、優先順位を尊重しています。有用な実践の詳細については、以下の記事をご覧ください。 Intersection Observer.
プレースホルダーと知覚速度
ぼやけ-プレースホルダー、LQIP、または BlurHash は、実際の画像が届くまでギャップを隠します。これにより、待ち時間の感覚が短縮され、移行がスムーズになります。 私は、プレースホルダーが最終的な寸法を使用するように注意して、ジャンプが発生しないようにしています。同時に、プレースホルダー自体が帯域幅をほとんど消費しないように、大幅に圧縮しています。これらの対策により、実際のダウンロードを遅らせることなく、ユーザーの認識をサポートしています（出典：[6]）。.
Eコマース：グリッド、無限スクロール、優先順位
ショップ-カタログは、ユーザーがスムーズにスクロールしている間に多くのプレビュー画像を読み込みます。過度に積極的なレイジー戦略は、再読み込みを遅らせ、灰色のフィールドを生成します。 そのため、私は、サムネイルには、余裕のあるプリロードのしきい値と、最低限ではない低品質を設定しています。最初の数行を熱心にロードして、スムーズなスタートを切ることが重要です。無限スクロールは、次の製品画像セットのために、優先順位の高い薄いパイプラインを利用することで、さらにメリットを得ることができます（出典：[7]）。.
測定：LCP画像を見つける方法
時点では Chrome DevTools で LCP 要素を選択し、その URL を確認して、ウォーターフォール位置を確認します。リクエストが遅れている場合は、レイジーを削除するか、優先度を上げます。 その後、フィルムストリップビューをチェックして、目に見える進捗状況を評価します。PageSpeed Insights は、フィールドデータとラボデータも提供してくれます。この測定によってのみ、変更が実際に効果をもたらしているかどうかを判断することができます（出典：[1]）。.
構成：よくあるアンチパターンを避ける
多くの プラグインは、ロゴ、スライダー、ヒーロー要素を含むすべての画像に対して、グローバルにレイジーローディングを設定します。 私は、表示されているメディアのレイジーローディングを無効にし、オフスクリーン画像にはプレースホルダーを設定し、固定サイズを定義しています。また、スクリプトの初期化が遅れて画像リクエストの速度が低下していないかも確認しています。CDN ルールは、LCP 画像に有益な優先度を上書きしてはなりません。これらの調整により、典型的なエラーの原因を取り除くことができます（出典：[1]、[8]）。.
LCP を犠牲にすることなく帯域幅を節約
怠惰 Loading は画像バイトを大幅に削減するため、サーバーとデータ量を節約できます。テストでは、オフスクリーン画像が不要になるため、最初のレンダリングで数倍の節約効果があることが示されています（出典：[1]）。このメリットは、LCP 画像を保護して扱う限り、その使用を正当化するものです。 そのため、私は Above-the-Fold (eager/preload) とその他 (lazy/intersecting) を厳密に区別しています。これにより、バイト数の削減と迅速な初回構築を両立しています。.
クリーンな実装のための技術チェックリスト
私の チェックリストにより、実装をスリムかつ確実に実行できます。LCP 画像を特定し、レイジーローディングを無効にして、明確な寸法を設定します。リクエストの順序、優先度、プリロードを慎重にテストします。 オフスクリーン画像には、Intersection Observer と適切なしきい値を使用します。Lighthouse およびフィールドで効果を監視し、リグレッションを回避します。さらに、レイジーローディングに関するブラウザガイドも、落とし穴を早期に発見するのに役立ちます（出典：[5]、[8]）。.
レスポンシブ画像：srcset、sizes、アートディレクション
正しい レスポンシブ画像を使用することで、過剰または不足を防止します。私は ソースセット 幅の記述子と正確な サイズ, 実際のレイアウト幅に相当する。あまりにも一般的な sizes="100vw" モバイルデバイスは、しばしば大きなファイルをロードすることを強いられます。アートディレクションやさまざまなトリミングには、私は <写真 をもって 媒体-クエリを入力します。重要：レスポンシブなバリエーションも、固定の寸法または CSS を取得します。アスペクト比, CLS を低く抑えるためです。これにより、視覚的な品質を犠牲にすることなく、ページのバイト数を節約できます。.
優先度ヒントとプリロードを正しく使用する方法
のために LCP画像で、ブラウザに明確な指示を出します。 fetchpriority="high" am <img> 重要性を示し、補足する loading="eager". プリロードは控えめに使用しています。 <link rel="preload" as="image"> 呼び出しを前倒しすることは可能ですが、同じパラメータ（以下を含む）を使用する必要があります。. imagesrcset そして imagesizes）のように、最終的な イムグ 二重ダウンロードを避けるために、プリロードは避けています。 Above-the-Fold 以外の画像については、回線を空けるためにプリロードを避けています。さらに、画像 CDN への早期の DNS および TLS 構築も効果的ですが、優先順位を薄めるようなインフレ的なヒントは避けています。.
背景画像と IMG：LCP に適したマークアップの決定
多くの ヒーローセクションを使用する 背景画像. しかし、背景グラフィックは多くの場合、LCPの対象にはなりません。ブラウザは別の要素をLCPとして選択しますが、背景画像は依然として多くの帯域幅を消費します。私はメインのモチーフを実際の <img> マークアップで、オプションで object-fit, レイアウトの要望を満たすためです。これにより、ブラウザは要素を正しく優先順位付けし、測定し、早期に表示することができます。装飾的なテクスチャは CSS 背景として残り、重要なモチーフは img/picture.
デコード、レンダリング、メインスレッド
写真-デコードにはCPUを消費します。オフスクリーン画像には、私は decoding="async", 、解凍によってメインスレッドがブロックされないようにするためです。LCP 画像については、 decoding="auto", ブラウザが同期デコードによって最も早い表示が可能かどうかを判断できるようにします。ネイティブのブラウザ機能で十分な場合は、レイジーローディング用の追加の JS ライブラリは使用しません。初期化を行うとメインスレッドが占有され、ヒーロー画像の配信が遅延する可能性があるためです。.
フレームワーク、ハイドレーション、CMSのデフォルト設定
近代 フレームワークやCMSには、独自の画像デフォルトが設定されています。WordPressは、デフォルトで多くの画像をレイジーとしてマークしますが、私は最初のビューポートのロゴ、ヒーロー、スライダーについては、意図的にこれを上書きしています。React/Next、Vue/Nuxt、Svelteでは、画像コンポーネントがヒーロー画像をハイドレーションの背後に隠さないよう注意しています。 サーバーサイドレンダリングとストリーミングは、画像がすでに HTML 内にあり、早期に参照される場合にのみ有効です。私は、LCP 画像を JS によって最初に挿入することを避けています。アプリの初期化に遅延が生じると、メトリクスがずれて、目に見える時間のロスになります。.
サーバーおよびネットワークレベル：HTTP/2/3、キャッシュ、アーリーヒント
時点では プロトコルレベルで余裕を確保：クリーンなキャッシュヘッダー (キャッシュ・コントロール, イータグ, 不変）は、繰り返しアクセスをスリムに保ちます。HTTP/2/3 の優先順位付けは、重要なオブジェクトの早期配信をサポートします。これは、ブラウザが、遅延設定の誤った設定による人為的なブロックに遭遇しない場合に最も効果的に機能します。103 アーリーヒントは、最終的な応答の前にプリロードを開始することができます。 私はこれを、コンパクトな次世代フォーマット（AVIF/WebP）と、回線を混雑させないよう適切に段階的に設定された品質選択と組み合わせています。.
特別なケース：動画、iframe、サードパーティ
ヒーロー-ビデオや埋め込みiframeは帯域幅を大量に消費します。ビデオの開始画像には、軽量のポスターを イムグ 通常のヒーロー画像と同様に優先順位を設定し、実際の動画は制御して読み込みます。ビューポート外の iframe は遅延読み込みしてもかまいませんが、広告、タグマネージャー、ソーシャル埋め込み用のスクリプトが LCP 画像を押し出すことは防止します。可能な場合は、 loading="lazy" iframe は折り目のかなり下に配置し、その初期化がメインのレンダリングパスを妨げないようにしてください。.
品質、フォーマット、アーティファクト
画質 は直線的ではありません。圧縮を少し行うだけで、目に見える悪影響を与えずにバイト数を大幅に削減することができます。 私は、モチーフの種類ごとにさまざまな品質レベル（AVIF/WebP/JPEG など）をテストし、Retina 密度用のバリエーションを用意しています。サムネイルには、多くの場合、より圧縮率の高いバージョンで十分です。これにより、メイン画像に十分な帯域幅を確保できます。重要：不必要に大きなピクセルサイズを配信しないでください。以下の組み合わせは避けてください。 ソースセット そして正確な サイズ 狭いディスプレイでの大きすぎる表示を防ぎます。.
スクロール動作としきい値を微調整する
仝 オフスクリーン画像のタイミングは、ユーザーがギャップを認識するかどうかを決定します。私は設定します rootMargins Intersection Observer で、画像が画面の長さの 1 倍分先に到達してから読み込みが開始されるように設定します。高速のデバイスではしきい値を小さく、低速のネットワークではしきい値を大きくすることができます。重要なのは、このロジックが LCP 画像に影響を与えないことです。そのため、私は次のルールを定めています。Above-the-Fold のすべては eager、その下は動的なしきい値に従う。.
生産のためのテスト戦略：RUM、ロールアウト、ガードレール
ラボ測定は重要ですが、現場での数値が最終的な判断材料となります。変更は段階的に実施し、LCP、FID/INP、CLS を実際のユーザーモニタリングで観察します。75 パーセンタイルの偏差は、私の早期警告システムとなっています。 DevTools で、弱いネットワークと CPU スロットリングをシミュレートし、ウォーターフォール、イニシエーター、優先度をチェックします。フィルムストリップは、ヒーロー画像が本当に早く表示されるかどうかを示します。フィールドとラボで一貫して改善が見られた場合にのみ、新しい構成を標準と宣言します（出典：[1]）。.
簡潔かつ明確：行動指針
セット レイジーローディングを選択的に使用し、LCP 画像を最優先で扱います。すぐに表示される画像についてはレイジーローディングを解除し、サイズを指定して優先度を確保します。 プレースホルダーと Intersection Observer を使用して、スクロールをスムーズに保ちます。推測に頼るのではなく、DevTools、Lighthouse、フィールド値を使用して、あらゆる変更を測定します。これにより、LCP 値の向上、レイアウトの安定化、すべてのデバイスでの高速かつ信頼性の高い表示を実現できます（出典：[1]、[3]、[5]、[8]）。.
