Tempo al primo byte (TTFB)

Il Time to First Byte (Time to First Byte) misura l'intervallo tra la richiesta di una risorsa da parte del browser e la ricezione del primo byte della risposta. Aggrega diverse fasi distinte: reindirizzamenti, risoluzione DNS, stabilimento della connessione, negoziazione TLS, la richiesta stessa e il tempo di elaborazione del server prima che inizi a rispondere. Poiché tutto il resto del caricamento della pagina dipende dall'arrivo di questa risposta, il Time to First Byte funge da parametro di riferimento per tutte le metriche di caricamento successive.

Il suo valore diagnostico deriva dalla posizione nella sequenza. Una pagina con un rendering lento della parte più grande della pagina (largest contentful paint) e un primo byte veloce presenta un problema di front-end, nella distribuzione delle risorse, nel rendering o nel blocco delle risorse. La stessa pagina con un primo byte lento presenta un problema di back-end o di rete, e nessuna ottimizzazione delle immagini o differimento degli script lo risolverà, perché il browser non ha ancora ricevuto nulla su cui lavorare. Stabilire quale di questi problemi si applica è il primo passo in qualsiasi seria indagine sulle prestazioni.

Le cause che contribuiscono al problema si dividono in categorie di rete e di server. Sul lato rete, la distanza geografica tra il visitatore e il server di origine aggiunge una latenza inevitabile, le catene di reindirizzamento aggiungono ciascuna un intero round trip e la negoziazione della connessione e del TLS aggiungono ulteriori round trip per le nuove connessioni. Sul lato server, le cause più comuni sono il codice applicativo lento, le query di database non indicizzate o inefficienti, le chiamate a servizi esterni effettuate in modo sincrono durante la richiesta, la cache assente o inefficace e la contesa delle risorse su hosting condiviso.

Di conseguenza, le soluzioni variano. Le reti di distribuzione dei contenuti (CDN) affrontano il problema della distanza servendo i contenuti da posizioni vicine al visitatore e possono fornire risposte memorizzabili nella cache interamente dalla periferia della rete, senza contattare il server di origine. La memorizzazione nella cache a più livelli, inclusa la cache di pagine intere, frammenti, oggetti e query di database, elimina le operazioni ripetute. L'eliminazione delle catene di reindirizzamento elimina interi round trip, che spesso rappresenta il miglioramento più significativo ottenibile sui siti con strutture URL obsolete. I protocolli moderni e il riutilizzo delle connessioni riducono l'overhead di negoziazione. Lato applicazione, l'ottimizzazione delle query e lo spostamento delle operazioni non essenziali al di fuori del percorso della richiesta si concentrano sul componente server.

La misurazione dovrebbe distinguere tra risposte memorizzate nella cache e risposte non memorizzate nella cache, e tra prime visite e visite successive, poiché queste possono differire di un ordine di grandezza e una media non tiene conto di entrambe. I dati raccolti segmentati per area geografica e tipo di connessione sono più informativi di un singolo dato, perché un sito con numeri complessivi accettabili potrebbe servire molto male un determinato mercato. Eseguire i test dalla posizione in cui il sito è ospitato, che è la prassi comune, sottostima sistematicamente l'esperienza dei visitatori provenienti da località remote.

Il tasso di successo della cache è l'indicatore diagnostico più utile quando si analizza questa metrica su un sito dietro una rete di distribuzione dei contenuti (CDN), e spesso risulta basso per motivi facilmente correggibili. Risposte contrassegnate come non memorizzabili nella cache per impostazione predefinita, chiavi di cache frammentate da parametri di tracciamento o intestazioni non necessarie e tempi di scadenza brevi causano l'invio al server di origine di richieste che non dovrebbero. Misurando la proporzione di richieste gestite dal server edge ed esaminando cosa distingue i mancati riscontri, si identifica in genere un piccolo numero di decisioni di configurazione responsabili della maggior parte di essi. Migliorare tale proporzione riduce sia la latenza per i visitatori sia il carico sul server di origine, migliorando così le risposte che devono effettivamente essere generate.

Poiché il miglioramento richiede solitamente modifiche all'infrastruttura, alla strategia di caching o al codice dell'applicazione piuttosto che alle risorse front-end, questa misura è il punto in cui il lavoro sulle prestazioni passa più spesso dal livello di presentazione all'ingegneria. In pratica viene affrontato congiuntamente da prestazioni web and sviluppo del prodottoe spesso è proprio questo vincolo che deve essere risolto per primo, poiché l'ottimizzazione front-end applicata su un'origine lenta produce risultati deludenti che vengono poi erroneamente attribuiti al lavoro di ottimizzazione.