LCP Resource Load Durationの最適化

LCP Resource Load Durationの最適化

Largest Contentful Paint (LCP)は、オンラインのuser experienceを測定する3つのCore Web Vitalsパフォーマンス指標の1つです。LCPは、最大のコンテンツ要素（画像、動画、またはテキストブロック）がビューポート内に表示されるまでの時間を測定します。Resource load DurationはLCPのサブパートであり、LCP要素のネットワークリソースの取得にどれだけの時間が費やされているかを示します。  LCPのresource load durationの側面を深く掘り下げ、その影響と最適化戦略を探りましょう。

LCPにおけるResource Load Durationとは？

Resource Load Duration（Load Durationとも呼ばれる）は、ブラウザが最終的にLCP要素となるネットワークリソース（例：画像）をダウンロードするのに必要な時間を指します。画像や動画の場合、この時間は画像のダウンロードが開始されてからブラウザがダウンロードを完了するまでの期間です。テキストベースのLCP要素の場合、load durationは通常ゼロです。

Resource Load Durationは、ブラウザがLCPリソースのダウンロードを開始した瞬間からダウンロードが完了するまでの時間として測定されます。この測定は、ユーザーがウェブページのメインコンテンツをどれだけ早く見て操作できるかに直接影響するため、非常に重要です。resource load durationは以下のような複数の要因に影響されます：

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

Resource Load Durationの検出方法

resource load durationを特定し測定するには、2つの効果的な方法があります：

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

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

Real User Monitoring (RUM)データの活用: 

RUMツールは多くの場合、 LCP attribution dataを記録します。 Largest contentful Paintのattribution データには、resource load delayに関する情報が含まれています。 このデータにより、load durationの傾向を時間軸やページ別に可視化でき、サイト全体の読み込み時間を明確に把握できます。これらのパターンを分析することで、読み込み時間を遅くしている要素を特定し、より高速でスムーズなパフォーマンスのための改善機会を発見できます。

LCP Load Durationを改善する方法

リソースの読み込み遅延は、リソースが最適でない順序やサイズでダウンロードされる場合に発生します。これに対処する主な2つのアプローチ：データサイズの削減またはデータ配信の最適化。LCPのresource load durationを改善するための効果的なテクニックとパターンを紹介します：

1. ファイルサイズの最適化：

ファイルサイズの最適化により、ネットワーク経由で送信するバイト数を削減します。データ量が少なければ、通常はダウンロード時間も短くなります。

最新の画像フォーマットを使用: AVIFとWebPは圧縮の最先端をリードしています。特にAVIFは広範な圧縮機能を提供し、WebPと比較してファイルサイズを最大50%削減できることが多く、画質を犠牲にすることなく複雑な写真に最適です。一方、WebPはより幅広いブラウザとの強力な互換性を維持しており、特にシンプルな画像に効果的です。

レスポンシブ画像：<picture>要素とsrcset属性により、画面サイズに基づいてカスタマイズされた画像を提供でき、モバイル向けには小さい画像バージョン、大画面向けには高解像度バージョンを配信できます。以下は設定例です：

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

正確な画像サイズ：レスポンシブ画像は解決策の一部にすぎません。レスポンシブであることは適切なサイズであることを意味しないからです。画像の寸法を表示サイズに合わせることは、私が見る最も一般的なミスの1つです。500pxの表示エリアに2000px幅の画像を配信すると、帯域幅が無駄になり、読み込み時間が著しく遅くなる可能性があります。

2. ネットワークパフォーマンスの改善： 

リソースのネットワークサイズが最適化されたら、次のステップはネットワーク速度の最大化、あるいはネットワークを完全にバイパスすることです。これは以下の方法で実現できます：

ネットワークの必要性をバイパス： スキップされたネットワーク接続より速いネットワーク接続はありません。ブラウザには、画像、スクリプト、スタイルシートなどの静的（不変の）コンテンツをローカルブラウザキャッシュから直接配信するオプションがあります。サーバーがブラウザに正しいキャッシュ指示を送信するように設定してください。例えばexiresヘッダーを使用します。

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

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

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

HTTP/3：最新のHTTP/3プロトコルは、従来のTCPよりもレイテンシを削減し、パケットロスをより効率的に処理することで、ネットワークパフォーマンスを改善できます。（HTTP/3には、特にTime to Fist Byteに関して他にも多くの利点があります） 

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

リソースのセルフホスティング：重要なネットワークリソースや初期に必要なネットワークリソースは、デフォルトでオリジンサーバーにホストすべきです。  セルフホスティングにより、サードパーティサーバーへの接続が不要になり、追加のDNSルックアップ、SSLネゴシエーション、接続セットアップによる大幅な遅延を回避できます。セルフホスティングは、単一の既に開いている接続の再利用を保証し、別々の接続を確立するオーバーヘッドを削減します。セルフホストされたリソースは、圧縮とキャッシュポリシーの完全な制御も可能にします。

CDNの活用：Content Delivery Network (CDN)は、画像、CSS、JavaScriptなどの静的リソースをユーザーに近い場所からキャッシュして配信する分散サーバーのネットワークです。これにより、データの移動時間（ラウンドトリップタイム）が短縮され、Resource Load Durationに直接影響します。それに加えて、多くのCDNは画像圧縮、優れたネットワーク構成（HTTP/3 & 0-RTTなど）など、さらに多くの利点を提供します。 専門的な画像CDNは、フォーマット変換、リサイズ、圧縮などの自動的なリアルタイム最適化を提供することで、これをさらに推し進めることができます。

3. リソース優先度の最適化

リソースサイズの削減とネットワークの最適化の後、ネットワーク競合の問題もあります。ネットワーク条件が悪い状態で複数のリソースが同時にリクエストされると、リソースのダウンロード時間が大幅に遅くなる可能性があります。そのため、リソースのダウンロードをスケジューリングしてネットワーク競合を最小限に抑えることが重要です。

重要なリソースの優先順位付け：ヒーロー画像やアバブザフォールドのCSSなどの重要なリソースに、fetchpriority="high"をフラグ付けしましょう。これにより、ブラウザにこれらのアセットを最初にダウンロードするよう指示し、即時読み込みが不要なスクリプト、ウィジェット、サードパーティ要素によって遅延することを防ぎます。これらの重要なリソースを優先することで、ユーザーが最も重視するコンテンツの読み込み時間を削減できます。 preload（遅延発見を解決するため）とfetchpriority="high"（ネットワーク競合を解決するため）の組み合わせは、LCPリソースを可能な限り早く、速く取得するための最も強力なテクニックです。

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

ネットワーク競合の削減：重要でないアセットの遅延読み込みにより、初期ダウンロードを効率化します。すぐに表示されない画像や動画、およびバックグラウンドやセカンダリ要素の読み込みを延期します。オフスクリーンメディアにloading="lazy"を使用するのは良い出発点ですが、他の重要でないスクリプトやアセットをさらに遅延させることで、帯域幅を解放し、重要なリソースとの競合を減らし、ページのメインコンテンツを素早く読み込んで表示できるようにします。 LCP画像にloading="lazy"を適用しないでください。これはスコアを悪化させる重大なアンチパターンです。

4. Speculation Rulesの設定

Speculation Rulesは、予測されるユーザーナビゲーションに基づいて、ブラウザがウェブページをprefetchまたはprerenderできるようにします。Prefetchingは、LCPのTime to First Byteサブパートを効果的に排除し、resource load durationには影響しません。Prerenderingは次のページを非表示タブでレンダリングし、すべてのページリソースをダウンロードします。  これにより、このプリレンダリングされたページのLCPブレークダウン例に示されているように、LCP要素のload durationのほとんどが排除されます。