LCPのResource Load Durationの最適化

このガイドは、Core Web VitalsリソースセンターのLargest Contentful Paint (LCP)セクションの一部です。Resource Load Durationは、LCPの4つのフェーズのうち3番目にあたり、LCPリソースをネットワーク経由でダウンロードする時間を測定します。LCPの時間全体ではResource Load Delayが大きな割合を占めることが多いですが、良好な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を試してください）。ネットワークインスペクターに、リソースのダウンロードにかかった時間が表示されます。

プロのヒント: 大きなリクエスト行を有効にすると、LCPレイテンシ、転送サイズ、実際のサイズなどの詳細を確認できます。

Real User Monitoring（RUM）データの活用:

RUMツールは多くの場合、LCPのアトリビューションデータを記録します。Largest Contentful Paintのアトリビューションデータには、Resource Load Durationに関する情報が含まれています。このデータを使えば、時系列やページごとの読み込み時間の傾向をグラフ化し、速度低下の原因となっているページや要素を特定できます。

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

LCPのLoad Durationを改善する方法

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: リソースが新鮮（fresh）とみなされる最大期間を1年間（31,536,000秒）に設定します。
• immutable: リソースが将来にわたって変更されないことを示し、不要な再検証リクエストを防ぎます。

この戦略を安全に運用するには、コンテンツハッシュを含めたファイル名（例: hero-abc123.webp）を使用してください。画像が変更されるとファイル名も変わるため、キャッシュが自動的に破棄されます。

BrotliとGzipの圧縮比較

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

理想的な構成は、ビルドプロセス中に静的アセットを高圧縮レベル（レベル11など）のBrotliで事前圧縮しておき、Brotli非対応のクライアント向けにGzipをfallbackとして用意することです。Cloudflareを含む大半のCDNは、この処理を自動で行います。CDN設定の詳細については、パフォーマンス向上のためのCloudflare設定に関するガイドを参照してください。

HTTP/2とHTTP/3: 最新プロトコルのメリット

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

• HTTP/2は多重化（multiplexing）を導入し、単一のTCP接続上で複数のリクエストとレスポンスを同時に送信できるようにしました。これにより、1つの低速なリソースが他のすべてのリソースを遅延させるという、HTTP/1.1のヘッドオブラインブロッキング問題を解消しました。また、HTTP/2はヘッダー圧縮（HPACK）やサーバープッシュもサポートしています。
• HTTP/3はTCPをUDPベースのプロトコルであるQUICに置き換えることで、この仕組みをさらに進化させました。HTTP/3はTCPレベルのヘッドオブラインブロッキング（1つのパケット損失がすべてのストリームを停止させる問題）を解消し、0-RTT（再訪者向けのZero Round Trip Time再開）によって接続確立を高速化し、パケット損失への耐性も高めています。これらの改善は主にTime to First Byteを高速化しますが、Resource Load Durationの短縮にもつながります。

HTTP/3が有効になっているか確認するには、Ctrl+Shift+Iショートカットを使ってネットワークを調査します。「Network」タブを選択し、カラムヘッダーを右クリックして「Protocol」が有効になっていることを確認してください。ページを再読み込みしてプロトコルを確認します。HTTP/3が有効であれば、プロトコル欄に「h3」と表示されます。

Content Delivery Networks (CDN)

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

物理的な近さだけでなく、最新のCDNには読み込み時間を短縮するパフォーマンス上のメリットがいくつもあります:

• 画像の自動最適化: 多くのCDNは、画像の圧縮、リサイズ、フォーマット変換をオンザフライで行えます。たとえば、Cloudflare Polish、Imgix、Cloudinaryなどは、ブラウザのAcceptヘッダーに基づいてWebPやAVIFを自動的に配信できます。
• エッジキャッシュ: 静的リソースが世界中のエッジノードにキャッシュされるため、オリジンサーバーから取得する必要が完全になくなります。
• プロトコルの最適化: 大半のCDNは、サーバー側の設定を変更することなく、デフォルトでHTTP/2やHTTP/3、Brotli圧縮を有効にします。
• 接続の再利用: 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">

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

重要でないアセットを遅延読み込み（defer）またはlazy loadingすることで、初期ダウンロードを効率化します。すぐに画面に表示されない画像や動画、背景要素や二次的な要素の読み込みは後回しにしてください。まずは画面外のメディアにloading="lazy"を適用することから始めましょう。さらに重要度の低いスクリプトやアセットの読み込みを遅延させれば、帯域幅が解放され、重要リソースとの競合を削減して、ページの主要コンテンツをすばやく読み込んで表示できます。LCP画像には絶対にloading="lazy"を適用しないでください。スコアを悪化させる重大なアンチパターンです。

4. Speculation Rulesを設定する

Speculation Rulesを使用すると、ユーザーの遷移予測に基づいてブラウザがWebページをプリフェッチまたはプリレンダリングできるようになります。プリフェッチはLCPのサブパートであるTime to First Byteを事実上ゼロにしますが、Resource Load Durationには影響を与えません。一方、プリレンダリングは非表示のタブで次のページをレンダリングし、ページの全リソースをダウンロードします。以下のプリレンダリングされたページのLCP内訳の例に示すように、これによりLCP要素の読み込み時間の大半が解消されます。

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

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

• LCP問題の特定と改善: field dataとlabツールを使って、すべてのLCP問題を特定・修正するための完全な診断手順です。
• LCP画像の最適化: 画像フォーマットの選定、レスポンシブ画像、プリロード、画像最適化でよくあるミスについて解説します。
• Resource Load Delay: ブラウザにLCPリソースを可能な限り早期に検出させます。多くの場合、読み込み時間そのものよりも大きなボトルネックになります。
• Element Render Delay: リソースのダウンロード後、main threadを解放してブラウザが即座に描画できるようにします。