Core/Dashディメンション： ネットワーク速度

Core Web Vitalsをユーザーのダウンロード速度でセグメント化し、どの帯域幅ティアがLCPを悪化させているかを特定します。

無料トライアル

Trusted by market leaders · Client results

marktplaatserasmusmcwhowhatwearaleteiaperionharvarddpg mediamy work featured on web.devvpnsnvnina carekpnebaymonarchloopearplugshappyhorizonworkivasaturnnestlecomparefotocasaadevinta

ディメンション：ネットワーク速度 (dl)

dlディメンションは、ページ訪問時における各ユーザーの接続の有効ダウンロード帯域幅（Mbps）を報告します。CoreDashはブラウザのNetwork Information APIからこの値を取得し、訪問を帯域幅ティアにグループ化します。CoreDashのテーブルの各行は特定の速度バケットを表しているため、高速なブロードバンドユーザー、中速の接続、および低速またはモバイルの接続におけるCore Web Vitalsスコアを並べて比較できます。

帯域幅は、ページロードパフォーマンスを決定する2つのネットワーク特性の1つです。もう1つはレイテンシであり、サーバーへのラウンドトリップタイムを決定します。CoreDashのdlディメンションは帯域幅の変数を分離するため、接続速度の低下に伴ってCore Web Vitalsスコアがどの程度悪化しているか、という具体的な疑問に答えることができます。

coredash metric table urls

なぜネットワーク速度がCore Web Vitalsにとって重要なのか

ダウンロード帯域幅は、Largest Contentful Paintに直接的かつ測定可能な影響を与えます。LCPは、ほぼ常にヒーロー画像、大きな背景画像、または重いWebフォントによってトリガーされます。100 Mbpsの接続では、400 KBのヒーロー画像はわずか約32ミリ秒の転送時間で到達します。一方、5 Mbpsの接続では、レイテンシや処理のオーバーヘッドを考慮する前の転送時間だけで、同じ画像に640ミリ秒以上かかります。この差だけで、合格基準を満たしていたLCPスコアが「改善が必要」の領域に押し下げられる可能性があります。

Time to First Byteは帯域幅の影響をあまり受けません。TTFBは、転送されるバイト数ではなく、サーバーの処理時間とネットワークのラウンドトリップレイテンシによってほぼ決まります。サーバーの応答が遅ければ、どのような接続速度であっても遅くなります。CoreDashのすべての帯域幅ティアでTTFBが悪い場合、それはクライアント側の帯域幅の問題ではなく、サーバーまたはCDNの問題を示しています。

Interaction to Next Paintは、ほぼ完全にCPUバウンドです。INPは、ユーザー入力から次のビジュアルアップデートまでの時間を測定します。重いJavaScriptの実行、long task、およびmain threadのブロッキングが、INPスコアを悪化させます。低速な接続はJavaScriptバンドルの初期ダウンロードを遅らせる可能性があり、ユーザーが最初にページを操作したときにスクリプトがまだ解析中であれば、間接的にINPを悪化させる原因になります。しかし、スクリプトのロードが完了すれば、INPのパフォーマンスはネットワークではなくデバイスの処理能力によって決まります。

実際、帯域幅の問題はLCP Load Timeに明確に現れます。これは、LCPリソースが検出されてからブラウザがダウンロードを完了するまでの時間を測定する、LCPのサブパートです。CoreDashはLCP Load Timeを個別に報告するため、低速なユーザーがネットワークを待っているのか、それとも他の要因を待っているのかを簡単に確認できます。

データの読み方

一般的なサイトにおけるCoreDashのトラフィックは、3つの帯域幅ティアに分類されます。それぞれのティアが何を意味しているかを理解することで、修正の優先順位を決定しやすくなります。

高速ブロードバンド：50 Mbps以上

CoreDashトラフィックの約35%がこのティアに該当します。これには、光回線、ケーブルブロードバンド、および電波状況の良い5Gモバイルユーザーが含まれます。2025年の平均5Gダウンロード速度は約184 Mbpsであり、米国の固定ブロードバンドの平均は214 Mbpsに達しています。このティアのユーザーが、十分に最適化されたページでネットワーク起因のLCP遅延を経験することはほとんどありません。もしここでLCPスコアが悪い場合、問題は帯域幅ではなく、サーバー応答時間、render blockingなリソース、またはLCP要素の検出遅延にあります。

中速：10〜50 Mbps

CoreDashトラフィックの約40%がこの範囲に収まります。このティアは、旧式のケーブル接続、平均的な電波状況下の4G LTE（一般的な4Gの実測速度は10〜50 Mbps）、および一部の固定無線ユーザーを対象としています。これらの速度では、300 KBのヒーロー画像の転送に48〜240ミリ秒かかります。画像が未最適化であったり、複数のrender blockingなリソースが存在したりするページは、このティアでLCPのしきい値をクリアできなくなり始めます。これは、画像フォーマットの選択（WebP、AVIF）や、fetchpriority="high"を使用した積極的なプリロードが、測定可能な違いを生み出すティアです。

低速およびモバイル：10 Mbps未満

CoreDashトラフィックの約25%が10 Mbps未満の接続によるものです。これには、3Gモバイルユーザー、地方の固定回線、および電波状況の悪い場所や混雑したネットワークにいる4Gユーザーが含まれます。5 Mbpsでは、400 KBの画像転送に640ミリ秒以上を要します。LCP画像が強力に圧縮され、ユーザーに近いCDNエッジノードから配信され、適切にプリロードされていない限り、このティアでのLCPの失敗はほぼ確実です。インフラが歴史的に遅い地域に向けてサービスを提供している場合は、CoreDashのCountryディメンションをdlと並べて確認し、低速トラフィックが特定の国に集中しているかどうかを確認してください。

デバッグのワークフロー

  1. CoreDashで10 Mbps未満のティアにフィルタリングし、LCP Load Timeを確認します。LCP Load TimeがLCPスコア悪化の主な要因である場合、低速な接続に対してLCPリソースが大きすぎます。画像をさらに圧縮し、AVIFフォーマットに切り替え、影響を受けるユーザーに近いエッジノードを持つCDNからリソースが配信されていることを確認してください。
  2. Countryディメンションとクロスリファレンス（相互参照）します。 低速なユーザーが特定の国に集中している場合は、その地域でのCDNのカバー範囲が良好かどうかを確認してください。200 ms離れたCDNエッジノードから配信される15 Mbps接続のユーザーは、10 msの距離 of ノードから配信される同じ速度のユーザーよりも、はるかに悪い体験をすることになります。
  3. ティア間でINPとTTFBのスコアを確認します。 低速な帯域幅ティアでINPが悪化し、高速なティアでは悪化しない場合、ユーザーが最初に操作したときに巨大なJavaScriptバンドルがまだダウンロードされている可能性があります。JavaScriptを分割し、非クリティカルなスクリプトの実行を遅延させ、初期化中にyielding to the main threadを行うことを検討し、パースフェーズにおけるINPへの影響を抑えてください。

エンジニアリングにおける経験則

  • 5 Mbpsの接続環境でもLCP Load Timeを200ミリ秒未満に抑えるため、LCP画像のファイルサイズは100 KB未満（AVIFまたはWebP）を目指してください。
  • 10 Mbpsの接続で2.5秒のしきい値内に許容できるLCPを達成するため、ファーストビュー（above-the-fold）リソースの合計ページウェイトは500 KB未満に抑えてください。
  • ブラウザが優先度の低いリソースに先に帯域幅を浪費しないよう、LCP画像にfetchpriority="high"を使用し、ドキュメントの<head>内でプリロードしてください。
  • すべての静的アセットはCDNから配信してください。CoreDashの帯域幅の数値はクライアントの接続を測定したものであり、サーバーのものではありません。サーバーが地理的に遠く、ファーストバイトが届くまでに300ミリ秒のレイテンシが加わるようでは、クライアントの接続が高速でも意味がありません。
  • トラフィックの15%以上が10 Mbps未満のティアに属し、それらのユーザーでLCPが失敗している場合は、他の何よりも先に画像最適化とCDNのカバー範囲をP1の課題として対処してください。