Performance
TTFB: cosa misura e come si riduce
Il TTFB è il tempo tra richiesta e primo byte. Sul nostro sito la mediana è 350 ms, di cui 59 ms di handshake: come si misura e cosa lo riduce.
In sintesi
- Il TTFB si misura con curl o con l'API Navigation Timing, non con la sola Lighthouse.
- La soglia Google è 800 ms al 75° percentile; sopra 1.800 ms la pagina è da correggere.
- Sul nostro sito la mediana su connessione fredda è 350 ms, e 59 ms sono handshake.
- Con TTFB buono e LCP alto il collo di bottiglia è il rendering, non il server.
Il TTFB (time to first byte) è il tempo tra la richiesta del browser e il primo byte di risposta: sotto 800 ms è buono, sopra 1.800 ms è da correggere. Misura server e rete, non il rendering.
Le quattro parti del TTFB
| Fase | Cosa la causa | Dove si legge | Rimedio |
|---|---|---|---|
| DNS | Risoluzione del dominio | domainLookupEnd - startTime | dns-prefetch e TTL più alto |
| TCP e TLS | Handshake con l'origine | connectEnd e secureConnectionStart | keep-alive, HTTP/2, preconnect |
| Server | Coda, query, cold start | responseStart - requestStart | cache HTML, indici, edge |
| Trasferimento | Primo byte dopo la risposta | responseStart | compressione e HTML più corto |
Sul nostro sito il server pesa più dell'handshake: 291 ms contro 59 ms. È il caso normale quando l'HTML si genera a ogni richiesta e nessuna cache lo riusa.
Misurarlo da terminale
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/; done | sort -nIl comando richiede bash, curl e una connessione. Il campo time_starttransfer include handshake e trasferimento: per il solo tempo del server leggi anche time_pretransfer e sottrai.
Cosa riduce il TTFB
- Cache: servi l'HTML dalla cache quando non cambia e togli le query duplicate dalla stessa pagina. Fonte: web.dev, CC BY 4.0.
- Connessione: tieni aperto il socket con keep-alive e HTTP/2 verso la stessa origine.
- Origini esterne: aggiungi rel=preconnect solo per gli host che usi davvero. Fonte: MDN, CC BY-SA 2.5.
- Distanza: se il pubblico è lontano dal server, metti una cache edge davanti all'origine.
Il limite da dichiarare
Il TTFB non dice nulla sul rendering: una pagina con 300 ms di primo byte e 4 s di LCP ha il problema nel JavaScript, non nel server. Non è nemmeno una Core Web Vital, è una metrica diagnostica, e va letta insieme a LCP, INP e CLS.
Dove continuare
Il catalogo EneUI indicizza 111.985 componenti, 1.556 blocchi e il record hero parallax: un hero con molte immagini gonfia l'HTML e allunga il primo byte. Per le soglie leggi cosa sono i Core Web Vitals, per il rendering cosa peggiora l'LCP, per il confronto tra architetture framework frontend a confronto.
Domande frequenti
Il TTFB è una Core Web Vital?
No. È una metrica diagnostica: Google la pubblica accanto a LCP, INP e CLS, ma non entra nel punteggio delle Core Web Vitals.
Qual è una soglia accettabile?
Sotto 800 ms al 75° percentile è buono, sopra 1.800 ms è da correggere. Sotto 500 ms resta margine per la rete mobile.
Perché il TTFB che misuro è diverso da Search Console?
Search Console usa dati di campo di utenti reali su 28 giorni; curl misura una richiesta dalla tua rete. Latenza, cache e posizione cambiano il numero.
Il TTFB si vede in Lighthouse?
Sì, l'audit server-response-time riporta il TTFB di laboratorio di una sola esecuzione. Per decidere se la pagina passa contano i dati di campo.
Cosa riduce il TTFB senza cambiare hosting?
Cache dell'HTML, indici sulle query, meno chiamate sincrone nel percorso critico e keep-alive. Se il server è lontano dal pubblico serve un edge o un'altra regione.