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

ユーザーのダウンロード速度によってCore Web Vitalsをセグメント化し、どの帯域幅の階層がLCPを悪化させているかを見つけます。

無料トライアル

Trusted by market leaders · Client results

ディメンション：ネットワーク速度 (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 の実行、長いタスク、およびメインスレッドのブロックが、悪い INP スコアを引き起こします。接続が遅いと JavaScript バンドルの初期ダウンロードが遅れる可能性があり、ユーザーが最初にページを操作したときにスクリプトがまだ解析中である場合、間接的に INP を悪化させる可能性があります。しかし、スクリプトが読み込まれると、INP のパフォーマンスはネットワークではなく、デバイスの処理能力によって決定されます。

実際のところ、帯域幅の問題は、LCP リソースが発見された後にブラウザがそのダウンロードに費やした時間を測定する LCP のサブ部分である LCP Load Time に明確に現れます。CoreDash は LCP Load Time を個別に報告するため、遅いユーザーがネットワークを待っているのか、それとも他の何かを待っているのかを簡単に確認できます。

データの読み方

典型的なサイト全体の CoreDash トラフィックは、3つの帯域幅の階層に分かれます。各階層が何を表しているかを理解することは、修正の優先順位を付けるのに役立ちます。

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

CoreDash トラフィックの約 35% がこの階層に該当します。これには、良好な信号条件でのファイバー接続、ケーブルブロードバンド、および 5G モバイルユーザーが含まれます。2025年の平均 5G ダウンロード速度は約 184 Mbps であり、米国の固定ブロードバンドの平均は 214 Mbps に達しています。この階層のユーザーは、十分に最適化されたページでネットワーク主導の LCP 遅延を経験する可能性は低いです。ここで LCP スコアが悪い場合、問題は帯域幅ではなく、サーバーの応答時間、レンダリングブロックリソース、または LCP 要素の発見の遅延です。

中程度の速度：10 ～ 50 Mbps

CoreDash トラフィックの約 40% がこの範囲に収まります。この階層は、古いケーブル接続、平均的な信号条件での 4G LTE（一般的な 4G の実際の速度は 10 ～ 50 Mbps）、および一部の固定ワイヤレスユーザーをカバーしています。300 KB のヒーロー画像は、これらの速度での転送に 48 ～ 240 ミリ秒かかります。最適化されていない画像や複数のレンダリングブロックリソースを持つページは、この階層で LCP のしきい値を満たせなくなります。これは、画像フォーマットの選択（WebP、AVIF）や、fetchpriority="high" を使用した積極的なプリロードが測定可能な違いを生み出す階層です。

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

CoreDash トラフィックの約 25% は、10 Mbps 未満の接続から来ています。これには、3G モバイルユーザー、地方の固定接続、および信号が弱いか混雑したネットワーク条件の 4G ユーザーが含まれます。5 Mbps では、400 KB の画像は転送時間だけで 640 ミリ秒以上かかります。LCP 画像が積極的に圧縮され、ユーザーに近い CDN エッジノード経由で提供され、正しくプリロードされていない限り、この階層での LCP の失敗はほぼ確実です。歴史的にインフラストラクチャが遅い地域のユーザーにサービスを提供している場合は、dl と共に CoreDash の国（Country）ディメンションをチェックして、低速トラフィックが地理的に集中しているかどうかを確認してください。

デバッグのワークフロー

CoreDash で 10 Mbps 未満の階層にフィルタリングし、LCP Load Time をチェックします。LCP Load Time が不合格の LCP スコアの主な原因である場合、LCP リソースは低速接続に対して大きすぎます。画像をさらに圧縮し、AVIF フォーマットに切り替え、影響を受けるユーザーの近くにエッジノードを持つ CDN からリソースが提供されていることを確認します。
国（Country）ディメンションと相互参照します。 低速ユーザーが特定の国に集中している場合は、CDN がその地域で十分なカバレッジを持っているかどうかを確認します。200 ミリ秒離れた CDN エッジノードによってサービスを受ける 15 Mbps 接続のユーザーは、10 ミリ秒離れたノードによってサービスを受ける同じ速度のユーザーよりもはるかに悪いエクスペリエンスになります。
階層全体で INP と TTFB のスコアをチェックします。 低帯域幅の階層では INP が悪化するが、高帯域幅の階層では悪化しない場合、ユーザーが最初に操作したときに大規模な JavaScript バンドルがまだダウンロードされています。JavaScript を分割し、重要でないスクリプトを遅延させ、解析フェーズ中の INP への露出を減らすために、初期化中にメインスレッドに処理を譲る（yielding to the main thread）ことを検討してください。

エンジニアリングの経験則

5 Mbps の接続でも LCP Load Time を 200 ミリ秒未満に保つために、LCP 画像のファイルサイズを 100 KB 未満（AVIF または WebP）にすることを目標にします。
2.5 秒のしきい値内で 10 Mbps 接続で妥当な LCP を提供するには、ファーストビュー（above-the-fold）リソースの合計ページウェイトを 500 KB 未満に保つ必要があります。
ブラウザが最初に優先度の低いリソースで帯域幅を無駄にしないように、LCP 画像で fetchpriority="high" を使用し、ドキュメントの <head> でプリロードします。
すべての静的アセットを CDN から提供します。CoreDash の帯域幅の数値は、サーバーではなくクライアントの接続を測定します。サーバーが地理的に遠く、最初のバイトが到着する前に 300 ミリ秒のレイテンシを追加する場合、クライアントの高速接続は役に立ちません。
トラフィックの 15% 以上が 10 Mbps 未満の階層にあり、それらのユーザーの LCP が失敗している場合は、他の問題に対処する前に、画像の最適化と CDN カバレッジを優先度1（P1）の問題として扱います。