Core/Dash Dimension: Country (国)

ディメンション: Country (cc)

Country (国) ディメンションは、ISO国コードを使用して、訪問者の地理的な場所ごとに RUM データをセグメント化します。パフォーマンスは世界中で均一ではありません。オランダで1.5秒で読み込まれるサイトが、ブラジルでは4秒、インドでは6秒かかる場合があります。Countryディメンションは、そのような漠然とした疑念を、フィルタリング可能な正確なデータセットに変換します。

国際的にユーザーへサービスを提供しているにもかかわらず、国別のフィルタリングを行っていない場合、最悪のパフォーマンスを最高のパフォーマンスの裏に隠してしまっていることになります。

地理的要因がパフォーマンスを決定づける理由

以下の3つの物理的要因により、国は TTFB および LCP を予測する最も強力な指標となります：

• サーバーとの距離: ユーザーとオリジンサーバーの距離が5,000km離れるごとに、およそ30〜50msのラウンドトリップ遅延が追加されます。サーバーがフランクフルトにあり、ユーザーがシドニーにいる場合、最初の1バイトが配信される前から250ms以上の物理的に回避不可能な遅延が発生します。
• ネットワークインフラ: 平均接続速度には大きなばらつきがあります。韓国は平均200Mbpsを超えますが、アフリカや南アジアの多くの国々は20Mbpsを下回ります。これは画像、スクリプト、フォントのロード時間に直接影響を与えます。
• デバイスの品質: 低所得地域では、低価格帯のAndroidデバイスの割合が高くなります。これらのスマートフォンはCPUが遅く、RAMが少なく、ブラウザのバージョンも古いため、ネットワークの遅延に処理遅延が重なり、INP が悪化します。

2025 Web Almanacによると、グローバルで3つの Core Web Vitals すべてに合格しているモバイルオリジンはわずか48%です。しかし、この数字は地理的な大きなばらつきを覆い隠しています。韓国は39.3%のオリジンが合格してリードしていますが、インフラの整備が遅れている国々は世界の中央値を大きく下回っています。

国別データの読み解き方

パフォーマンスが高い国

アメリカ、ドイツ、オランダ、日本、韓国などの国々は、一般的に優れた Core Web Vitals を示します。これらの地域は、高速なネットワーク、近接するCDNエッジノード、および最新のデバイス群を兼ね備えています。CoreDash のデータでは、ヨーロッパや東アジアのトラフィックにおけるp75の LCP は、通常1.5秒から2.2秒の間を示します。

中堅クラスの国

ブラジル、メキシコ、ポーランド、トルコ、タイなどは、「要改善（needs improvement）」の範囲に位置することがよくあります。ネットワーク速度は良好ですが、CDNのカバレッジが薄い場合があり、デバイス構成にはミッドレンジのハードウェアが多く含まれます。これらの地域では、p75の LCP は2.5秒から3.5秒になると想定してください。

課題の多い国

インド、インドネシア、ナイジェリア、パキスタン、フィリピンは、パフォーマンスの観点で最も過酷な環境の代表例です。モバイルトラフィックの高いシェア（多くの場合85%以上）、遅い平均接続速度、そして低価格帯デバイスが三重の制約を生み出します。これらの市場向けに積極的な最適化を行っていないサイトでは、p75の LCP が4秒を超えることが一般的です。

指標別の地理的パターン

TTFB と LCP

これらは地理的要因から最も影響を受ける指標です。オリジンサーバーが単一の地域にあり、CDNを使用していない場合、その地域外のすべての国がレイテンシのペナルティを受けます。解決策はインフラストラクチャにあります。つまり、エッジキャッシュ、CDN配信、および地域ごとのオリジンサーバーの構築です。物理的な距離によって引き起こされる300msの TTFB は、フロントエンドの最適化をどれだけ行っても解決できません。

INP

INP は、ネットワーク速度よりもデバイスの品質と強い相関があります。古いデバイス群が多い国（インド、東南アジア、アフリカの一部）では、ボトルネックが帯域幅ではなくCPUにあるため、高速なネットワーク上であっても INP が悪化します。ネットワークの影響とデバイスの影響を切り分けるには、「Country + Device Type」でフィルタリングしてください。

CLS

CLS は主に地理的要因に依存しません。レイアウトのズレは、ネットワークの状況ではなく、レンダリングのロジックによって引き起こされます。もし国によって CLS にばらつきが見られる場合は、地域ごとに異なる広告ネットワーク、Cookieバナー、またはサードパーティスクリプトを配信していないか調査してください。

デバッグのワークフロー

1. ボリュームとインパクトでソートする: Country ディメンションのテーブルを開き、インパクトでソートします。トラフィックが最も多く、かつパフォーマンスが最も悪い国が最優先事項です。ユーザーの40%に対してパフォーマンスを改善することは、2%のユーザーに対して改善するよりも効果的です。
2. CDNマップと比較する: 特定の国で TTFB が高い場合、そこにCDNのPoP（Point of Presence）が存在するかどうかを確認します。PoPがない場合、リクエストは利用可能な最も近いエッジにルーティングされ、レイテンシが増加します。
3. デバイスタイプと照らし合わせる: INP が悪い国には、JavaScript の最適化が必要ない場合もあります。その市場で支配的な低価格帯デバイス向けに、より軽量なページを配信することが求められている可能性があります。Country + Device Type + Client Capability Score でフィルタリングして確認してください。

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

• ターゲットとするすべての国で TTFB を800ms未満にする: これを超える国がある場合、それはインフラストラクチャの問題です。CDNのPoPまたはリージョンキャッシュを追加してください。
• トラフィック上位5か国で LCP を2.5秒未満にする: これらは、全体的なCrUXスコアと検索ランキングを決定づける市場です。
• 「グローバル平均」に向けて最適化しない: 特定の国に向けて最適化してください。グローバルのp75が2.3秒であっても、2番目に大きな市場であるインドのp75が4.1秒であるという事実が隠されている可能性があります。

Country ディメンションは、インフラストラクチャの監査ツールです。CDN、キャッシュ戦略、およびサーバーの配置が、実際のユーザーに対してどこで機能していないかを正確に教えてくれます。