LCPリソースの読み込み時間を最適化してください。

本ガイドはCore Web VitalsリソースセンターのLargest Contentful Paint (LCP)セクションの一部です。Resource Load Durationは4つの連続するLCPフェーズの3番目であり、ネットワーク経由でLCPリソースをダウンロードする時間を測定します。多くの場合、Resource Load DelayがLCP時間の大部分を占めますが、良好なLCPスコアを達成するにはダウンロード時間の最適化が依然として不可欠です。

LCPのResource Load Durationを最適化する

Largest Contentful Paint (LCP)は、オンラインでのユーザーエクスペリエンスを測定する3つのCore Web Vitalsパフォーマンス指標の1つです。LCPは、最大コンテンツ要素（画像、動画、またはテキストブロック）がviewportに表示されるまでの時間を捉えます。Resource Load DurationはLCPのサブパートであり、LCP要素のネットワークリソースを取得するために費やされた時間を示します。

LCPにおけるResource Load Durationとは

Resource Load Duration（単にLoad Durationと呼ばれることもあります）は、最終的にLCP要素となるネットワークリソース（例：画像）をブラウザがダウンロードするのに必要な時間を指します。画像と動画の場合、この時間は画像のダウンロード開始からブラウザがダウンロードを完了するまでです。テキストベースのLCP要素の場合、ロード時間は通常ゼロです。GoogleのLCP最適化ガイドではLCPを4つの連続するサブパートに分割しており、Resource Load Durationはリソースのバイトを実際にダウンロードするのに費やされる時間です。

Resource Load Durationは、ブラウザがLCPリソースのダウンロードを開始した瞬間からダウンロードが完了するまで測定されます。Resource Load Durationを決定する主な要因は4つあります。

• ファイルサイズ: ファイルが大きいほどダウンロード時間は長くなります。
• ネットワーク速度: 接続が遅いと当然ロード時間は延びます。
• サーバーの応答性: サーバーの応答遅延によりリソースの取得が遅くなります。
• 同時ダウンロード: 同時にダウンロードされるリソースは帯域幅を競合するため、ロード時間が増加します。

Resource Load Durationの検出方法

Resource Load Durationを特定して測定する効果的な方法が2つあります。

Chrome DevToolsのネットワーク検査: Ctrl + Shift + Iショートカットを使用してChromeのDeveloper Toolsを開き、「Network」タブを選択してページをリロードします。ネットワークリクエストからLCP要素を探します（LCP要素を知りたい場合は、Core Web Vitals Visualizerを試してください）。ネットワークインスペクターはリソースのダウンロードにかかった時間を示します。

Pro Tip: 大きなリクエスト行を有効にして、LCPレイテンシ、転送サイズ、実際のサイズなどの追加の詳細を確認してください。

Real User Monitoring (RUM) データを使用する:

RUMツールは多くの場合、LCPアトリビューションデータを記録します。Largest Contentful Paintのアトリビューションデータには、Resource Load Durationに関する情報が含まれています。このデータを使用すると、時間経過やページごとのロード時間の傾向をグラフ化し、速度を低下させているページや要素を特定できます。

ステップバイステップガイド: 正確なlabデータでの測定には、Performanceパネルでトレースを記録してください。LCP breakdownインサイトには、他の3つのサブパートと並んでResource Load Durationが表示されます。詳細な手順: Chrome DevTools PerformanceパネルでLCPを診断する。

LCPのロード時間を改善する方法

Resource Load Durationの問題は、リソースが大きすぎる場合や、最適でないネットワークパス経由で配信される場合に発生します。これに対処する主なアプローチは、データサイズの縮小とデータ配信の最適化の2つです。

1. ファイルサイズを最適化する

ファイルサイズを最適化することで、ネットワーク経由で送信されるバイト数が減少します。データが少ないほどダウンロード時間は短くなります。画像の最適化に関する完全なガイドについては、画像の最適化方法に関する記事を参照してください。

モダンな画像フォーマットを使用する

AVIFとWebPは画像圧縮の最良の選択肢です。複雑な写真の場合、AVIFはWebPよりも最大50%小さく圧縮でき、見た目の品質低下もありません。WebPはブラウザのサポートが広く、シンプルな画像に適しています。2025 Web Almanacによると、現在WebPは画像リクエストの40%以上で使用されています。一方、AVIFの採用は前年比でほぼ倍増しましたが、依然として10%未満にとどまっています。

適切な品質設定を選択する

WebPやAVIFなどのモダンな画像フォーマットでは、視覚的な劣化が目立つまでに品質を大幅に下げることができます。原則として、品質設定をWebPで75〜85、AVIFで60〜75にすると、通常の視聴距離ではオリジナルと同じに見えますが、ファイルサイズはわずか数分の一になります。最適な品質はコンテンツの種類（写真、イラスト、テキストの多い画像など）に依存するため、常に実際の画像でテストしてください。

Sharpを使用して画像圧縮を自動化する

ビルド時の画像最適化において、sharpライブラリはNode.jsエコシステムで最も高速で広く使用されているツールの1つです。次の例は、最適化された品質設定を使用して、画像をWebPおよびAVIFフォーマットに変換および圧縮する方法を示しています。

const sharp = require('sharp');

// 最適化された品質でWebPに変換する
await sharp('input.jpg')
  .resize(1200)  // 必要な最大幅にリサイズする
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// 最適化された品質でAVIFに変換する
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// レスポンシブな画像用に複数のサイズを生成する
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

このアプローチにより、モダンなフォーマットをサポートするレスポンシブな<picture>要素に必要なすべてのバリアントが生成されます。WordPressサイトの場合、ShortPixelやImagifyなどのプラグインがアップロード時にこの変換を自動的に処理します。

レスポンシブな画像

<picture>要素とsrcset属性は、画面に基づいて異なるサイズの画像を提供します。モバイルには小さいバージョン、大きな画面には高解像度のバージョンを提供します。設定例は次のとおりです。

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Description" width="800" height="450">
</picture>

正しい画像の寸法

レスポンシブな画像は解決策の一部にすぎません。レスポンシブであることが、正しいサイズであることを意味するわけではないからです。画像の寸法を表示サイズに合わせないのは、非常によく見られる間違いです。500pxの表示領域に2000px幅の画像を提供すると帯域幅が無駄になり、ロード時間を著しく遅くします。

フォントファイルの最適化

LCP要素がカスタムWebフォントでレンダリングされたテキストの場合、フォントファイルがLCPリソースになります。次の方法でフォントのロード時間を最適化してください。

• WOFF2フォーマットを使用する: WOFF2はWebフォントに最適な圧縮を提供し、通常はWOFFより30%小さく、TTFやOTFファイルよりも大幅に小さくなります。
• フォントをサブセット化する: サイトがラテン文字のみを使用する場合、フォントをサブセット化して未使用の文字セット（キリル文字、ギリシャ文字、CJK）を削除します。glyphhangerやpyftsubsetのようなツールでこれを自動化し、多くの場合フォントのファイルサイズを50%以上削減します。
• フォントのバリエーションを制限する: 各ウェイトとスタイル（レギュラー、ボールド、イタリック）は個別のファイルダウンロードになります。デザインで実際に使用するウェイトのみを含めてください。

2. ネットワークパフォーマンスを改善する

リソースサイズを最適化したら、次のステップはネットワーク速度を最大化するか、ネットワークを完全にバイパスすることです。

ブラウザキャッシュでネットワークの必要性をバイパスする

スキップされたネットワーク接続ほど高速なネットワーク接続はありません。ブラウザはローカルキャッシュから静的コンテンツ（画像、スクリプト、スタイルシート）を直接提供できます。正しいキャッシュ指示をブラウザに送信するようにサーバーを設定してください。

最も効果的な設定は、次のようなCache-Controlヘッダーを送信することです。

Cache-Control: public, max-age=31536000, immutable

• public: ブラウザと中間キャッシュの両方でリソースをキャッシュできるようにします。
• max-age=31536000: リソースが新鮮であると見なされる最大時間を1年（31,536,000秒）に設定します。
• immutable: リソースが時間とともに変化しないことを示し、不要な再検証リクエストを防ぎます。

この戦略を安全に機能させるには、コンテンツハッシュ化されたファイル名（例：hero-abc123.webp）を使用します。これにより、画像が変更されるとファイル名も変更され、キャッシュが自動的に破棄されます。

BrotliとGzip圧縮の比較

テキストベースのリソース（HTML、CSS、JavaScript、SVG）には、サーバー側の圧縮が不可欠です。Googleが開発したBrotliは、Gzipと同等の解凍速度を維持しながら、圧縮率で常にGzipを上回ります。以下の比較は、その違いを示しています。

理想的な設定は、ビルドプロセス中に高い圧縮レベル（例：レベル11）のBrotliで静的アセットを事前圧縮し、BrotliをサポートしていないクライアントへのフォールバックとしてGzipを使用することです。Cloudflareを含むほとんどのCDNは、これを自動的に処理します。CDN設定の詳細については、パフォーマンスのためのCloudflare設定のガイドを参照してください。

HTTP/2とHTTP/3: モダンプロトコルの利点

ブラウザが複数のリソースを同時にダウンロードする場合、配信プロトコルが最も重要になります。

• HTTP/2はマルチプレキシングを導入し、単一のTCP接続上で複数のリクエストとレスポンスを同時に送信できるようにしました。これにより、1つの遅いリソースが他のすべてのリソースを遅延させるHTTP/1.1のHead-of-Lineブロッキングの問題が排除されます。HTTP/2はヘッダー圧縮（HPACK）とサーバープッシュもサポートしています。
• HTTP/3はTCPをUDPベースのプロトコルであるQUICに置き換えることで、これをさらに進めています。HTTP/3はTCPレベルのHead-of-Lineブロッキング（1つの失われたパケットがすべてのストリームを停止させる）を排除し、0-RTT（再訪問者のためのゼロラウンドトリップタイム再開）を通じてより高速な接続確立を提供し、パケット損失をより適切に処理します。これらの改善は主にTime to First Byteを高速化しますが、Resource Load Durationも短縮します。

HTTP/3が有効になっているかを確認するには、Ctrl+Shift+Iショートカットでネットワークを検査します。Networkタブを選択し、ネットワーク列のヘッダーを右クリックして、「Protocol」が有効になっていることを確認してください。ページをリロードしてプロトコルを確認します。HTTP/3の場合、プロトコルは「h3」と表示されます。

Content Delivery Network (CDN)

CDNは、画像、CSS、JavaScriptなどの静的リソースをキャッシュし、ユーザーに近い場所から提供する分散サーバーのネットワークです。これによりデータの移動時間（ラウンドトリップ時間）が短縮され、Resource Load Durationに直接影響を与えます。

物理的な近さ以外にも、モダンなCDNはロード時間を短縮するいくつかのパフォーマンス上の利点を提供します。

• 画像の自動最適化: 多くのCDNは、画像をその場で圧縮、リサイズ、変換できます。たとえば、Cloudflare Polish、Imgix、Cloudinaryは、ブラウザのAcceptヘッダーに基づいてWebPまたはAVIFを自動的に提供できます。
• エッジキャッシュ: 静的リソースは世界中のエッジノードにキャッシュされるため、オリジンサーバーからフェッチする必要が完全になくなります。
• プロトコルの最適化: CDNは通常、サーバー側の設定変更を必要とせずに、Brotli圧縮とともにHTTP/2とHTTP/3をデフォルトで有効にします。
• 接続の再利用: CDNは単一のドメインからすべてのリソースを提供するため、ブラウザは単一の接続を再利用し、複数のDNSルックアップとTLSハンドシェイクのオーバーヘッドを排除します。

特化したImage CDNは、フォーマット変換、リサイズ、圧縮などの自動的かつリアルタイムな最適化を提供することで、これをさらに進めます。

リソースのセルフホスティング

重要かつ早期に必要なネットワークリソースは、デフォルトで常にオリジンサーバーでホストする必要があります。セルフホスティングにより、サードパーティのサーバーに接続する必要がなくなります。サードパーティへの接続は、追加のDNSルックアップ、SSLネゴシエーション、接続設定により大幅な遅延を引き起こします。セルフホスティングは、すでに開いている単一の接続の再利用を確実にし、個別の接続を確立するオーバーヘッドを削減します。セルフホストされたリソースは、圧縮とキャッシュポリシーの完全な制御も可能にします。

3. リソースの優先順位付けを最適化する

リソースサイズを削減しネットワークを最適化した後には、ネットワークの競合の問題もあります。遅い接続でブラウザが同時に複数のリソースをリクエストすると、帯域幅をめぐって競合します。リソースのダウンロードをスケジュールして、その競合を最小限に抑えてください。

重要なリソースを優先する

ヒーロー画像やファーストビューのCSSなどの不可欠なリソースに、fetchpriority="high"のフラグを付けます。これにより、ブラウザはこれらのアセットを最初にダウンロードするよう指示され、即時ロードを必要としないスクリプト、ウィジェット、サードパーティの要素によって処理が滞るのを防ぎます。これらの重要なリソースを優先することで、ユーザーが最も気にかけるコンテンツのロード時間が短縮されます。（発見の遅れを解決する）preloadと（ネットワーク競合を解決する）fetchpriority="high"の組み合わせは、LCPリソースを可能な限り早期かつ高速に取得するための最も強力な手法です。

<!-- 初期HTMLに表示されるLCP画像用 -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- 検出を改善するため -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

ネットワークの競合を減らす

重要でないアセットを遅延させるかlazy loadingすることで、初期ダウンロードを合理化します。すぐには表示されない画像や動画、背景や二次的な要素のロードを後回しにします。画面外のメディアにloading="lazy"を使用するのは良い出発点です。さらに他の重要でないスクリプトやアセットを遅延させると帯域幅が解放され、重要なリソースとの競合が減少して、ページのメインコンテンツの高速なロードと表示が維持されます。LCP画像には決してloading="lazy"を適用しないでください。これはスコアを悪化させる致命的なアンチパターンです。

4. Speculation Rulesを設定する

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

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

Resource Load Durationは4つのLCPフェーズの1つにすぎません。ダウンロード時間を最適化した後は、他のLCPフェーズに進んでください。

• LCPの問題の特定と修正: field dataとlabツールを使用してすべてのLCPの問題を発見し修正する完全な診断手法。
• LCP画像を最適化する: 画像フォーマットの選択、レスポンシブな画像、プリロード、および画像の最適化におけるよくある間違い。
• Resource Load Delay: ブラウザがLCPリソースを可能な限り早期に検出できるようにします。これは多くの場合、ロード時間自体よりも大きなボトルネックになります。
• Element Render Delay: リソースのダウンロード後、main threadをクリアしてブラウザが即座にペイントできるようにします。