Il tempo al primo byte è quanto passa dalla domanda all'arrivo del primo byte della risposta. Contiene il DNS, la connessione, l'handshake e il server che pensa - e curl stampa ogni parte separatamente, così lei vede quale sia.
curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://yourdomain.com/Come si legge
- dns grande - un resolver lento, oppure un TTL bassissimo che costringe a una risoluzione ogni volta.
- connect grande - la distanza. Un server in un altro continente non si aggiusta con il codice.
- tls meno connect grande - l'handshake. Una catena di certificati incompleta obbliga il browser ad andarsi a prendere il pezzo mancante.
- ttfb meno tls grande - il server che costruisce la pagina. È questa la parte che può sistemare.
Che cosa è un buon valore
- Sotto i 200 ms - il server non è il suo problema. Guardi il browser.
- 200-500 ms - normale per una pagina dinamica senza cache.
- Oltre gli 800 ms - qualcosa di preciso è lento, e conviene trovarlo invece di coprirlo con la cache.
Misuri lo stesso URL più volte. La prima richiesta dopo un deploy è lenta per ragioni che non toccheranno mai un visitatore - cache fredde, opcache vuoto - e una singola misura di quella non le dice nulla.
Misuri da dove stanno i suoi visitatori
Un TTFB misurato dal server stesso esclude del tutto la rete ed è sempre eccellente. Non è nemmeno ciò che vive qualcuno.
Se il TTFB è buono e la pagina sembra comunque lenta, smetta di ottimizzare il server. Il tempo sta nel browser e nessuna quantità di cache lo cambierà.
