Ridurre il TTFB: dove si perde il tempo prima del primo byte

Il Time to First Byte è il tempo che passa tra l'avvio della navigazione e l'arrivo del primo byte della risposta HTML. Non è un Core Web Vital, ma è il punto di partenza di tutti gli altri: se l'HTML arriva dopo due secondi, nessuna ottimizzazione di immagini o JavaScript potrà portare l'LCP sotto i 2,5 secondi. Come orientamento, un TTFB intorno agli 800 millisecondi o meno è generalmente ritenuto ragionevole; il valore ideale dipende dal tipo di sito.

Che cosa c'è dentro il TTFB

Misurato dal browser, il TTFB include più tempi di quanto si pensi:

1. eventuali redirect prima della pagina finale;
2. eventuale avvio di un service worker;
3. ricerca DNS del dominio;
4. connessione TCP (o QUIC con HTTP/3) e negoziazione TLS;
5. invio della richiesta e elaborazione sul server;
6. viaggio del primo byte di ritorno.

Chi guarda solo i log del server vede il punto 5 e conclude che va tutto bene: «la pagina viene generata in 120 millisecondi». Ma l'utente può aspettare un secondo intero per colpa dei punti precedenti.

Redirect: il costo nascosto

Ogni redirect è un viaggio completo in più, con possibile nuova connessione se cambia il dominio. Una catena frequente:

http, senza www  →  https, senza www  →  https, con www  →  https, con www e /it/

Tre redirect prima della pagina vera. Su una rete mobile con 100 millisecondi di latenza, solo questa catena può costare diverse centinaia di millisecondi. Le correzioni:

• fare in modo che link interni, sitemap e campagne puntino direttamente all'indirizzo finale;
• condensare le regole in un solo redirect diretto verso la destinazione corretta;
• attivare HSTS, così che dopo la prima visita il browser passi a https senza chiedere al server.

Distanza e connessione

La latenza di rete dipende anche dalla distanza fisica. Un server in un solo data center serve bene chi è vicino e peggio chi è lontano, perché DNS, handshake TCP e TLS richiedono ciascuno almeno un viaggio di andata e ritorno. Le contromisure:

• servire le pagine da una rete di distribuzione con nodi vicini al pubblico, anche per l'HTML quando è memorizzabile;
• usare TLS 1.3, che richiede meno viaggi per la negoziazione rispetto alle versioni precedenti;
• abilitare HTTP/3 dove possibile, perché su QUIC connessione e cifratura si stabiliscono insieme;
• scegliere un fornitore DNS veloce e TTL non troppo brevi.

Elaborazione sul server

Quando il tempo di attesa vero e proprio è alto, il problema è nell'applicazione. Le cause che incontro più spesso:

• nessuna cache di pagina: ogni visita rigenera la pagina da zero interrogando il database, anche se il contenuto cambia una volta al giorno;
• query lente o ripetute: un elenco di articoli che esegue una query per ogni elemento invece di una sola per tutti;
• chiamate esterne sincrone: la pagina attende la risposta di un servizio terzo (meteo, recensioni, valute) prima di partire;
• risorse del server insufficienti: hosting condiviso sovraccarico, memoria esaurita, processi PHP o Node in coda;
• avvio a freddo: piattaforme serverless che, dopo un periodo di inattività, impiegano tempo a riattivare l'istanza.

Misurare dal lato server

L'intestazione Server-Timing permette di esporre al browser i tempi interni dell'applicazione, che poi compaiono in DevTools accanto alla richiesta:

Server-Timing: db;dur=85, tpl;dur=30, cache;desc="miss"

Così si vede subito se il tempo va nel database, nel rendering del modello o se la cache non ha funzionato.

Cache dell'HTML

L'intervento più efficace per siti in cui il contenuto è uguale per tutti è memorizzare l'HTML già generato. Le opzioni vanno dalla cache di pagina dell'applicazione a quella del server web, fino alla cache sulla rete di distribuzione. Per pagine che cambiano spesso si può usare stale-while-revalidate: l'utente riceve subito la versione in cache mentre in background se ne prepara una nuova.

Il punto delicato è la personalizzazione. Pagine con carrello, nome dell'utente o contenuti per regione non si possono memorizzare in blocco; si separa allora la parte comune, memorizzabile, da quella personale, caricata dopo.

Streaming della risposta

Un'altra tecnica utile è inviare la prima parte dell'HTML, cioè l'intestazione con CSS e risorse critiche, prima che il server abbia finito di generare il resto. Il browser inizia a scaricare stili e font mentre il server completa il corpo. Molti framework moderni lo supportano nativamente; anche un semplice flush anticipato in un'applicazione tradizionale può dare benefici.

In sintesi

• Il TTFB include redirect, DNS, connessione, TLS ed elaborazione, non solo il tempo del server.
• Elimina le catene di redirect e attiva HSTS.
• Avvicina i contenuti al pubblico e usa TLS 1.3 e, se possibile, HTTP/3.
• Con Server-Timing scopri dove si perde il tempo nell'applicazione.
• La cache dell'HTML e lo streaming della risposta sono gli interventi più efficaci.