Core/Dash Dimension: Country
Isolate geographic performance bottlenecks by segmenting Core Web Vitals data per country.
Dimension: Country (cc)
The Country dimension segments your Real User Monitoring data by the visitor's geographic location using ISO country codes. Performance is not uniform across the globe. A site that loads in 1.5 seconds in the Netherlands may take 4 seconds in Brazil and 6 seconds in India. The Country dimension turns that vague suspicion into a precise, filterable dataset.
If you serve users internationally and you are not filtering by country, you are hiding your worst performance behind your best.

Why Geography Determines Performance
Three physical factors make country the strongest predictor of TTFB and LCP:
- Server distance: Every additional 5,000 km between the user and your origin server adds roughly 30-50ms of round-trip latency. If your server sits in Frankfurt and your user is in Sydney, you are starting with 250ms+ of unavoidable physics before a single byte is served.
- Network infrastructure: Average connection speeds vary wildly. South Korea averages over 200 Mbps, while many African and South Asian countries sit below 20 Mbps. This directly impacts Load Time for images, scripts, and fonts.
- Device quality: Lower-income regions have a higher proportion of budget Android devices. These phones have slower CPUs, less RAM, and older browser versions, compounding network delays with processing delays that inflate INP.
According to the 2025 Web Almanac, only 48% of mobile origins pass all three Core Web Vitals globally. But that number masks enormous geographic variance. Korea leads with 39.3% of origins passing, while countries with less developed infrastructure fall well below the global median.
Reading the Country Data
High-performing countries
Countries like the United States, Germany, the Netherlands, Japan, and South Korea typically show strong Core Web Vitals. These regions combine fast networks, nearby CDN edge nodes, and modern device fleets. In CoreDash data, European and East Asian traffic usually shows p75 LCP values between 1.5s and 2.2s.
Mid-tier countries
Brazil, Mexico, Poland, Turkey, and Thailand often sit in the "needs improvement" range. The network speeds are decent but CDN coverage may be thinner, and the device mix includes more mid-range hardware. Expect p75 LCP between 2.5s and 3.5s for these regions.
Challenging countries
India, Indonesia, Nigeria, Pakistan, and the Philippines represent some of the hardest performance environments. High mobile traffic share (often 85%+), slower average connections, and budget devices create a triple constraint. p75 LCP above 4s is common for sites without aggressive optimization for these markets.
Metric-Specific Geographic Patterns
TTFB and LCP
These are the metrics most affected by geography. If your origin server is in a single region and you do not use a CDN, every country outside that region pays a latency tax. The fix is infrastructure: edge caching, CDN distribution, and regional origin servers. No amount of frontend optimization fixes a 300ms TTFB caused by distance.
INP
INP correlates more with device quality than network speed. Countries with older device fleets (India, Southeast Asia, parts of Africa) show worse INP even on fast networks because the bottleneck is CPU, not bandwidth. Filter by Country + Device Type to separate the network effect from the device effect.
CLS
CLS is largely geography-independent. Layout shifts are caused by rendering logic, not network conditions. If you see CLS variance by country, investigate whether you are serving different ad networks, cookie banners, or third-party scripts per region.
Debugging Workflow
- Sort by volume and impact: Open the Country dimension table and sort by Impact. Your highest-traffic country with the worst performance is your top priority. Fixing performance for 40% of your users beats fixing it for 2%.
- Compare against your CDN map: If a specific country has high TTFB, check whether your CDN has a Point of Presence (PoP) there. Missing PoPs mean requests route to the nearest available edge, adding latency.
- Cross-reference with Device Type: A country with bad INP may not need JavaScript optimization. It may need you to serve lighter pages to the budget devices dominating that market. Filter Country + Device Type + Client Capability Score to confirm.
Engineering Rule of Thumb
- TTFB under 800ms for every country you target: If a country exceeds this, it is an infrastructure problem. Add a CDN PoP or regional cache.
- LCP under 2.5s for your top 5 countries by traffic: These are the markets that determine your aggregate CrUX score and search ranking.
- Do not optimize for "global average": Optimize for specific countries. A global p75 of 2.3s can hide the fact that India (your second-largest market) sits at 4.1s.
The Country dimension is your infrastructure audit tool. It tells you exactly where your CDN, caching strategy, and server placement are failing real users.