Dimensione Core/Dash: Paese

Dimensione: Paese (cc)

La dimensione Paese segmenta i tuoi dati di Real User Monitoring in base alla posizione geografica del visitatore utilizzando i codici paese ISO. Le prestazioni non sono uniformi in tutto il mondo. Un sito che si carica in 1,5 secondi nei Paesi Bassi può impiegarne 4 in Brasile e 6 in India. La dimensione Paese trasforma questo vago sospetto in un set di dati preciso e filtrabile.

Se servi utenti a livello internazionale e non filtri per paese, stai nascondendo le tue prestazioni peggiori dietro a quelle migliori.

Perché la geografia determina le prestazioni

Tre fattori fisici rendono il paese il fattore predittivo più forte per TTFB e LCP:

• Distanza dal server: ogni 5.000 km aggiuntivi tra l'utente e il tuo server di origine aggiungono circa 30-50 ms di latenza di andata e ritorno. Se il tuo server si trova a Francoforte e il tuo utente è a Sydney, parti con oltre 250 ms di fisica inevitabile prima che venga servito un singolo byte.
• Infrastruttura di rete: le velocità medie di connessione variano enormemente. La Corea del Sud ha una media di oltre 200 Mbps, mentre molti paesi africani e dell'Asia meridionale sono al di sotto dei 20 Mbps. Questo influisce direttamente sul tempo di caricamento di immagini, script e font.
• Qualità dei dispositivi: le regioni a basso reddito hanno una percentuale maggiore di dispositivi Android economici. Questi telefoni hanno CPU più lente, meno RAM e versioni del browser più vecchie, aggravando i ritardi di rete con ritardi di elaborazione che gonfiano l'INP.

Secondo il Web Almanac 2025, solo il 48% delle origini mobili supera tutti e tre i Core Web Vitals. Ma questo numero nasconde un'enorme variabilità geografica. La Corea è in testa con il 39,3% di origini conformi, mentre i paesi con infrastrutture meno sviluppate scendono ben al di sotto della mediana globale.

Leggere i dati per paese

Paesi ad alte prestazioni

Paesi come Stati Uniti, Germania, Paesi Bassi, Giappone e Corea del Sud mostrano in genere Core Web Vitals solidi. Queste regioni combinano reti veloci, nodi edge CDN vicini e un parco dispositivi moderno. Nei dati di CoreDash, il traffico europeo e dell'Asia orientale mostra solitamente valori di p75 LCP compresi tra 1,5 e 2,2 secondi.

Paesi di fascia media

Brasile, Messico, Polonia, Turchia e Thailandia si trovano spesso nella fascia "necessita di miglioramenti". Le velocità di rete sono decenti, ma la copertura CDN può essere più limitata e il mix di dispositivi include più hardware di fascia media. Aspettati un p75 LCP compreso tra 2,5 e 3,5 secondi per queste regioni.

Paesi difficili

India, Indonesia, Nigeria, Pakistan e Filippine rappresentano alcuni degli ambienti prestazionali più difficili. L'elevata quota di traffico mobile (spesso superiore all'85%), le connessioni medie più lente e i dispositivi economici creano un triplo vincolo. Un p75 LCP superiore a 4 secondi è comune per i siti che non hanno un'ottimizzazione aggressiva per questi mercati.

Pattern geografici specifici per metrica

TTFB e LCP

Queste sono le metriche più influenzate dalla geografia. Se il tuo server di origine si trova in una singola regione e non usi una CDN, ogni paese al di fuori di quella regione paga una tassa di latenza. La soluzione è l'infrastruttura: edge caching, distribuzione tramite CDN e server di origine regionali. Nessuna ottimizzazione frontend può risolvere un TTFB di 300 ms causato dalla distanza.

INP

L'INP è correlato più alla qualità dei dispositivi che alla velocità della rete. I paesi con parchi dispositivi più vecchi (India, Sud-est asiatico, parti dell'Africa) mostrano un INP peggiore anche su reti veloci, perché il collo di bottiglia è la CPU, non la larghezza di banda. Filtra per Paese + Tipo di dispositivo per separare l'effetto rete dall'effetto dispositivo.

CLS

Il CLS è ampiamente indipendente dalla geografia. Gli spostamenti di layout sono causati dalla logica di rendering, non dalle condizioni di rete. Se noti variazioni del CLS per paese, verifica se stai servendo reti pubblicitarie, cookie banner o script di terze parti diversi a seconda della regione.

Flusso di lavoro per il debug

1. Ordina per volume e impatto: apri la tabella della dimensione Paese e ordina per Impatto. Il paese con il traffico più alto e le prestazioni peggiori è la tua priorità assoluta. Risolvere i problemi di prestazioni per il 40% dei tuoi utenti è meglio che risolverli per il 2%.
2. Confronta con la mappa della tua CDN: se un paese specifico mostra un TTFB alto, controlla se la tua CDN ha un Point of Presence (PoP) in quella regione. La mancanza di PoP fa sì che le richieste vengano instradate verso l'edge disponibile più vicino, aumentando la latenza.
3. Incrocia i dati con il Tipo di dispositivo: un paese con un pessimo INP potrebbe non aver bisogno di ottimizzazione JavaScript. Potrebbe essere necessario servire pagine più leggere ai dispositivi economici che dominano quel mercato. Filtra per Paese + Tipo di dispositivo + Client Capability Score per verificare.

Regole pratiche di ingegneria

• TTFB inferiore a 800 ms per ogni paese target: se un paese supera questo valore, si tratta di un problema infrastrutturale. Aggiungi un PoP della CDN o una cache regionale.
• LCP inferiore a 2,5 secondi per i primi 5 paesi per traffico: questi sono i mercati che determinano il tuo punteggio CrUX aggregato e il posizionamento di ricerca.
• Non ottimizzare per la "media globale": ottimizza per paesi specifici. Un p75 globale di 2,3 secondi può nascondere il fatto che l'India (il tuo secondo mercato più grande) si attesta a 4,1 secondi.

La dimensione Paese è il tuo strumento di audit dell'infrastruttura. Ti dice esattamente dove la tua CDN, la tua strategia di caching e il posizionamento dei server stanno penalizzando gli utenti reali.