LCP の Resource Load Delay を最適化する

このガイドは Largest Contentful Paint (LCP) ハブの一部です。Resource Load Delay は、多くの場合、LCP スコアの悪化の最大の要因となります。ほとんどのチームは画像の圧縮に集中しますが、本当の問題はブラウザが画像を発見するのが遅すぎることです。

LCP の Resource Load Delay を最適化する

Largest Contentful Paint (LCP) は、TTFB、Resource Load Delay、Resource Load Duration、Element Render Delay の 4 つのフェーズで構成されています。開発の取り組みはファイル圧縮による Load Duration の短縮に集中しがちですが、これは遅延のより大きな原因となることが多い Resource Load Delay を見落としています。ダウンロード開始前のこの遅延は、LCP に数百ミリ秒を追加し、2.5 秒の「Good」のしきい値を超える原因となる可能性があります。

簡単なヒント: LCP が画像の場合、テキストよりも常に悪化する傾向があります。RUM データで LCP 要素のタイプをトラッキングする必要があります。そうしなければ、盲目的に飛行しているのと同じです。

正確な定義: ダウンロード前の重要な待機時間

Resource Load Delay とは、TTFB からブラウザが LCP リソースのダウンロードを開始するまでの時間です。これはダウンロード時間ではなく、フェッチが始まる前に発生する発見のレイテンシです。この値が高い場合、初期の HTML payload の中にブラウザがリソース URL を見つけられないというアーキテクチャ上の問題があることを示しています。この Resource Load Delay は、ブラウザが LCP リソースが必要であることを特定し、それをフェッチすると決定するまでに費やす時間とみなすことができます。

テキストベースでシステムフォントを使用してレンダリングされる LCP 要素の場合、外部リソースをフェッチする必要がないため、この Resource Load Delay は通常ゼロになります。Resource Load Delay の値が高くなるのは、画像や動画ファイルなどの外部ネットワークリソースに依存する LCP 要素に特有の現象です。

発見のエンジン: プリロードスキャナ vs DOM パーサー

Resource Load Delay を減らすには、ブラウザがリソースをどのように発見するかを理解する必要があります。この発見プロセスの効率が、レイテンシを決定する主な要因です。ブラウザは高速パスと低速パスの 2 つのメカニズムを使用します。

• プリロードスキャナ (高速パス): これは生の HTML から <img> や <link> タグ内のリソース URL をスキャンする高速なセカンダリパーサーです。CSS が解析されたり JavaScript が実行されたりする前に、直ちにそれらをダウンロードキューに入れます。これは、あらゆる重要なリソースにとって最適なパスです。
• DOM パーサー (低速パス): これは、完全な Document Object Model (DOM) と CSS Object Model (CSSOM) を構築するメインパーサーです。CSS の background-image や JavaScript によって挿入された要素など、初期の HTML に見つからないリソースは、このパーサーによってのみ発見されます。他のファイルが先にダウンロードされ実行されることに依存しているため、依存関係の連鎖が生まれ高いレイテンシが生じる低速パスとなります。

Resource Load Delay を最適化するための戦略全体は、1 つの原則に基づいています。それは、LCP リソースの URL がプリロードスキャナによって発見可能であることを確認することです。初期の HTML ドキュメントから URL を隠すようなパターンはすべて、ブラウザに遅い発見パスの使用を強制します。この待機期間がそのまま Resource Load Delay に直結します。効果的な最適化はすべて、LCP リソースを高速パスに配置するように HTML を設計することに関するものです。ブラウザのリソース優先順位付けの完全なガイドについては、リソースの優先順位付けに関する記事をご覧ください。

なぜ Load Delay が重要なのか

よくある誤解は、LCP が遅いのは「ファイルサイズ」の問題であるというものです。このため、チームは Resource Load Duration を短縮するための画像圧縮にのみ注力しがちです。アセットの最適化も一つの要因ですが、実際のフィールドデータの分析によると、LCP が悪い多くのサイトにおいて、パフォーマンスの主なボトルネックは Resource Load Duration ではなく、Resource Load Delay であることが示されています。

フィールドデータによると、LCP スコアが悪いサイトの中央値では 1.3 秒の Resource Load Delay が発生しています。これは、「Good」な LCP スコアの予算である 2.5 秒の半分以上であり、LCP リソースのダウンロードが始まる前にすべて消費されています。データは、これらのサイトがダウンロード自体にかかる時間の 4 倍近い時間を、ダウンロードが開始されるまでの待機に費やしていることを示しています。

このデータは、開発の労力が頻繁に誤った方向に向けられていることを明らかにしています。チームは何週間もかけて画像のキロバイト単位を削り Load Duration を数ミリ秒短縮する一方で、1.5 秒の Load Delay を引き起こしているアーキテクチャ上の問題は放置されたままです。LCP は連続的なプロセスです。初期フェーズでの遅延は、後のフェーズを最適化しても取り戻すことはできません。フェッチが 1 秒以上遅れた場合、100 ミリ秒のダウンロード時間の違いは最終的な LCP スコアには無関係です。最も影響の大きい最適化には、単なるアセット圧縮ではなく、リソースの発見可能性の向上など、アーキテクチャの変更が含まれます。焦点を、アセットを小さくすることから、より早く発見されるようにすることに移す必要があります。

Resource Load Delay を検出する方法

Resource Load Delay を修正するには、まず正確に測定する必要があります。プロフェッショナルなワークフローは、まず実際のユーザーデータ (RUM) で問題を定義し、その後に Chrome DevTools に移行して詳細な分析を行うことです。

ステップ 1: フィールドデータ (RUM) を分析する

フィールドデータ、または Real User Monitoring (RUM) は、実際のユーザーセッションから収集されます。公開されている Chrome User Experience Report (CrUX) や私自身のツールである CoreDash のような RUM ツールは、「現実世界で何が起きているのか？」という問いに答えます。フル機能の RUM ツールは、LCP の各サブパーツの内訳も提供し、ユーザー全体の Resource Load Delay の中央値を示します。このデータは、LCP の問題が存在することを検証し、どの URL が影響を受けているかを示し、ユーザーが実際に見ている一般的な LCP 要素を明らかにします。本当の問題を解決していることを確認するために、ここから始める必要があります。

ステップ 2: DevTools で診断する

RUM データによってターゲットページと LCP 要素が特定されたら、Chrome DevTools を使用して原因を診断します。ここでの目的は、問題を再現し、LCP のサブパーツを測定して、正確な Resource Load Delay の値を取得することです。DevTools は、メインスレッド分析を実行して、どのタスクが実行され、レンダリングプロセスをブロックしている可能性があるかを正確に確認する場所でもあります。

Chrome DevTools Performance パネルのステップバイステップガイド

Chrome DevTools の Performance パネルは、LCP を分析し、Load Delay を定量化するための不可欠なツールです。

1. セットアップと構成:

• ページを右クリックして「検証」を選択するか、ショートカット Ctrl+Shift+I (Windows/Linux) または Cmd+Option+I (Mac) を使用して、Chrome DevTools を開きます。
• Performance タブに移動します。
• キャプチャ設定で Web Vitals チェックボックスが有効になっていることを確認します。これにより、パフォーマンスタイムラインに Core Web Vitals 情報がオーバーレイされます。
• 現実的なユーザー条件をシミュレートするために、CPU とネットワークのスロットリングを適用します。モバイルテストでは、CPU に「4x slowdown」、ネットワークプロファイルに「Fast 3G」または「Slow 4G」を使用するのが一般的な出発点です。

2. パフォーマンスプロファイルの記録:

• Performance パネルの「Record and reload page」ボタン (円形の矢印アイコン) をクリックします。これにより記録が開始され、ページがリロードされ、ページが完全に読み込まれると記録が停止します。

3. 分析と解釈:

• Timings トラック: メインのタイムラインビューで、Timings トラックを見つけます。LCP というラベルの付いたマーカーが表示されます。このマーカーにカーソルを合わせると、メインのビューポートのスクリーンショットで対応する LCP 要素がハイライト表示され、合計 LCP 時間が表示されます。
• フェーズ別の LCP 内訳: Timings トラックの LCP マーカーをクリックします。パネル下部の Summary タブに、LCP タイミングの詳細な内訳が表示されます。この内訳には、Load delay を含む 4 つのサブパーツそれぞれの所要時間がミリ秒単位で明示的に示されています。この値は、特定のページ読み込みにおける Resource Load Delay の最も直接的かつ正確な測定値です。
• メインスレッド分析: タイムラインを調べる際、Main トラックで長いタスク (赤い三角形のフラグが付いたアクティビティのブロック) を探します。これらの長いタスクが、LCP リソースの読み込み完了後、LCP マーカーの前に発生している場合、それらは関連性はあるものの別の問題である Element Render Delay に寄与している可能性が高いです。

一般的な原因と影響の大きい解決策

高い Resource Load Delay は、LCP リソースの発見が遅れるか、低い fetchpriority (フェッチ優先度) が割り当てられるかのいずれかによって引き起こされます。ここでは、最も一般的なアーキテクチャ上の間違いとその解決策を紹介します。

原因: LCP が CSS 経由で読み込まれている

問題点: プリロードスキャナは CSS ファイルを解析しません。LCP 画像が CSS の background-image で定義されている場合、その URL はこの高速スキャナからは見えません。ブラウザは、HTML をダウンロードし、CSS ファイルのリンクを見つけ、CSS ファイルをダウンロードし、CSSOM を構築し、スタイルを適用した後でのみ、画像を発見することができます。この依存関係の連鎖は、直接的に高い Resource Load Delay を引き起こします。このパターンの詳細については、背景画像の遅延読み込みに関するガイドをご覧ください。

解決策: 正しい実装は、重要な LCP 要素に対して background-image の使用を避けることです。代わりに標準の <img> タグを使用してください。これにより、画像 URL が HTML 内に直接配置され、プリロードスキャナが直ちに見つけられるようになります。CSS を使用して同じ視覚的な結果を得ることができます。

実装例:

アンチパターン (これは行わないでください):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

ベストプラクティス (代わりにこれを行ってください):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

この実装は同じ視覚的な結果を提供しますが、LCP 画像を可能な限り早い段階で発見可能にし、Load Delay を最小限に抑えます。

原因: クライアントサイドレンダリングと JavaScript のインジェクション

問題点: React や Vue のようなクライアントサイドレンダリング (CSR) フレームワークを使用するアプリケーションは、しばしば最小限の HTML シェルのみを提供します。LCP の <img> タグを含む実際のコンテンツは、大規模なフレームワークのバンドルがダウンロードされ、解析され、実行された後でのみ JavaScript によって DOM に挿入されます。このプロセスは根本的にプリロードスキャナから LCP リソースを隠し、高い発見レイテンシを生み出します。

解決策: 最も効果的な解決策は、初期レンダリングをクライアントからサーバーに移すことです。

• サーバーサイドレンダリング (SSR) または静的サイトジェネレーション (SSG): SSR や SSG のようなアーキテクチャパターンは、サーバー上で完全な HTML を生成します。ブラウザは、<img> タグとその src 属性を含む完全なドキュメントを受け取るため、LCP リソースはプリロードスキャナによって直ちに発見可能になります。これは、パフォーマンスが重要なあらゆるページに必要なアーキテクチャです。
• フレームワーク固有の最適化: 最新のフレームワークは、組み込みの最適化機能も提供しています。例えば、Next.js の <Image> コンポーネントには priority プロパティがあります。これを true に設定すると、フレームワークに対して適切な <link rel="preload"> と fetchpriority="high" 属性を自動的に追加するよう指示され、画像が正しい優先度で発見されフェッチされることが保証されます。

原因: LCP 画像での loading="lazy" の使用

問題点: これは頻繁に見られる、影響の大きい間違いです。loading="lazy" 属性は、画像がビューポートに近づくまでフェッチを遅らせるようブラウザに直接指示するものです。これはスクロールせずに見えない位置 (below-the-fold) にある画像にとっては正しい最適化ですが、スクロールせずに見える位置 (above-the-fold) の LCP 要素に適用するのは逆効果です。ブラウザのプリロードスキャナは loading="lazy" を持つ画像を無視するように設計されているため、発見が遅れ、高い Resource Load Delay が生じることが保証されてしまいます。

解決策: 解決には注意深い対応が必要です。

• LCP 画像から loading="lazy" を削除する: LCP 要素になる可能性が高い画像には、loading="lazy" 属性を含めてはなりません。ブラウザのデフォルトの動作は loading="eager" であり、これは重要な above-the-fold コンテンツにとって正しい設定です。loading 属性を完全に省略しても同じ効果があります。
• サードパーティツールの監査と構成: サードパーティツールの監査も行う必要があります。WordPress のような多くの CMS プラットフォームや様々な画像最適化プラグインは、自動的にすべての画像に遅延読み込み (lazy loading) を適用します。これらのツールを設定して、LCP 画像をこの動作から除外することが不可欠です。これには多くの場合、ページの最初の 1 つまたは 2 つの画像に対する除外ルールの作成が含まれます。

原因: 最適化されていない HTML 構造と大規模なドキュメント

問題点: プリロードスキャナは HTML ドキュメントを上から下へと処理します。ヘッダーのアイコンやチャットウィジェットのスクリプトのように、重要ではないが帯域幅を消費するリソースが、<body> 内で LCP 要素よりも上に配置されていると、それらが先に発見されダウンロードのキューに入れられます。これにより初期のネットワーク帯域幅が消費され、LCP リソースのダウンロードが遅れる可能性があります。大規模な HTML ドキュメントも問題になり得ます。LCP 要素がブラウザが受け取る最初のデータチャンク (約 14KB) に含まれていない場合、その発見は少なくとも 1 回のネットワークラウンドトリップ分遅れることになります。

解決策: HTML 内のコンテンツの構造と優先度を最適化します。

• HTML の順序を並べ替える: 可能な限り、LCP 要素の <img> タグまたはテキストブロックが、<body> タグ内のなるべく早い位置に配置されるようにします。
• 重要でない画像の優先度を下げる: (ヘッダーのアイコンのように) HTML ソースの早い段階で表示させる必要がある必須でない画像には、loading="lazy" を適用します。これにより、プリロードスキャナにそれらをスキップするよう指示し、LCP 要素のためのダウンロードキューを確保します。
• 必須でないスクリプトを遅延させる: 分析、広告、またはソーシャルメディアのウィジェットのスクリプトが、初期のレンダリングにとって重要であることは稀です。それらの <script> タグを <body> の最後に移動するか、defer 属性を使用します。これにより、パーサーのブロックや、LCP リソースとのネットワーク帯域幅の競合を防ぐことができます。

リソースヒントによる高度な優先順位付け

LCP リソースが HTML 内で発見可能になったら、リソースヒントを使用して、フェッチする方法についてより明示的な指示をブラウザに与えることができます。これらのヒントは、発見と優先順位付けのきめ細かい制御を提供します。

<link rel="preload"> を使って早期の発見を強制する

<link rel="preload"> はヒントではなく、ディレクティブ (指示) です。メインパーサーによってまだ発見可能でない場合でも、優先度を高くしてリソースをダウンロードするようブラウザに強制します。これを HTML の <head> に配置することは、フォント、CSS の background-image、または DOM の深い場所に位置する LCP 画像などのリソースにおける発見の遅れの問題を修正する最も直接的な方法です。完全な実装の詳細と例については、LCP 画像をプリロードする方法の専用ガイドをご覧ください。

メカニズム

preload リンクが HTML ドキュメントの <head> に配置されると、プリロードスキャナはそれを識別し、指定されたリソースを即座にダウンロードキューに入れます。これは、外部スタイルシートの @font-face 経由で読み込まれるフォント、CSS background-image の LCP (ただし <img> タグの使用が推奨されます)、または複雑な DOM 構造の深い場所に位置する LCP 画像などのリソースに最適です。

レスポンシブなプリロード

レスポンシブ画像をプリロードする場合、重要な実装の詳細が必要になります。ブラウザがユーザーのビューポートに合わせて正しいサイズの画像を確実にプリロードし、無駄な二重ダウンロードを回避するために、<link rel="preload"> タグには、対応する <img> タグの属性を完全に反映した imagesrcset と imagesizes 属性が必須です。

レスポンシブなプリロードの例:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

潜在的な落とし穴

プリロードはフェッチのタイミング (Load Delay と Load Duration) を解決しますが、ペイントのタイミングは解決しません。プリロードされた画像が到着したときに、重い JavaScript やレンダリングをブロックする CSS によってメインスレッドがブロックされている場合、画像はレンダリングされるまで待機しなければならず、ボトルネックが Load Delay から Element Render Delay に移行する可能性があります。

fetchpriority="high" とブラウザの優先度キュー

fetchpriority 属性は、リソースのダウンロードの相対的な重要性を示すヒントです。これにより、ブラウザのダウンロードキュー内でのリソースの優先度に影響を与えることができます。

ブラウザの優先順位付けの仕組み

ブラウザがページ読み込み中にリソースを発見すると、それぞれに内部の優先度レベルを割り当てます。デフォルトでは、ビューポート内の画像は「Low (低)」の優先度で始まり、ブラウザがレイアウトを完了しそれらが可視であると判断した後に「High (高)」にアップグレードされます。このアップグレードには、ブラウザが先に CSS をダウンロードして解析する必要があるため、遅延が生じます。fetchpriority="high" 属性は、画像が発見された瞬間から「High」の優先度を設定することで、このプロセスを完全にバイパスします。これは優先度のアップグレードによる遅延を排除するため、LCP 画像にとって特に影響が大きいです。

preload vs fetchpriority

これら 2 つのヒントは異なる目的を果たしますが、相互に補完し合います。preload はリソースがいつ発見されてキューに追加されるかに影響します。fetchpriority はキューに入った後の優先度レベルに影響します。この違いを理解することは重要です。preload は遅い発見を解決し、fetchpriority は低い優先度を解決します。HTML 内にすでに存在する多くの LCP 画像にとっては、fetchpriority だけで十分な場合があります。これらがどのように相互作用するかの完全なガイドについては、リソースの優先順位付けに関する記事をご覧ください。

LCP のベストプラクティス

LCP 画像の場合、最適な戦略はそれらを併用することです。まず、<img> タグを HTML の早い段階に配置するか、preload を使用することで、早期の発見を確保します。次に、fetchpriority="high" を <img> タグ (および使用する場合は preload リンク) に直接追加します。この組み合わせにより、リソースが早期に発見されるだけでなく、スタイルシートやフォントなどの他のリソースとのネットワーク帯域幅をめぐる競争に勝つために、可能な限り高い優先度が与えられます。

例:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

fetchpriority="low" を使用する場合

fetchpriority 属性は、優先度を上げるためだけのものではありません。fetchpriority="low" を使用して、LCP 画像と帯域幅を競合する重要でないリソースの優先度を下げることもできます。一般的な候補には、(ヘッダーにある小さなアイコンやアバターのような) LCP 要素ではない above-the-fold 画像や、必要ではあるが緊急ではないプリロードされたリソースが含まれます。これらの競合するリソースの優先度を明示的に下げることで、LCP 画像のための帯域幅の余裕をより多く作り出せます。

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

実証済みの影響

Google Flights を含むケーススタディにおいて、LCP の背景画像に fetchpriority="high" を追加したことで、LCP 時間が 2.6 秒から 1.9 秒に改善し、700ms の短縮が実現しました。

サードパーティ接続の最適化: preconnect と dns-prefetch

問題点

LCP リソースが画像 CDN や Google Fonts のようなフォントプロバイダーなどのサードパーティドメインでホストされている場合、ブラウザはそのドメインへの新しいネットワーク接続を確立する必要があります。このプロセスには、DNS ルックアップ、TCP ハンドシェイク、TLS ネゴシエーションが含まれ、リソースの最初のバイトをダウンロードする前にこれらすべてを完了する必要があります。この接続のセットアップ時間は、クロスオリジンのアセットにおける Resource Load Delay に直接寄与します。

解決策

• preconnect: このヒントは、指定されたサードパーティのオリジンに対する完全な接続セットアップ (DNS、TCP、TLS) を、事前にバックグラウンドで実行するようブラウザに指示します。リソースが実際にリクエストされたときには接続がすでにウォームアップされており、セットアップのレイテンシを排除できます。これは非常に効果的であり、LCP リソースを提供する 1 つまたは 2 つの最も重要なサードパーティドメインに推奨されます。
• dns-prefetch: これは、ドメインの DNS ルックアップのみを実行する軽量なヒントです。preconnect よりも時間の節約は少ないですが、ブラウザのサポート範囲が広く、フォールバックとして、またはそれほど重要でないサードパーティドメインに役立ちます。

実装のベストプラクティス

最大限の互換性を確保するために、両方のヒントを提供します。ブラウザはサポートされている場合は preconnect を使用し、そうでない場合は dns-prefetch にフォールバックします。フォントのような CORS を使用してフェッチされるリソースには crossorigin 属性が不可欠です。

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

表: LCP 最適化のためのリソースヒントの比較

誤用を防ぎ、これらの強力なヒントの明確な役割を明らかにするために、以下の表に比較の要約を示します。

全体的および将来を見据えた戦略

リソースヒントを超えて、より広範なアーキテクチャの決定により、Resource Load Delay をさらに短縮することができます。

モダン CDN の役割

コンテンツデリバリーネットワーク (CDN) は、ウェブパフォーマンスの基礎となるテクノロジーであり、特に LCP リソースにおいて、間接的ではありますが大幅に Resource Load Delay を短縮します。

• 接続のオーバーヘッドを減らす: アセットをグローバルなサーバーネットワークに分散させることで、CDN はコンテンツを地理的にユーザーに近い場所に配置します。これにより、接続セットアップ時間の構成要素である DNS ルックアップ、TCP ハンドシェイク、TLS ネゴシエーションに必要なラウンドトリップタイム (RTT) が本質的に減少します。CDN でホストされている LCP 画像の場合、これは Load Delay を直接的に短縮します。
• 画像 CDN: 特化した画像 CDN は 2 重のメリットをもたらします。標準的な CDN と同様の距離の利点を提供すると同時に、オンザフライでの画像リサイズ、圧縮、AVIF や WebP のような最新フォーマットへの変換など、Resource Load Duration を短縮する多くの複雑な最適化を自動化します。
• 高度なプロトコル: 多くのモダン CDN は HTTP/3 を使用しており、これは TCP の代わりに QUIC を使用します。HTTP/3 は接続セットアップ時間を短縮し、Head-of-Line ブロッキングを軽減することで、全体的により高速で効率的なリソース配信をもたらします。

Speculation Rules による遅延の完全な排除

Speculation Rules API は、後続のナビゲーションにおける LCP の遅延を完全に排除することができます。

メカニズム

この API を使用すると、ユーザーが次に移動しそうな URL をブラウザに宣言的に通知することができます。これらのルールに基づいて、ブラウザはユーザーがリンクをクリックする前に、非表示のバックグラウンドタブでターゲットページを事前レンダリング (prerender) することを選択できます。

LCP への影響

ユーザーが事前レンダリングされたページへのリンクをクリックすると、ナビゲーションはほぼ瞬時に行われます。ページはすでに完全に読み込まれ、バックグラウンドでレンダリングされています。このナビゲーションでは、TTFB、Resource Load Delay、Resource Load Duration、Element Render Delay のすべてが、ユーザーの視点から事実上ほぼゼロに短縮されます。

使用例

eコマースのカテゴリーページにおいて、リスト内の最初のいくつかの商品詳細ページを事前レンダリングするために Speculation Rules を使用できます。ユーザーがこれらの商品のいずれかをクリックすると、ページが瞬時に表示されます。

ケーススタディの統合: 理論から実践へ

これらの最適化には、現実世界で測定可能な影響があります。

• ケース 1: プリロードの変革力: Load Delay が高いページで DebugBear が実施した実験は、劇的な例を提供しています。LCP 画像はリクエストチェーンの中に隠されており、Resource Load Delay が全体の LCP 時間の驚異的な 75% を占める原因となっていました。画像を早期に発見可能にするための単一の <link rel="preload"> ヒントを実装することで、Resource Load Delay は LCP 時間のわずか 2% に短縮されました。これは、単純なアーキテクチャの修正がいかにして大規模なパフォーマンスのボトルネックを解決できるかを示しています。
• ケース 2: 現実世界の loading="lazy" アンチパターン: Stack Overflow 上の開発者が、高速なネットワークにもかかわらず不可解な 1,430ms の Load Delay を伴うデスクトップの LCP を報告しました。原因をたどると、src 属性を透明なプレースホルダー SVG に置き換えることで、LCP 画像に誤って遅延読み込み (lazy loading) を適用している画像最適化プラグインでした。決定的な解決策は、LCP 要素に対するこの動作を無効にし、画像が発見され、優先して (eagerly) 読み込まれるようにすることでした。これは、サードパーティのツールが意図せず深刻な Load Delay を導入する可能性があることを示しています。
• ケース 3: fetchpriority のパフォーマンス向上: Google Flights のケーススタディは、明示的な優先順位付けの影響に関する明確な証拠を提供しています。ページの LCP の背景画像に fetchpriority="high" を追加しただけで、LCP スコアが 2.6 秒から 1.9 秒へと改善し、700ms の向上が見られました。これは、リソースが発見可能であっても、ネットワーク帯域幅の競争に勝つためには、その重要性が高いことをブラウザにシグナルで伝えることが重要なステップであることを実証しています。

Chrome DevTools でのネットワーク検査: Ctrl + Shift + I のショートカットを使用して Chrome の Developer Tools を開き、「Network」タブを選択してページをリロードします。読み込み順序を見てください。LCP リソースは、ダウンロードのためにキューに入れられた最初の項目の 1 つであるはずです。他の要素より遅れている場合は、Resource Load Delay の問題があります。以下は、Resource Load Delay が最適化されていないサイトの例です。

Real User Monitoring (RUM) データの使用: Real User Monitoring ツールは多くの場合、LCP アトリビューションデータをログに記録します。RUM を使用すると、LCP サブパーツの内訳を (時系列またはページ単位で) 視覚化でき、サイト全体またはページごとの LCP 要素の Load Delay の明確な全体像を把握できます。以下の例は、対応する Load Delay とともにグローバルな LCP の内訳を示しています。

Load Delay を改善する方法

Resource Load Delay は、リソースのダウンロード順序とタイミングが最適でない場合に発生します。本質的に、これを解決する直接的な方法は 2 つあります。LCP リソースの優先度を上げるか、LCP 以外のリソースの優先度を下げるかです。いくつかの一般的なパターンを見てみましょう。

LCP ヒント: プリロードスキャナを理解する: 最新のブラウザは、HTML を高速にスキャンし、リソースをダウンロードキューに入れるプリロードスキャナというメカニズムを使用しています。プリロードスキャナによってリソースをキューに入れられない場合は、より遅い DOM パーサーを待つ必要があり、遅延につながります。LCP リソースがプリロードスキャナによって発見可能であることを保証することは、Load Delay の短縮に大きな違いをもたらします。

1. HTML 構造を最適化する

ブラウザ (またはプリロードスキャナ) は HTML を上から下へ処理し、出現した順にリソースをキューに入れます。これは、LCP リソースが HTML の上部にあるほど、早くキューに入れられることを意味します。これを最適化するには、不要なリソースを HTML の上部から削除または遅延させます。

• 重要でない画像や非表示の画像の遅延読み込み: 言語別バージョンのサイトの国旗やメニュー内の画像などが、サイトの HTML の最上部に見つかることがあります。これらの画像は、LCP 要素ほど重要ではありません。これらの画像を遅延読み込み (lazy-load) することで、プリロードスキャナによってスキップされ、読み込みプロセスの少し後でキューに入れられるようになります。
• 重要でないスクリプトをページ下部に移動する: 初期読み込みにとって全く重要ではないスクリプトをページ下部に移動し、重要なリソースの遅延を防ぎます。例えば、チャットウィジェットなどです。インターネットの歴史上、ページが表示される前にチャットを必要とした人は一人もいません！

2. 背景画像を避ける

背景画像はプリロードスキャナからは見えないため、常に非常に遅い DOM パーサーによってキューに入れられることになります。この遅延を避けるには、代わりに通常の <img> タグを使用し、CSS プロパティの object-fit: cover と組み合わせて背景画像の外観を模倣します。このようにすれば、プリロードスキャナは直ちに画像を検出し、キューに入れることができます。

3. Fetch Priority を使用する

LCP 要素に fetchpriority="high" 属性を追加して、ブラウザに対して最初からこのリソースを優先すべきであることをヒントとして与えます。通常、画像はデフォルトで低または中程度の優先度で読み込まれます。レイアウトのフェーズ中に、ブラウザは可視要素を高い優先度にアップグレードします。fetchpriority="high" を設定することで、ダウンロードは直ちに高い優先度で開始され、LCP をより高速にすることができます。

fetchpriority は、要素の相対的な優先度を設定する (この場合、その画像は他の画像よりも相対的に重要であると設定する) ものであり、スタイルシートや非ブロッキングスクリプトなどよりも優先度を高くするわけではないため、通常、プリロードよりも侵入性が低く (そして効果も低く) なります。

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. プリロードを実装する

プリロードは、プリロードスキャナがファイルをキューに入れる順序を変更します。ページの head に <link rel="preload"> タグを配置して、LCP 画像などの重要なリソースを可能な限り早期にフェッチするようブラウザに指示します。プリロードは、HTML の後方で参照される (したがって後でキューに入れられる) リソースのプリロードや、(一部のスライダーのように) HTML でまだ参照されていないリソースのプリロードにも使用できます。最大限の効果を得るためには、ページの head 内で、スタイルシートの後、スクリプトの前にプリロードを配置することをお勧めします。

<link rel="preload" as="image" href="hero-image.jpg">

5. スタイルを最適化する

スタイルシートは通常、LCP リソースの前にキューに入れられますが、それには正当な理由があります。スタイルシートがなければ、ブラウザはページがどのように表示されるかを知ることができず、レンダリングフェーズを開始できません。しかし、CSS のサイズが過剰であったり、スタイルシートの数が多すぎたりすると、初期の帯域幅をめぐって LCP リソースと競合することになります。

6. 効率的な遅延読み込みを実装する

loading 属性は諸刃の剣になる可能性があります。LCP リソースには loading="eager" を使用し (またはブラウザのデフォルトが「eager」であるため属性を省略し)、画面外の画像には loading="lazy" を適用します。

• LCP 要素を Eager 読み込みする: LCP 要素が遅延読み込み (lazy-load) されると、プリロードスキャナによってキューに入れられず、はるかに後になって読み込まれるため、パフォーマンスに悪影響を与えます。
• ビューポート画像の遅延読み込み: 可視ビューポート内にあるものの LCP リソースではない画像には、loading="lazy" を使用してダウンロードキューを少し遅らせます。これにより、LCP リソースとの帯域幅の競合が軽減されます。
• 画面外の画像の遅延読み込みを避ける: 可視ビューポート内にない画像はそもそもダウンロードをトリガーしないため、帯域幅の競合を完全に排除します。

7. ブラウザのキャッシュ

ブラウザのキャッシュを使用すると、ユーザーのデバイスにすでにローカルに保存されているリソースのネットワークリクエストをスキップできます。最初のページビューを高速化することはありませんが、後続のページビューや再訪問者のロード時間を改善します。ブラウザのキャッシュが Resource Load Delay にどのように役立つかを以下に示します。

• 競合するリソースをキャッシュする: LCP リソース自体をキャッシュすることは素晴らしい戦略ですが、ブラウザのキャッシュは、スクリプト、スタイルシート、画像など、LCP リソースと競合したり遅延させたりする可能性のあるネットワークリソースを保存することで、LCP の Resource Load Delay を改善します。
• サーバーの負荷を減らす: キャッシュによりサーバーに送信されるリクエストの数が減少し、帯域幅が解放されサーバーの CPU サイクルが削減されるため、他のリソースのパフォーマンスが向上する可能性があります。

8. Speculation Rules を使用する

Speculation Rules により、ブラウザは予測されるユーザーのナビゲーションに基づいて、ウェブページをプリフェッチまたは事前レンダリング (prerender) できるようになります。プリフェッチは事実上 LCP の Time to First Byte サブパーツを排除しますが、Resource Load Delay には影響を与えません。事前レンダリングは、次のページを非表示のタブでレンダリングし、すべてのページリソースをダウンロードします。これにより、事前レンダリングされたページの LCP 内訳の例が示すように、LCP 要素のすべての Load Delay が排除されます。

9. クライアントサイドレンダリングを避ける

次のステップ: LCP の最適化を続ける

Resource Load Delay は、LCP の 4 つのフェーズの 1 つです。発見のレイテンシを最小限に抑えたら、これらのガイドを続けてご覧ください。

• LCP の問題を特定して修正する: すべての LCP の問題を見つけて修正するための完全な診断方法論。
• LCP 画像を最適化する: 画像フォーマットの選択、レスポンシブ画像、プリロード、画像に関するよくある間違い。
• Resource Load Duration: ブラウザがリソースを発見した後、圧縮、最新のフォーマット、CDN の最適化を通じてダウンロードにかかる時間を短縮します。
• Element Render Delay: リソースのダウンロード後、メインスレッドをクリアすることで、ブラウザがすぐにペイントできるようにします。