In btlabs Core, un tempo di risposta di un sito web inferiore a 200 ms si riferisce al Time to First Byte (TTFB) : il tempo che intercorre tra l'inizio della navigazione e l'arrivo del primo byte di risposta. Questo valore non descrive il tempo di caricamento totale né il punteggio Lighthouse. Tuttavia, senza dati grezzi sull'URL di test, la regione di test, lo stato della cache, la mediana e il p95, "meno di 200 ms" non rappresenta una garanzia di prestazioni generalmente verificabile.
Questa distinzione è importante. In oltre 20 anni di sviluppo web, ho spesso visto PMI presentare un singolo parametro impressionante senza spiegare la misurazione o le condizioni del test. Un punteggio elevato potrebbe essere accurato, ma rivela comunque poco sulla reattività quotidiana del sito web.
Per fornire un'affermazione affidabile sulla velocità di un sito web sono necessari una metrica chiara, un protocollo di misurazione aperto e risultati riproducibili nelle stesse condizioni.
Cosa misura effettivamente il tempo di risposta del sito web
Secondo web.dev, il Time to First Byte (TTFB) misura il tempo che intercorre tra l'inizio della navigazione e l'arrivo del primo byte di risposta. Il TTFB comprende diverse fasi:
- possibili reindirizzamenti,
- l'inizio di un lavoratore dei servizi, se esiste,
- Risoluzione DNS,
- la creazione della connessione e la negoziazione TLS,
- la trasmissione della richiesta e l'elaborazione fino al primo byte di risposta.
Il TTFB viene spesso abbreviato in tempo di risposta del server di un sito web. Questo termine è incompleto perché include anche le fasi di rete precedenti all'effettiva elaborazione sul server. La posizione del server, il routing e la distanza tra la regione di test e il data center influenzano il tempo di risposta del sito web, così come l'applicazione stessa.
In questo articolo, per "tempo di risposta" si intende sempre il TTFB (Time To First By). Il tempo di risposta di un sito web dopo un clic all'interno di un'interfaccia utente già caricata è una metrica diversa.
Classificazione corretta dei tempi di risposta dei siti web inferiori a 200 ms
Web.dev indica un TTFB (Time To First Backlog) non superiore a 0,8 secondi (800 ms) come linea guida approssimativa per buone prestazioni. Valori superiori a 1,8 secondi sono considerati scadenti; qualsiasi valore intermedio è considerato bisognoso di miglioramenti. Tuttavia, il TTFB non è un Core Web Vital. Pertanto, queste soglie servono come linea guida e non come unico criterio per valutare l'esperienza utente.
Un tempo di risposta del sito web inferiore a 200 ms, misurato singolarmente, rappresenta un risultato estremamente rapido. Tuttavia, ciò non garantisce che ogni URL, ogni richiesta e ogni area geografica manterranno costantemente un tempo di risposta inferiore a 200 ms. Funzionalità dinamiche, contenuti personalizzati, errori di cache o un carico elevato del server possono infatti portare a risultati diversi.
Per btlabs Core, la documentazione fornita non include un set completo di dati grezzi con data del test, singole misurazioni, mediana e p95. Pertanto, "inferiore a 200 ms" viene qui presentato come una specifica di prestazione da verificare e non come un risultato di misurazione definitivamente documentato. Una verifica affidabile richiede la pubblicazione di una serie completa di misurazioni.
TTFB, tempo di caricamento, LCP e punteggio Lighthouse differenziano
TTFB: Quando inizia la risposta?
Il TTFB (Time To First Byte) termina non appena arriva il primo byte di risposta. A questo punto, immagini, font, fogli di stile e file JavaScript potrebbero non essere ancora stati caricati. Un TTFB basso indica un buon punto di partenza, ma non garantisce che l'intera pagina sia già visibile o utilizzabile.
Tempo totale di ricarica: Quando termina il processo di ricarica?
Il tempo di caricamento totale non è una metrica di prestazione unica e universalmente definita. A seconda dello strumento, può riferirsi all'evento di caricamento stesso o a un momento successivo con bassa attività di rete. Media, font, script e servizi esterni possono aumentare il tempo di caricamento anche dopo l'arrivo del primo byte HTML.
Area di visualizzazione con il contenuto più grande: quando viene visualizzato il contenuto più grande?
Secondo web.dev, il Largest Contentful Paint (LCP) misura il tempo di rendering dell'immagine, del blocco di testo o del video più grande visibile nell'area di visualizzazione. L'LCP è uno dei Core Web Vitals e viene calcolato rispetto all'inizio della navigazione.
TTFB e LCP misurano tempi diversi ma sono collegati: i ritardi fino al raggiungimento del primo byte fanno parte del tempo LCP complessivo. Un TTFB lento può compromettere l'LCP. Viceversa, un TTFB veloce non garantisce un buon LCP se, ad esempio, l'immagine di copertina centrale è troppo grande o viene richiesta in ritardo.
Punteggio Lighthouse: come viene valutata la prestazione complessiva?
Secondo Chrome per sviluppatori, il punteggio di prestazioni di Lighthouse è una media ponderata di diversi punteggi metrici. Il modello di punteggio documentato include metriche come First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time e Cumulative Layout Shift. I pesi potrebbero cambiare con le nuove versioni di Lighthouse.
Il punteggio Lighthouse non è quindi sinonimo del tempo di risposta del server di un sito web. Un sito web può avere un TTFB (Time To First By) veloce e comunque un punteggio Lighthouse mediocre. Al contrario, un buon test Lighthouse in laboratorio può mascherare debolezze regionali o sporadiche nel tempo di risposta del sito web.
Protocollo di misurazione per una misurazione riproducibile
Una misurazione riproducibile richiede condizioni identiche. Per btlabs Core e qualsiasi altro sito web, il protocollo di misurazione deve contenere almeno le seguenti informazioni:
- Oggetto di prova: dominio completo e URL specifico,
- Tipo di pagina: Pagina iniziale, pagina dei contenuti, pagina di ricerca o funzione dinamica,
- Risposta: Stato HTTP e possibile catena di reindirizzamento,
- Volta: Data, ora e fuso orario della serie di misurazioni,
- Attrezzo: Nome e versione dello strumento di misurazione,
- Area di prova: ad esempio l'Italia settentrionale o l'Europa centrale,
- Connessione: profilo di rete definito,
- Stato della cache: La cache fredda e la cache calda sono separate.
- Campione: Numero di corse di riscaldamento e misurazioni valutate,
- Risultati: Valori individuali, mediana e p95,
- contesto: Posizione del server, utilizzo della CDN e funzionalità dinamiche.
Per dimostrare un tempo di risposta del sito web inferiore a 200 ms, è necessario definire un URL pubblico fisso per il core di btlabs. Inoltre, la misurazione dovrebbe includere diverse pagine di contenuto tipiche. Pubblicare solo l'URL più veloce non fornirebbe un quadro rappresentativo del sistema.
Misurare separatamente la cache fredda e la cache calda.
Una cache fredda significa che la risposta richiesta non può ancora essere fornita da una cache preparata. L'applicazione potrebbe dover leggere e rielaborare il contenuto da un'origine dati. Ciò in genere si traduce in un errore di cache.
Con una cache attiva (warm cache), la risposta, o una parte significativa di essa, è già presente nella cache. Un riscontro nella cache può ridurre significativamente il TTFB (tempo per la prima ricerca). Questi due stati rispondono a domande diverse:
- Il test della cache a freddo mostra le prestazioni quando è necessario rielaborare il contenuto.
- Il test della cache a caldo mostra la consegna dei contenuti richiesti più frequentemente.
- Il rapporto tra cache hit e cache miss mostra con quale frequenza gli utenti beneficiano della risposta memorizzata nella cache.
Mescolare cache fredda e cache calda in un'unica media rende difficile la classificazione. Un report trasparente presenta entrambe le serie di misurazioni separatamente e documenta come è stato raggiunto ciascuno stato.
Mediana e p95 invece dei valori migliori individuali
La mediana è il valore centrale di una serie ordinata di misurazioni: metà delle misurazioni sono inferiori ad essa, l'altra metà superiori. La mediana è meno sensibile ai valori anomali individuali rispetto alla media aritmetica.
Il valore p95 rappresenta il 95° percentile. Il 95% delle misurazioni indica tempi di risposta uguali o più rapidi; il 5% indica tempi di risposta più rapidi. Il valore p95 mostra come si comporta il tempo di risposta di un sito web in condizioni meno favorevoli, ma che si verificano regolarmente.
Per una PMI, entrambe le metriche sono rilevanti. La mediana descrive il caso tipico. Il p95 indica se un sistema rimane stabile o se alcuni visitatori riscontrano tempi di attesa significativamente più lunghi. Un singolo valore inferiore a 200 ms dimostra solo che tale velocità è stata raggiunta una sola volta. Solo la mediana e il p95 insieme mostrano quanto sia ripetibile la prestazione.
Quale architettura supporta un TTFB veloce?
Un sito web veloce non si crea con una singola ottimizzazione. Ciò che è fondamentale è un'architettura che eviti elaborazioni e trasmissioni non necessarie.
- Interfaccia utente snella: Una minore quantità di codice superfluo riduce il volume dei dati e il carico di elaborazione nel browser.
- Elaborazione lato server: I contenuti precompilati possono essere distribuiti prima rispetto ai contenuti creati interamente nel browser.
- Memorizzazione mirata nella cache: Le richieste ricorrenti non devono essere elaborate nuovamente ogni volta.
- Catene di inoltro brevi: Ogni reindirizzamento aggiuntivo crea un ulteriore passaggio nella rete.
- Distribuzione multimediale ottimizzata: I formati e le dimensioni adatti migliorano principalmente i tempi di caricamento LCP e di caricamento completo.
- Pochi script di terze parti: I servizi esterni aumentano le dipendenze e possono ritardare il rendering e l'interattività.
btlabs Core è concepito come una piattaforma digitale centrale da cui siti web e altri canali di output accedono a una base di contenuti comune. Nell'articolo sull'architettura di btlabs Core spiego il background tecnico . Un'architettura adeguata crea condizioni ottimali, ma non sostituisce le misurazioni in condizioni reali.
Quali fattori influenzano il tempo di risposta di un sito web?
Anche con il codice sorgente invariato, il tempo di risposta del server di un sito web può variare. Le cause tipiche includono:
- la distanza tra la regione di test e la posizione del server,
- il routing dell'operatore di rete,
- l'utilizzo attuale di hosting, database o applicazione,
- un successo nella cache o un errore nella cache
- contenuti personalizzati e utenti registrati,
- funzioni dinamiche di ricerca, prenotazione o acquisto,
- interfacce esterne e script di terze parti,
- Una connessione di rete locale instabile.
Per le aziende in Alto Adige, si consiglia di effettuare misurazioni in una regione di test dell'Europa centrale di riferimento. Se un sito web si rivolge a utenti in Italia e nella regione DACH (Germania, Austria e Svizzera), è opportuno condurre ulteriori serie di misurazioni in entrambe le aree di destinazione. Un test effettuato da un data center vicino al server non riflette in modo affidabile l'esperienza degli utenti situati più lontano.
Ecco come verificare il tempo di risposta di un sito web
Per un confronto affidabile, è innanzitutto necessario un approccio standardizzato:
- Scegli da tre a cinque URL pubblici rappresentativi.
- Si noti lo stato HTTP e i reindirizzamenti di ciascun URL.
- Definire uno strumento di misurazione e una regione di prova fissa.
- Eseguire diverse corse di riscaldamento che non sono incluse nella valutazione.
- Successivamente, registra almeno 20 misurazioni per ogni URL e stato della cache.
- Mantenere la cache fredda e la cache calda rigorosamente separate.
- Memorizza i singoli valori e calcola la mediana e il p95.
- Ripetere la misurazione una seconda volta.
- Confrontare i sistemi solo nelle stesse condizioni di prova.
Successivamente, verifica non solo il TTFB (Time To First By), ma anche le prestazioni complessive del sito web . La qualità percepita include anche i contenuti visibili, la stabilità grafica, l'interattività e una navigazione utente chiara.
Dopo il lancio, un Cookie di prestazione Budget per siti web di PMI Sono stati impostati dei limiti per immagini, script e indicatori chiave di prestazione. Ciò garantisce che la velocità rimanga un requisito di qualità costante.
Perché questo post non contiene un confronto prima-dopo
Un confronto prima-dopo ha senso solo se entrambi i sistemi vengono misurati con contenuti e funzioni comparabili, la stessa area di test, lo stesso strumento e stati della cache separati. Tali dati comparativi, raccolti in modo uniforme, non sono disponibili nella documentazione fornita.
Pertanto, evito di utilizzare valori comparativi costruiti ad arte o metodologicamente incoerenti. Quando si lavora con le PMI, un dato mancante chiaramente identificato è più utile di una cifra impressionante priva di una base verificabile.
Quali dati deve contenere un report di misurazione di btlabs Core?
Affinché un tempo di risposta del sito web "inferiore a 200 ms" sia considerato documentato, il report di misurazione deve riportare i seguenti dati:
- dominio testato e URL di test specifici,
- Data e ora della misurazione,
- Strumento, versione e regione di test,
- Ubicazione del server e relativa infrastruttura,
- Numero di corse di riscaldamento e misurazioni,
- Risultati della cache fredda e della cache calda,
- Mediana e p95 per URL e stato della cache,
- Valori grezzi o un report di misurazione esportabile,
- Valori anomali con una classificazione plausibile.
Stato editoriale: 25 marzo 2026. Infrastruttura, contenuti e servizi esterni sono soggetti a modifiche. Pertanto, una serie di misurazioni pubblicata richiede una data di aggiornamento e dovrebbe essere ripetuta dopo modifiche significative.
Domande e risposte sui tempi di risposta dei siti web
Qual è un buon valore di TTFB per un sito web?
Web.dev suggerisce un valore massimo di 800 ms come linea guida approssimativa per un buon TTFB (Time To First Byte). Per un progetto specifico di una PMI, considero anche la mediana, il p95, la regione di destinazione e il tipo di pagina, perché una singola soglia non rappresenta appieno l'esperienza utente.
Un TTFB inferiore a 200 ms significa che il sito web si carica in 200 ms?
No. Meno di 200 ms significa solo che il primo byte di risposta è arrivato entro tale intervallo di tempo. Immagini, font, JavaScript e contenuti visibili possono comunque essere caricati e visualizzati in seguito.
Perché la cache calda è più veloce della cache fredda?
Con una cache "calda", i dati o le risposte pre-configurati possono essere forniti direttamente, spesso con conseguente cache hit. Con una cache "fredda", il sistema potrebbe dover rigenerare il contenuto. Pertanto, entrambi gli stati devono essere misurati separatamente.
Perché Lighthouse mostra un valore diverso rispetto a un test TTFB?
Lighthouse valuta diverse metriche di prestazione ponderate in condizioni di laboratorio definite. Al contrario, un test TTFB considera solo il tempo intercorso fino alla ricezione del primo byte di risposta. Entrambe le misurazioni rispondono a domande diverse.
TTFB è un elemento fondamentale del Web?
No, il TTFB non è uno dei Core Web Vitals. Tuttavia, questa metrica influenza le fasi di caricamento successive e può quindi ritardare il Largest Contentful Paint (LCP).
Devo misurare il TTFB sul mio dispositivo mobile o sul mio computer fisso?
Per ottenere serie di misurazioni comparabili, è necessario utilizzare condizioni fisse e documentate. I test supplementari su dispositivi mobili sono utili perché la copertura della rete mobile, i dispositivi meno potenti e la qualità variabile della rete influiscono sull'esperienza utente reale.
Di quante misurazioni ho bisogno?
Un singolo test non è sufficiente per una conclusione affidabile. Per una verifica pragmatica da parte di esperti del settore, consiglio almeno 20 misurazioni valutate per URL e stato della cache dopo diverse prove di riscaldamento, nonché la valutazione della mediana e del p95.
Posso confrontare direttamente due sistemi per la creazione di siti web?
Sì, a condizione che il contenuto e le funzioni siano comparabili e che la regione di test, lo strumento, il numero di misurazioni e lo stato della cache siano gli stessi. Confrontare una semplice homepage con una pagina di negozio personalizzata non sarebbe metodologicamente corretto.
btlabs Core garantisce un tempo di risposta del sito web inferiore a 200 ms in ogni momento?
No. Una singola misurazione non può fornire una garanzia duratura per ogni URL, regione e funzione. Un'affermazione del genere può essere considerata un risultato comprovato solo con un protocollo di misurazione completo, dati grezzi, mediana e valore p95.
Conclusione: Il tempo di risposta del sito web può essere valutato in modo trasparente.
Un TTFB (Time To First By) basso è prezioso perché le fasi di caricamento successive possono procedere solo dopo che la risposta è iniziata. Tuttavia, il tempo di risposta di un sito web è solo un aspetto della sua qualità. Per la tua attività, sono altrettanto cruciali la stabilità del servizio, il caricamento rapido dei contenuti, una navigazione intuitiva per l'utente e un sistema gestibile a lungo termine.
Pertanto, con btlabs Core, il valore "inferiore a 200 ms" non dovrebbe essere presentato come un valore ottimale isolato. È necessaria una serie di misurazioni documentate, che includano le regioni di test pertinenti, cache fredda e calda separate, mediana, p95 e dati grezzi accessibili. Questo trasforma una specifica di prestazioni in una misurazione verificabile.
