Carichi il tuo sito web: è veloce. La tua squadra nella stessa città conferma: velocemente. Quindi un utente in Germania invia un'e-mail: "Il tuo sito impiega 12 secondi per caricarsi." Un cliente a Singapore twitta: "Il checkout continua a scadere."
Il tuo sito web non è lento ovunque. È lento da qualche parte e non sai dove o perché.
Hai trascorso mesi a ottimizzare il tuo sito web. I punteggi del faro sono alti. I Core Web Vitals sono verdi. Il tuo CDN è configurato. SSL è impostato correttamente.
Poi inizi a ricevere lamentele. Non da tutti, solo da regioni specifiche. Gli utenti in Brasile segnalano tempi di caricamento di 8 secondi. Gli utenti in India non possono completare il pagamento. Gli utenti in Australia dicono che il sito "sembra rotto".
Esegui il test dal tuo laptop: tutto funziona. Esegui un test di velocità: i risultati sembrano soddisfacenti. Il tuo APM mostra tempi di risposta salutari. La dashboard della tua CDN mostra tutti i bordi operativi.
Ma le denunce continuano ad arrivare. E non hai modo di vedere cosa stanno effettivamente sperimentando quegli utenti.
Questa è la realtà di gestire un sito Web con utenti internazionali. Il tuo sito web può essere lento in alcuni paesi ma veloce in altri e, a meno che non lo monitori da quei paesi, non lo saprai mai finché non ti costerà delle entrate.
Internet non è un'unica rete: è un mosaico di migliaia di sistemi autonomi, ciascuno con le proprie peculiarità, accordi di peering e modalità di fallimento.
Prima che un browser possa connettersi al tuo server, deve risolvere il tuo nome di dominio. Se il tuo provider DNS non dispone di nodi anycast vicino alla posizione di un utente, la sola risoluzione DNS può aggiungere 200–500 ms a ogni caricamento di pagina.
Esempio: un utente in Sud Africa che interroga un server DNS in Europa aggiunge più di 150 ms di tempo di andata e ritorno, prima ancora che venga avviata la prima richiesta HTTP.
BGP (Border Gateway Protocol) determina il modo in cui i pacchetti attraversano Internet. Un routing non ottimale può inviare il traffico su deviazioni bizzarre: i pacchetti dal Brasile potrebbero passare attraverso Miami, quindi Amsterdam, prima di raggiungere il tuo server di Londra.
Esempio: un utente a San Paolo che si connette al tuo server di Singapore potrebbe riscontrare una latenza di 400 ms a causa del routing attraverso la costa occidentale degli Stati Uniti anziché tramite cavi sottomarini diretti.
La tua CDN potrebbe avere 200 edge location, ma non sono tutte uguali. Alcuni bordi sono sovraccarichi. Alcuni hanno cache obsolete. Alcuni hanno problemi di connettività con la tua origine. La pagina di stato del CDN dice "operativo", ma i tuoi utenti a Giakarta sperimentano un TTFB di 5 secondi.
Esempio: il CDN edge di Manila fornisce istantaneamente i contenuti memorizzati nella cache. Edge a Ho Chi Minh City perde la cache e recupera ogni volta un'origine lenta.
Alcuni ISP limitano il traffico verso determinati intervalli IP o provider di hosting. Altri hanno punti di peering congestionati durante le ore di punta. Gli utenti di un ISP caricano il tuo sito in 1 secondo; gli utenti di un altro ISP nella stessa città aspettano 10 secondi.
Esempio: gli utenti di Reliance Jio in India riscontrano tempi di caricamento di 8 secondi. Gli utenti su Airtel nella stessa città sperimentano 1,2 secondi. Stesso sito web, stessa città, ISP diverso.
La realtà frustrante: tutti questi problemi sono invisibili dalla tua posizione. Il tuo server è veloce. Il tuo codice è ottimizzato. Il tuo CDN è configurato correttamente. Ma da qualche parte tra la tua infrastruttura e determinati utenti, qualcosa aggiunge secondi a ogni richiesta e puoi rilevarlo solo monitorando da dove si trovano effettivamente quegli utenti.
Gli strumenti di monitoraggio standard sono progettati per rilevare le interruzioni, non il degrado delle prestazioni regionali.
La maggior parte degli strumenti di monitoraggio della velocità dei siti Web effettua il controllo da 3 a 10 località, fortemente concentrate negli Stati Uniti e in Europa occidentale. Se i tuoi utenti si trovano nel Sud-Est asiatico, in America Latina, nel Medio Oriente o in Africa, stai volando alla cieca.
L'esecuzione di controlli sintetici dalle regioni AWS o GCP non è rappresentativa. La connettività cloud-to-cloud è spesso migliore rispetto ai percorsi di rete residenziali o aziendali. Il tuo monitoraggio mostra 200 ms; gli utenti reali sperimentano 2.000 ms.
Sapere che una pagina è "lenta" non è sufficiente. È DNS? Connessione TCP? Stretta di mano TLS? Tempo per il primo byte? Download di contenuti? Senza un'analisi della latenza, non è possibile diagnosticare se il problema riguarda il server, la CDN o il percorso di rete.
Quando si verifica un problema di routing o una perdita di pacchetti sul percorso, sono necessari i dati di traceroute e MTR per identificare dove i pacchetti vengono ritardati o eliminati. La maggior parte degli strumenti di monitoraggio non lo offre, quindi non puoi dimostrare al tuo CDN o al tuo provider di hosting esattamente dove si trova il problema.
Se monitori solo da 10 posizioni, visualizzerai meno del 10% dell'esperienza dei tuoi utenti. Il restante 90% potrebbe vivere una realtà completamente diversa.
Un sito web lento in alcuni paesi non è solo un piccolo inconveniente: è un problema aziendale.
Gli utenti che riscontrano tempi di caricamento lenti non si lamentano: se ne vanno. Un ritardo di 3 secondi aumenta la frequenza di rimbalzo del 32%. Un ritardo di 5 secondi lo aumenta del 90%. Questi utenti non compaiono mai nelle tue analisi perché non hanno mai finito di caricare il tuo codice di monitoraggio.
Se il caricamento della pagina di pagamento impiega 10 secondi in Germania, stai perdendo clienti tedeschi. Se il tuo modulo di registrazione scade in India, stai perdendo la seconda popolazione Internet più grande del mondo. Questi non sono casi limite: sono interi mercati che stai inavvertitamente ignorando.
Google esegue la scansione da più località globali. Se Googlebot riscontra tempi di caricamento lenti da determinate regioni, i tuoi Core Web Vitals ne risentono, il budget di scansione diminuisce e le classifiche scendono, non a livello globale, ma in mercati specifici. Vedi il calo del traffico e non hai idea del perché.
La voce si sparge. "Quel servizio è inutilizzabile in Asia." "Non preoccuparti, non funziona mai dall'Europa." I post sui forum, i tweet e i commenti sui siti di recensioni creano una percezione difficile da invertire, soprattutto quando non sai nemmeno che esiste il problema.
La diagnosi dei problemi di performance regionale richiede tre cose: copertura globale, profondità diagnostica e contesto storico.
Non monitorare solo dall'"Asia": monitora da Tokyo, Singapore, Mumbai, Giakarta, Sydney. Non limitatevi a monitorare dall'"Europa": monitorate da Francoforte, Londra, Amsterdam, Varsavia, Stoccolma. Ogni posizione rivela percorsi di rete diversi e potenziali colli di bottiglia.
Abbina le posizioni di monitoraggio a dove si trovano effettivamente i tuoi utenti.
Misura ogni fase: ricerca DNS, handshake TCP, negoziazione TLS, tempo per il primo byte, trasferimento di contenuti. Quando una pagina è lenta, saprai esattamente quale fase è colpevole e se si tratta di qualcosa che puoi risolvere o di un problema di rete a monte.
"Lento" è vago. "500ms DNS + 200ms TTFB" è utilizzabile.
Quando una regione è lenta, traceroute ti mostra esattamente quale hop di rete sta aggiungendo latenza. Il confronto storico ti dice se si tratta di un comportamento nuovo o è sempre stato così. Insieme, ti aiutano a determinare se si tratta di un problema temporaneo o di un problema di routing permanente.
I dati di Traceroute sono la tua prova quando si passa ai fornitori.
Un approccio passo passo per identificare il motivo per cui il tuo sito web è lento in alcuni paesi ma veloce in altri.
Estrai dati da Google Analytics, Cloudflare o dai log del tuo server. Identifica i 10 principali paesi e città da cui provengono i tuoi utenti. Queste sono le posizioni da cui devi monitorare.
Utilizza un servizio di monitoraggio che controlla da oltre 50 posizioni e fornisce tempistiche per fase (DNS, TCP, TLS, TTFB). Senza questa granularità, saprai che qualcosa è lento ma non cosa o perché.
Quando identifichi una regione lenta, esegui traceroute e MTR per vedere il percorso di rete. Cerca hop ad alta latenza, perdita di pacchetti o routing insolito. Questi dati ti dicono se il problema è il tuo CDN, la tua origine o la dorsale di Internet.
Verifica che la tua CDN stia effettivamente servendo contenuti dal bordo più vicino. Controlla i rapporti di riscontro della cache per regione. Un errore nella cache indica un recupero dell'origine lento. Alcuni bordi potrebbero essere configurati in modo errato o sovraccarichi.
Se la risoluzione DNS è lenta in alcune regioni, il tuo provider DNS potrebbe non avere nodi anycast nelle vicinanze. Prendi in considerazione un provider DNS con una migliore copertura globale o aggiungi un provider secondario per la ridondanza.
Quando contatti il tuo CDN, il provider di hosting o il servizio DNS per questioni regionali, porta con te dati di traceroute, suddivisioni temporali e grafici storici. "È lento a Singapore" viene ignorato. "Ecco 30 giorni di traceroute che mostrano un salto di 400 ms al tuo limite" entra in azione.
Configura avvisi per regioni specifiche che ti avvisano quando la latenza supera una soglia o la disponibilità diminuisce. Non hai bisogno di avvisi globali sui tempi di inattività: hai bisogno di avvisi di degrado specifici per regione.
Dedica 10 minuti ogni settimana all'analisi delle tendenze delle prestazioni regionali. Il lento degrado è invisibile in tempo reale ma evidente nei grafici storici. Individua i problemi prima che si aggravino.
Latency Global è stato creato appositamente per risolvere il problema "lento in alcuni paesi, veloce in altri". Monitoriamo da oltre 70 luoghi reali in 6 continenti: non solo regioni cloud, ma reali punti di osservazione della rete che riflettono ciò che sperimentano gli utenti reali.
Ogni controllo include la suddivisione completa della latenza: DNS, TCP, TLS, TTFB. Puoi eseguire traceroute e MTR su richiesta da qualsiasi luogo. I dati storici ti consentono di confrontare il rendimento attuale con i valori di riferimento. E costa $ 5 al mese, non i $ 200-$ 500 normalmente utilizzati dal monitoraggio globale aziendale.
Il monitoraggio globale è costoso da gestire: ecco perché la maggior parte degli strumenti limita le posizioni. Manteniamo i prezzi bassi servendo i clienti paganti, non mantenendo i livelli gratuiti.
Le cause più comuni sono: latenza della risoluzione DNS (il tuo provider DNS non dispone di server vicino a tali utenti), routing BGP non ottimale (pacchetti che seguono percorsi inefficienti), problemi di prestazioni del CDN edge (cache mancate o edge sovraccarichi) e limitazione o congestione dell'ISP regionale. L'unico modo per identificare quale sta causando il tuo problema specifico è monitorare da quelle posizioni con suddivisione completa della latenza e dati di traceroute.
I test una tantum forniscono un'istantanea, ma le prestazioni variano durante il giorno. È necessario un monitoraggio continuo per individuare problemi intermittenti, identificare modelli (ad esempio rallentamenti durante le ore di punta in regioni specifiche) e creare linee di base storiche. Un test di velocità gratuito inoltre non ti fornirà la ripartizione della latenza o i dati di traceroute per diagnosticare la causa principale.
"Operativo" non significa "ottimale". Gli edge possono essere operativi ma: avere bassi tassi di riscontro nella cache (forzando il recupero dell'origine), essere sovraccarichi durante le ore di punta, avere contenuti obsoleti o non configurati correttamente o avere scarsa connettività con determinati ISP. Il monitoraggio indipendente dall'esterno della tua CDN ti fornisce la verità che i dashboard della CDN non mostrano.
Guarda la ripartizione della latenza. Se il TTFB (Time to First Byte) è alto ma DNS/TCP/TLS sono normali, il problema è il tuo server di origine. Se l'handshake DNS o TCP è elevato, il problema è a monte del server. Traceroute ti mostra esattamente quale hop di rete sta aggiungendo latenza, che si tratti del tuo provider di hosting, di una rete di transito o di un ISP.
Potresti non essere in grado di risolvere direttamente i problemi a livello di ISP, ma puoi: (1) verificare che non si tratti della tua infrastruttura, (2) documentare il problema per i clienti interessati, (3) esplorare bordi CDN alternativi che instradano in modo diverso, (4) aggiungere server di origine in regioni con problemi persistenti o (5) contattare il team di rete del tuo provider di hosting con prove di traceroute per esplorare le modifiche del peering.
Per i siti Web di produzione con utenti internazionali, gli intervalli di controllo di 1 minuto sono ideali. Ciò rileva problemi intermittenti e fornisce punti dati sufficienti per un'analisi significativa delle tendenze. Intervalli di 5 minuti sono accettabili per le pagine meno critiche, ma perderai problemi di breve durata.
Smetti di indovinare perché il tuo sito web è lento in alcuni paesi. Aggiungi il tuo URL, seleziona le posizioni di monitoraggio e ottieni visibilità su ciò che effettivamente sperimentano i tuoi utenti globali, prima che ti inviino un'e-mail a riguardo.
$ 5/mese • Nessun contratto • Annulla in qualsiasi momento