Un buon tempo di risposta per un sito, misurato come time to first byte di una pagina HTML, è indicativamente sotto i 200 millisecondi per una pagina in cache e sotto i 600 millisecondi per una pagina dinamica. Le linee guida di web.dev di Google considerano buono un time to first byte di 0,8 secondi o meno. Oltre circa un secondo, i visitatori iniziano a percepire l’attesa prima che sullo schermo compaia qualcosa. Sono regole pratiche, non limiti rigidi: conta di più che il tempo di risposta sia stabile e che tu te ne accorga quando cambia.
Questa guida spiega cosa misura il tempo di risposta, in cosa differisce dal tempo di caricamento della pagina, perché il tuo monitor e il tuo browser riportano numeri diversi e come tenerlo sotto controllo per risolvere i rallentamenti prima che diventino interruzioni.
Il tempo di risposta non è il tempo di caricamento della pagina
I due termini vengono spesso confusi, ma misurano cose diverse.
Il tempo di risposta è quanto impiega il server a rispondere a una singola richiesta. Per un monitor indica di solito il tempo che va dall’invio della richiesta all’arrivo della risposta.
Il tempo di caricamento della pagina è quanto impiega il browser a mostrare una pagina utilizzabile. Include il tempo di risposta del documento HTML, più il download e l’esecuzione di CSS, JavaScript, font e immagini, spesso decine di richieste aggiuntive.
Una pagina può avere un tempo di risposta rapido e un caricamento lento, per esempio quando il server risponde in 150 millisecondi ma la pagina carica poi tre megabyte di JavaScript. I nostri consigli per un sito più veloce trattano questo lato front-end. Succede anche il contrario: un frontend ben ottimizzato non può nascondere un server che impiega quattro secondi a generare l’HTML. Il tempo di risposta è la parte che dipende dal tuo server e dal tuo hosting. Il caricamento della pagina è la parte che dipende dal tuo frontend. Contano entrambi e richiedono interventi diversi. Per il caricamento della pagina, il monitoraggio della velocità delle pagine di Uptimecheck esegue Google Lighthouse ogni giorno su mobile e desktop e ti avvisa quando il punteggio mobile di una pagina scende sotto la tua soglia.
Cosa include il time to first byte
Il time to first byte, o TTFB, è il tempo che va dall’inizio della richiesta all’arrivo del primo byte della risposta. È composto da diverse fasi:
Risoluzione DNS: trasformare il nome host in un indirizzo IP.
Connessione TCP: il viaggio di andata e ritorno per aprire una connessione.
Handshake TLS: l’accordo sulla cifratura per HTTPS.
Elaborazione sul server: l’applicazione viene eseguita, interroga il database e costruisce la risposta.
Primo byte in transito: l’inizio della risposta che torna indietro.
Puoi vedere ogni fase per il tuo sito con curl:
curl -o /dev/null -s -w “dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n” https://northwind.shop/
I valori sono cumulativi. Se tls è 0,12 secondi e ttfb è 0,95 secondi, il server ha impiegato circa 0,8 secondi a generare la pagina. È questo il numero su cui lavorare. Se le fasi DNS o di connessione sono lunghe, il problema è la distanza, la rete o il DNS, non la tua applicazione. Uptimecheck suddivide il tempo di risposta di ogni controllo nelle stesse fasi: DNS, connessione, TLS, server e download.
Perché monitor e browser riportano numeri diversi
È normale che il tuo monitor di uptime, gli strumenti per sviluppatori del browser e uno strumento di test delle prestazioni mostrino tempi di risposta diversi per la stessa pagina. I motivi più comuni:
Posizione. Un controllo da un altro continente aggiunge viaggi di andata e ritorno a ogni fase vista sopra. Un server a Stoccolma risponde più in fretta a un visitatore di Stoccolma che a un controllo dalla costa est degli Stati Uniti.
Riutilizzo delle connessioni. Il browser tiene aperte le connessioni e le riutilizza. Un controllo di monitoraggio spesso apre ogni volta una nuova connessione, quindi paga DNS, TCP e TLS a ogni richiesta.
Cache. Il browser potrebbe avere in cache la pagina o parte di essa, e una CDN potrebbe servire una copia in cache ad alcune regioni e non ad altre.
Cosa viene misurato. Uno strumento riporta il TTFB, un altro il tempo totale per scaricare tutta la risposta, un terzo il caricamento dell’intera pagina.
Cookie e login. Gli utenti autenticati spesso scavalcano la cache delle pagine, quindi le loro risposte sono più lente di un controllo anonimo.
Nessuno di questi fattori rende sbagliato un numero. L’importante è confrontare dati omogenei: lo stesso controllo, dalla stessa posizione, nel tempo. Un monitor che misura la stessa richiesta ogni minuto ti dà una baseline coerente, e sono le variazioni rispetto a quella baseline a dirti quando intervenire.
Obiettivi ragionevoli, come regole pratiche
Gli intervalli qui sotto sono regole pratiche per la risposta del server a una pagina HTML o a una chiamata API, misurata da una posizione abbastanza vicina al server. Sono un punto di partenza per la tua baseline, non uno standard.
Tipo di rispostaBuonoDa approfondirePagina in cache o file statico tramite CDNsotto 100–200 msoltre 400 msPagina dinamica (CMS, e-commerce, app)sotto 300–600 msoltre 1 sEndpoint API di lettura semplicesotto 100–300 msoltre 800 msRicerca, report, query pesantisotto 1–2 soltre 3 s
Due note per leggere la tabella. Primo, aggiungi la distanza di rete: un controllo da un altro continente può aggiungere qualche centinaio di millisecondi, e non è qualcosa che la tua applicazione possa risolvere. Secondo, la colonna che conta di più è quella che stabilisci tu. Se il tuo checkout di solito risponde in 350 ms e oggi risponde in 900 ms, qualcosa è cambiato, anche se 900 ms sulla carta sembrano ancora accettabili.
Cosa rallenta i tempi di risposta
Quando il tempo di risposta aumenta, la causa è quasi sempre una di queste:
Query lente sul database: un indice mancante, una query che cresce con le dimensioni di una tabella o un plugin che esegue decine di query per pagina.
Nessuna cache di pagina o di oggetti: ogni richiesta ricostruisce da zero la stessa pagina.
Chiamate esterne durante la richiesta: API di pagamento, spedizione, ricerca o analytics chiamate in modo sincrono mentre il visitatore aspetta.
Troppo pochi worker: le richieste si mettono in coda quando i worker di PHP-FPM, Node o dell’application server sono tutti occupati.
Risorse sotto pressione: CPU al limite, memoria in swap o I/O del disco saturato da backup o scritture di log.
Cold start: funzioni serverless e container scalati a zero impiegano tempo ad avviarsi alla prima richiesta.
Distanza: visitatori lontani dal server senza una CDN nel mezzo.
Le code sono il motivo per cui il tempo di risposta conta per la disponibilità. Quando le risposte rallentano, ogni richiesta occupa un worker più a lungo, il pool si riempie e le nuove richieste aspettano o vengono rifiutate. Un rallentamento che inizia con mezzo secondo in più può finire con un errore 503 Service Unavailable al successivo picco di traffico.
Segui l’andamento, non un singolo controllo
Un singolo controllo lento significa poco. Un disturbo di rete, una pausa della garbage collection o un cache miss possono rallentare una richiesta. Quello che ti dice che c’è qualcosa che non va è uno schema ricorrente:
Un salto improvviso: il tempo di risposta aumenta dopo un deploy, l’aggiornamento di un plugin o un cambio di hosting, e resta alto.
Una crescita lenta: il tempo di risposta aumenta un po’ ogni settimana man mano che cresce una tabella o un log.
Uno schema giornaliero: il tempo di risposta ha un picco alla stessa ora ogni giorno, spesso per un backup, un’importazione o un cron job che compete per le risorse.
Una differenza tra regioni: una regione è lenta mentre un’altra va bene, il che indica una CDN, l’instradamento o il DNS più che il server.
Uptimecheck salva il tempo di risposta di ogni controllo per ciascun monitor di uptime e monitor API, lo mostra in grafici con mediana e 95° percentile, e i report via email settimanali e mensili includono il tempo di risposta medio accanto all’uptime. È questo storico che ti permette di vedere un salto il giorno stesso in cui avviene, invece che settimane dopo.
Ricevi avvisi sui rallentamenti prolungati
Inviare un avviso per ogni controllo lento crea rumore, e gli avvisi rumorosi vengono ignorati. Invia avvisi per i rallentamenti che durano. Un approccio pratico:
Misura la baseline di ogni endpoint importante per una o due settimane.
Imposta la soglia di avviso ben al di sopra della variazione normale, per esempio due o tre volte il tempo di risposta abituale.
Invia l’avviso solo quando il rallentamento persiste per diversi controlli o minuti consecutivi.
Invia gli avvisi di lentezza a un canale del team e riserva le notifiche push sul telefono ai guasti veri e propri.
Imposta un timeout su ogni controllo. Una risposta che impiega 30 secondi è un guasto per un visitatore, qualunque sia il codice di stato.
In Uptimecheck imposti un limite di risposta lenta per ogni monitor. Quando tre controlli di fila sono più lenti del limite, ricevi un avviso di lentezza, e un altro quando il monitor torna veloce. Il tempo di lentezza non conta come downtime.
Gli stessi principi valgono per ogni avviso che configuri. La nostra guida su come ridurre i falsi allarmi nel monitoraggio uptime approfondisce conferme e soglie, e come scegliere le soglie di avviso per i server spiega come impostare i limiti per CPU, memoria e disco. Quando i tempi di risposta salgono, il monitoraggio dei server accanto ai controlli di uptime mostra se la causa è il server, così non devi tirare a indovinare tra database, rete e codice.
Checklist per il tempo di risposta
Misura il TTFB delle pagine e degli endpoint chiave con curl, da una posizione vicina al server.
Monitora le stesse pagine ogni minuto e conserva lo storico.
Annota una baseline per ogni endpoint e confrontati con quella, non con un numero generico.
Indaga sui salti dopo i deploy e sulle crescite lente nell’arco di settimane.
Metti in cache ciò che puoi, correggi le query lente e sposta le chiamate esterne fuori dalla richiesta.
Invia avvisi per i rallentamenti prolungati e per i timeout, non per singoli controlli lenti.
Riepilogo
Un buon tempo di risposta è basso per il tipo di pagina, vicino alla tua baseline e stabile nel tempo. Come regola pratica, punta a qualche centinaio di millisecondi per le pagine dinamiche e a molto meno per quelle in cache. Misuralo sempre allo stesso modo, segui l’andamento e considera un aumento prolungato come un segnale d’allarme precoce, perché la pagina lenta di oggi è spesso l’interruzione di domani.
Uptimecheck registra i tempi di risposta a ogni controllo, così vedi i rallentamenti oltre alle interruzioni. Provalo gratis per 14 giorni, senza carta di credito.