Core/Dash Dimension: Land

Dimension: Land (cc)

Land-dimensionen segmenterer dine RUM-data (Real User Monitoring) efter den besøgendes geografiske placering ved hjælp af ISO-landekoder. Performance er ikke ensartet over hele kloden. Et site, der loader på 1,5 sekunder i Holland, kan tage 4 sekunder i Brasilien og 6 sekunder i Indien. Land-dimensionen forvandler denne vage mistanke til et præcist, filtrerbart datasæt.

Hvis du betjener brugere internationalt, og du ikke filtrerer efter land, skjuler du din dårligste performance bag din bedste.

Hvorfor geografi bestemmer performance

Tre fysiske faktorer gør landet til den stærkeste indikator for TTFB og LCP:

• Serverafstand: Hver ekstra 5.000 km mellem brugeren og din origin-server tilføjer cirka 30-50 ms round-trip latency. Hvis din server står i Frankfurt, og din bruger er i Sydney, starter du med 250 ms+ uundgåelig fysik, før en eneste byte bliver serveret.
• Netværksinfrastruktur: Gennemsnitlige forbindelseshastigheder varierer enormt. Sydkorea har et gennemsnit på over 200 Mbps, mens mange afrikanske og sydasiatiske lande ligger under 20 Mbps. Dette påvirker direkte indlæsningstiden for billeder, scripts og skrifttyper.
• Enhedskvalitet: Regioner med lavere indkomst har en højere andel af budget-Android-enheder. Disse telefoner har langsommere CPU'er, mindre RAM og ældre browserversioner, hvilket forværrer netværksforsinkelser med processeringsforsinkelser, der puster INP op.

Ifølge 2025 Web Almanac er det kun 48 % af mobile origins globalt, der består alle tre Core Web Vitals. Men det tal dækker over en enorm geografisk varians. Korea fører med 39,3 % af origins, der består, mens lande med mindre udviklet infrastruktur falder langt under den globale median.

Aflæsning af landedata

Lande med høj performance

Lande som USA, Tyskland, Holland, Japan og Sydkorea viser typisk stærke Core Web Vitals. Disse regioner kombinerer hurtige netværk, nærliggende CDN edge nodes og moderne enhedsflåder. I CoreDash-data viser europæisk og østasiatisk trafik normalt p75 LCP-værdier mellem 1,5s og 2,2s.

Lande i mellemlaget

Brasilien, Mexico, Polen, Tyrkiet og Thailand ligger ofte i "trænger til forbedring"-området. Netværkshastighederne er anstændige, men CDN-dækningen kan være tyndere, og enhedsmixet inkluderer mere mid-range hardware. Forvent p75 LCP mellem 2,5s og 3,5s for disse regioner.

Udfordrende lande

Indien, Indonesien, Nigeria, Pakistan og Filippinerne repræsenterer nogle af de sværeste performance-miljøer. En høj andel af mobiltrafik (ofte 85 %+), langsommere gennemsnitsforbindelser og budgetenheder skaber en tredobbelt begrænsning. p75 LCP over 4s er almindeligt for sites uden aggressiv optimering til disse markeder.

Metrik-specifikke geografiske mønstre

TTFB og LCP

Disse er de metrikker, der påvirkes mest af geografi. Hvis din origin-server er i en enkelt region, og du ikke bruger et CDN, betaler hvert land uden for den region en latency-skat. Løsningen er infrastruktur: edge caching, CDN-distribution og regionale origin-servere. Ingen mængde frontend-optimering løser en 300 ms TTFB forårsaget af afstand.

INP

INP korrelerer mere med enhedskvalitet end netværkshastighed. Lande med ældre enhedsflåder (Indien, Sydøstasien, dele af Afrika) viser dårligere INP, selv på hurtige netværk, fordi flaskehalsen er CPU'en, ikke båndbredden. Filtrer efter Land + Enhedstype for at adskille netværkseffekten fra enhedseffekten.

CLS

CLS er stort set uafhængig af geografi. Layout shifts forårsages af rendering-logik, ikke netværksbetingelser. Hvis du ser CLS-varians fra land til land, bør du undersøge, om du serverer forskellige annoncenetværk, cookie-bannere eller tredjeparts-scripts pr. region.

Debugging-workflow

1. Sortér efter volumen og indvirkning (Impact): Åbn tabellen for Land-dimensionen og sortér efter indvirkning. Dit land med mest trafik og dårligst performance er din højeste prioritet. At fikse performance for 40 % af dine brugere slår at fikse det for 2 %.
2. Sammenlign med dit CDN-kort: Hvis et specifikt land har høj TTFB, bør du tjekke, om dit CDN har et Point of Presence (PoP) der. Manglende PoP'er betyder, at anmodninger dirigeres til den nærmeste tilgængelige edge, hvilket tilføjer latency.
3. Krydsreferér med Enhedstype: Et land med dårlig INP behøver muligvis ikke JavaScript-optimering. Det kan være nødvendigt for dig at servere lettere sider til de budgetenheder, der dominerer det marked. Filtrer efter Land + Enhedstype + Client Capability Score for at bekræfte.

Teknisk tommelfingerregel

• TTFB under 800 ms for hvert land, du målretter mod: Hvis et land overstiger dette, er det et infrastrukturproblem. Tilføj en CDN PoP eller regional cache.
• LCP under 2,5s for dine top 5 lande målt på trafik: Dette er de markeder, der afgør din samlede CrUX-score og søgerangering.
• Optimer ikke efter "globalt gennemsnit": Optimer til specifikke lande. En global p75 på 2,3s kan skjule det faktum, at Indien (dit næststørste marked) ligger på 4,1s.

Land-dimensionen er dit infrastruktur-auditværktøj. Det fortæller dig præcist, hvor dit CDN, din caching-strategi og din serverplacering svigter rigtige brugere.