Core/Dash-dimensjon: Land

Dimensjon: Land (cc)

Land-dimensjonen segmenterer Real User Monitoring-dataene dine etter den besøkendes geografiske lokasjon ved hjelp av ISO-landskoder. Ytelsen er ikke lik over hele verden. Et nettsted som laster på 1,5 sekunder i Nederland, kan bruke 4 sekunder i Brasil og 6 sekunder i India. Land-dimensjonen gjør den diffuse mistanken om til et nøyaktig datasett som kan filtreres.

Hvis du betjener brukere internasjonalt og ikke filtrerer etter land, skjuler du den dårligste ytelsen din bak den beste.

Hvorfor geografi bestemmer ytelsen

Tre fysiske faktorer gjør land til den sterkeste prediktoren for TTFB og LCP:

• Serveravstand: Hver ekstra 5 000 km mellom brukeren og origin-serveren din legger to omtrent 30–50 ms med tur-retur-latens. Hvis serveren din står i Frankfurt og brukeren din er i Sydney, starter du med over 250 ms med uunngåelig fysikk før en eneste byte blir levert.
• Nettverksinfrastruktur: Gjennomsnittlige tilkoblingshastigheter varierer enormt. Sør-Korea har et snitt på over 200 Mbps, mens mange afrikanske og sørasiatiske land ligger under 20 Mbps. Dette påvirker lastetiden for bilder, skript og fonter direkte.
• Enhetskvalitet: Regioner med lavere inntektsnivå har en høyere andel rimelige Android-enheter. Disse telefonene har tregere prosessorer, mindre RAM og eldre nettleserversjoner, noe som forsterker nettverksforsinkelser med prosesseringsforsinkelser som blåser opp INP-en.

Ifølge 2025 Web Almanac består bare 48 % av mobil-origins alle tre Core Web Vitals globalt. Men det tallet skjuler enorme geografiske forskjeller. Korea leder med 39,3 % beståtte origins, mens land med mindre utbygd infrastruktur ligger langt under den globale medianen.

Slik leser du land-dataene

Land med høy ytelse

Land som USA, Tyskland, Nederland, Japan og Sør-Korea viser vanligvis gode Core Web Vitals. Disse regionene kombinerer raske nettverk, nære CDN-noder og moderne enhetsparker. I CoreDash-data viser europeisk og østasiatisk trafikk vanligvis p75 LCP-verdier mellom 1,5 s og 2,2 s.

Land i mellomklassen

Brasil, Mexico, Polen, Tyrkia og Thailand ligger ofte i området «trenger forbedring». Nettverkshastighetene er greie, men CDN-dekningen kan være tynnere, og enhetsmiksen inneholder mer maskinvare i mellomklassen. Forvent p75 LCP mellom 2,5 s og 3,5 s for disse regionene.

Utfordrende land

India, Indonesia, Nigeria, Pakistan og Filippinene representerer noen av de tøffeste ytelsesmiljøene. Høy andel mobiltrafikk (ofte over 85 %), tregere gjennomsnittlige tilkoblinger og rimelige enheter skaper en tredobbel begrensning. p75 LCP over 4 s er vanlig for nettsteder uten aggressiv optimalisering for disse markedene.

Metrikkspesifikke geografiske mønstre

TTFB og LCP

Dette er metrikkene som påvirkes mest av geografi. Hvis origin-serveren din er i én enkelt region og du ikke bruker et CDN, betaler alle land utenfor denne regionen en latens-skatt. Løsningen er infrastruktur: edge-caching, CDN-distribusjon og regionale origin-servere. Ingen mengde frontend-optimalisering kan fikse en TTFB på 300 ms forårsaket av avstand.

INP

INP korrelerer mer med enhetskvalitet enn med nettverkshastighet. Land med eldre enhetsparker (India, Sørøst-Asia, deler av Afrika) viser dårligere INP selv på raske nettverk, fordi flaskehalsen er CPU-en, ikke båndbredden. Filtrer etter Country + Device Type for å skille nettverkseffekten fra enhetseffekten.

CLS

CLS er stort sett uavhengig av geografi. Layout-skift forårsakes av renderingslogikk, ikke nettverksforhold. Hvis du ser CLS-variasjon per land, bør du undersøke om du leverer ulike annonsenettverk, cookie-bannere eller tredjepartsskript per region.

Arbeidsflyt for feilsøking

1. Sorter etter volum og Impact: Åpne Country-dimensjonstabellen og sorter etter Impact. Landet med mest trafikk og dårligst ytelse er din øverste prioritet. Å fikse ytelsen for 40 % av brukerne dine er langt bedre enn å fikse den for 2 %.
2. Sammenlign med CDN-kartet ditt: Hvis et spesifikt land har høy TTFB, sjekk om CDN-et ditt har et Point of Presence (PoP) der. Manglende PoP-er betyr at forespørsler rutes til nærmeste tilgjengelige edge, noe som øker latensen.
3. Kryssreferer med Device Type: Et land med dårlig INP trenger kanskje ikke JavaScript-optimalisering. Det kan være at du må levere lettere sider til de rimelige enhetene som dominerer dette markedet. Filtrer på Country + Device Type + Client Capability Score for å bekrefte dette.

Tommelfingerregler for utviklere

• TTFB under 800 ms for alle land du retter deg mot: Hvis et land overskrider dette, er det et infrastrukturproblem. Legg til en CDN-PoP eller et regionalt cache-lager.
• LCP under 2,5 s for de 5 største landene dine målt i trafikk: Dette er markedene som bestemmer den samlede CrUX-scoren og søkerangeringen din.
• Ikke optimaliser for «globalt gjennomsnitt»: Optimaliser for spesifikke land. En global p75 på 2,3 s kan skjule det faktum at India (ditt nest største marked) ligger på 4,1 s.

Land-dimensjonen er ditt verktøy for revisjon av infrastrukturen. Den forteller deg nøyaktig hvor CDN-et, cache-strategien og serverplasseringen din svikter virkelige brukere.