CoreDash Dimensjon: Land

Dimensjon: Land (cc)

Dimensjonen Land segmenterer dine Real User Monitoring-data etter besøkendes geografiske plassering ved hjelp av ISO-landskoder. Ytelse er ikke ensartet over hele kloden. Et nettsted som lastes på 1,5 sekunder i Nederland, kan ta 4 sekunder i Brasil og 6 sekunder i India. Land-dimensjonen gjør den vage mistanken om til et presist, filtrerbart datasett.

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

Hvorfor geografi bestemmer ytelse

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

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

I følge 2025 Web Almanac er det bare 48 % av mobil-originene som består alle tre Core Web Vitals globalt. Men det tallet maskerer enorme geografiske forskjeller. Korea leder med 39,3 % beståtte originer, mens land med mindre utviklet infrastruktur faller godt under det globale mediannivået.

Lese landsdataene

Høyytelsesland

Land som USA, Tyskland, Nederland, Japan og Sør-Korea viser vanligvis sterke Core Web Vitals. Disse regionene kombinerer raske nettverk, nærliggende 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 midtsjiktet

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 inkluderer 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 hardeste ytelsesmiljøene. Høy andel mobiltrafikk (ofte 85 %+), tregere gjennomsnittlige tilkoblinger og budsjettenheter 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 din origin-server er i en enkelt region og du ikke bruker et CDN, betaler hvert land utenfor den regionen en forsinkelsesskatt. Løsningen er infrastruktur: edge-bufring, CDN-distribusjon og regionale origin-servere. Ingen mengde frontend-optimalisering fikser en 300 ms TTFB forårsaket av avstand.

INP

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

CLS

CLS er i stor grad geografisk uavhengig. Layoutforskyvninger er forårsaket av renderingslogikk, ikke nettverksforhold. Hvis du ser CLS-variasjon etter land, bør du undersøke om du serverer forskjellige annonsenettverk, informasjonskapsel-bannere eller tredjepartsskript per region.

Arbeidsflyt for feilsøking

1. Sorter etter volum og påvirkning: Åpne tabellen for Land-dimensjonen og sorter etter Påvirkning (Impact). Ditt land med høyest trafikk og dårligst ytelse er din høyeste prioritet. Å fikse ytelse for 40 % av brukerne dine slår å fikse det for 2 %.
2. Sammenlign mot ditt CDN-kart: Hvis et spesifikt land har høy TTFB, sjekk om ditt CDN har et Point of Presence (PoP) der. Manglende PoP-er betyr at forespørsler rutes til nærmeste tilgjengelige edge, noe som legger til forsinkelse.
3. Kryssreferanse med enhetstype: Et land med dårlig INP trenger kanskje ikke JavaScript-optimalisering. Det kan hende du må servere lettere sider til budsjettenhetene som dominerer det markedet. Filtrer Land + Enhetstype + Client Capability Score for å bekrefte.

Ingeniørmessig tommelfingerregel

• TTFB under 800 ms for hvert land du retter deg mot: Hvis et land overskrider dette, er det et infrastrukturproblem. Legg til en CDN-PoP eller regional cache.
• LCP under 2,5 s for dine topp 5 land etter trafikk: Dette er markedene som bestemmer din aggregerte CrUX-score og søkerangering.
• 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 infrastrukturrevisjon. Den forteller deg nøyaktig hvor ditt CDN, din bufringsstrategi og din serverplassering svikter ekte brukere.