Risolvere e Identificare i Problemi di Time to First Byte (TTFB)

Trovare e Risolvere i Problemi di Time to First Byte (TTFB)

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). Il TTFB è una metrica diagnostica che misura il tempo tra la richiesta di una pagina da parte dell'utente e la ricezione del primo byte della risposta da parte del browser. Sebbene il TTFB non sia di per sé un Core Web Vital, influenza direttamente sia il First Contentful Paint (FCP) che il Largest Contentful Paint (LCP). Un buon TTFB è inferiore a 800 millisecondi al 75° percentile.

Nel nostro articolo precedente abbiamo parlato del Time to First Byte. Se desideri approfondire le basi, quello è un ottimo punto di partenza.

In questo articolo ci concentreremo sull'identificazione dei diversi problemi di Time to First Byte e poi spiegheremo come risolverli.

SUGGERIMENTO TTFB: nella maggior parte dei casi il TTFB sarà molto peggiore per i visitatori alla prima visita poiché non hanno una cache DNS per il tuo sito. Quando si monitora il TTFB ha molto senso distinguere tra visitatori alla prima visita e visitatori di ritorno.

Passo 1: Controllare il TTFB in Search Console

"Il primo passo verso la guarigione è ammettere di avere un problema." Quindi prima di fare qualsiasi cosa per risolvere il Time to First Byte, assicuriamoci di avere davvero un problema con il TTFB.

Purtroppo il Time to First Byte non viene riportato in Google Search Console, quindi dobbiamo ricorrere a pagespeed.web.dev per consultare i dati CrUX del nostro sito. Fortunatamente i passaggi sono semplici: vai su pagespeed.web.dev, inserisci l'URL della tua pagina e assicurati che il pulsante "origin" sia selezionato (poiché abbiamo bisogno dei dati a livello di sito e non solo della homepage). Ora passa da Mobile a Desktop e controlla il Time to First Byte per entrambi i tipi di dispositivo.

Nell'esempio qui sotto vedrai un sito che non supera i Core Web Vitals a causa di un TTFB elevato.

Passo 1b: Utilizzare l'Header Server-Timing per un'Analisi più Approfondita

L'header di risposta HTTP Server-Timing consente al tuo server di comunicare le metriche di performance del backend direttamente al browser. Questo permette di individuare esattamente quale parte dell'elaborazione del server è lenta senza dover accedere ai log del server.

Un tipico header Server-Timing si presenta così:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

In questo esempio il server riporta tre valori di timing:

• db;dur=53: la query al database ha impiegato 53 millisecondi.
• app;dur=120: la logica applicativa (rendering dei template, chiamate API, ecc.) ha impiegato 120 millisecondi.
• cache;desc="miss": la cache del server non è stata utilizzata per questa richiesta (un cache miss).

Puoi leggere questi valori in Chrome DevTools aprendo la scheda Network, selezionando la richiesta del documento e scorrendo fino alla sezione "Server Timing" nella scheda Timing. I valori sono accessibili anche tramite l'API PerformanceServerTiming in JavaScript:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Se il tuo server non invia ancora header Server-Timing, considera di aggiungerli. La maggior parte dei framework web lo rende semplice. In PHP puoi aggiungere l'header prima di qualsiasi output:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

In Node.js con Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

L'header Server-Timing è particolarmente utile se combinato con il Real User Monitoring perché consente di correlare le performance lato server con il TTFB sperimentato dagli utenti reali. Scopri di più su come le 103 Early Hints possono ridurre ulteriormente il TTFB percepito inviando suggerimenti sulle risorse prima che la risposta completa sia pronta.

Passo 2: Configurare il Monitoraggio RUM

Il Time to First Byte è una metrica complessa. Non possiamo semplicemente affidarci a test sintetici per misurare il TTFB perché nella vita reale altri fattori contribuiranno alle fluttuazioni del TTFB. Per ottenere risposte a tutte le domande di cui sopra dobbiamo misurare i dati nella vita reale e registrare qualsiasi problema che potrebbe verificarsi con il Time to First Byte. Questo si chiama Real User Monitoring, e ci sono diversi modi per abilitare il monitoraggio RUM. Abbiamo sviluppato CoreDash proprio per questi casi d'uso. CoreDash è uno strumento RUM a basso costo, veloce ed efficace che svolge il suo lavoro. Naturalmente ci sono molte soluzioni RUM disponibili e anche loro faranno il lavoro (anche se a un prezzo più alto).

Come pensare al TTFB: Immagina che un web server sia la cucina di un ristorante e che un utente che richiede una pagina web sia un cliente affamato che effettua un ordine. Il Time to First Byte (TTFB) è l'intervallo di tempo tra il momento in cui il cliente effettua l'ordine e quello in cui la cucina inizia a preparare il cibo.
Quindi il TTFB NON riguarda la velocità con cui l'intero pasto viene cucinato (First Contentful Paint) e servito (Largest Contentful Paint), ma piuttosto quanto è reattiva la cucina alla richiesta iniziale.
Il monitoraggio RUM è paragonabile a un sondaggio tra i clienti per comprendere la loro esperienza culinaria. Potresti scoprire che i clienti seduti più lontano dalla cucina ricevono meno attenzione dal cameriere e vengono serviti più tardi, o che i clienti abituali ricevono un trattamento preferenziale mentre i nuovi visitatori devono aspettare più a lungo per un tavolo.

Passo 2b: Stabilire una Baseline delle Performance

Prima di apportare qualsiasi modifica, stabilisci una baseline per il tuo TTFB. Registra il 75° percentile del TTFB nelle seguenti dimensioni, poiché questo ti aiuterà a misurare l'efficacia delle tue ottimizzazioni in seguito:

1. TTFB complessivo (mobile e desktop separatamente): registra il 75° percentile per ogni tipo di dispositivo.
2. Le 10 pagine con più traffico: registra il TTFB individualmente per le pagine con il traffico più alto.
3. Nuovi visitatori vs. visitatori di ritorno: i visitatori alla prima visita hanno tipicamente un TTFB più alto a causa dell'overhead DNS e di connessione.
4. I 5 paesi con più traffico: la distanza geografica dal tuo server influisce significativamente sul TTFB.
5. Scomposizione delle sotto-parti del TTFB: registra il 75° percentile per ogni sotto-parte (attesa, cache, DNS, connessione, richiesta).

Documenta questi numeri in un foglio di calcolo. Dopo aver implementato ogni ottimizzazione, attendi almeno 7 giorni per raccogliere dati RUM sufficienti prima di confrontare i risultati. Un buon approccio è affrontare una sotto-parte del TTFB alla volta, misurare e poi passare alla successiva.

Passo 3: Identificare i Problemi di Time to First Byte

Sebbene il Chrome User Experience Report (CrUX) di Google fornisca dati preziosi dal campo, non offre dettagli specifici sulle cause di un TTFB elevato. Per migliorare efficacemente il TTFB dobbiamo sapere esattamente cosa sta succedendo a un livello più dettagliato. A questo punto ha senso distinguere tra un TTFB che fallisce complessivamente e un TTFB che fallisce in condizioni specifiche (anche se nella realtà ci sarà sempre un mix).

3.1 Il TTFB Fallisce Complessivamente

1. Verificare tempi di "richiesta" generalmente scadenti: Tempi di richiesta scadenti significano che il "problema" risiede nel tempo necessario al server per generare la pagina. Questa è la causa più comune di punteggi TTFB scadenti.
2. Verificare altre sotto-parti del TTFB scadenti: Il TTFB non è solo una singola metrica ma può essere scomposto in più parti, ognuna con il proprio potenziale di ottimizzazione. Se la durata di attesa, la durata della cache, la durata del lookup DNS o la durata della connessione sono lente, probabilmente dovrai ottimizzare le impostazioni del tuo server o iniziare a cercare un hosting di qualità migliore.

3.2 Il TTFB Fallisce in Condizioni Specifiche

1. Segmentazione per paese: Comprendere la distribuzione geografica di un TTFB elevato è importante, specialmente per i siti web con un pubblico globale. Se stai servendo le tue pagine da un solo server in un solo paese (senza edge caching CDN), la distanza fisica tra la posizione dell'utente e il server che ospita il sito web causerà ogni tipo di ritardo e impatterà sul TTFB. Considera di configurare Cloudflare o un altro CDN per avvicinare i tuoi contenuti agli utenti di tutto il mondo.
   
2. Segmentazione per cache: Il caching può ridurre il TTFB saltando la generazione lato server dell'HTML. Purtroppo è comune che il caching sia disabilitato o bypassato per molte ragioni. Ad esempio, il caching può essere disabilitato per utenti autenticati, pagine del carrello, pagine con query string (es. da Google Ads), pagine dei risultati di ricerca e pagine di checkout. Se il tuo sito web utilizza il caching (edge), usa il monitoraggio RUM per verificare il rapporto di cache hit.
   
3. Segmentazione per pagina (cluster): La differenza nelle performance del Time to First Byte (o la mancanza di differenza) tra pagine o tipi di pagina è un altro aspetto da determinare. Sapere quali pagine non superano la metrica TTFB fornirà informazioni preziose su come migliorare il Time to First Byte.
   
4. Segmentazione per redirect: Il tempo di redirect viene aggiunto direttamente al TTFB. Ogni redirect aggiunge tempo extra prima che il web server possa iniziare a caricare la pagina. Misurare ed eliminare i redirect non necessari può aiutare a migliorare il TTFB. Per un approfondimento sull'ottimizzazione dei redirect, consulta la nostra guida sulla durata di attesa, sotto-parte del TTFB.
   
5. Altre segmentazioni: Sebbene la segmentazione per le variabili sopra elencate copra i sospetti abituali, ogni sito è unico e ha le proprie sfide. Fortunatamente il monitoraggio RUM è progettato per consentire la segmentazione per molte altre variabili come RAM del dispositivo, velocità di rete, tipo di dispositivo, sistema operativo, variabili personalizzate e molto altro.

Passo 4: Approfondire i Problemi e Risolverli

Le sotto-parti del Time to First Byte (TTFB) sono:

• Attesa + Redirect (o durata di attesa)
• Worker + Cache (o durata della cache)
• DNS (o durata DNS)
• Connessione (o durata della connessione)
• Richiesta (o durata della richiesta)

Passo 5: Checklist Rapida per i Problemi TTFB più Comuni

In base alla sotto-parte che contribuisce maggiormente al tuo TTFB, ecco un riferimento rapido per le correzioni più comuni:

Misurare il TTFB con JavaScript

Puoi misurare il TTFB completo e le sue sotto-parti direttamente nel browser utilizzando la Navigation Timing API. Il seguente snippet calcola il TTFB e registra ogni sotto-parte:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Questo codice fornisce la stessa scomposizione che strumenti come CoreDash visualizzano nel pannello di attribuzione del TTFB. Eseguire questo snippet nella console del browser ti dà una lettura immediata per un singolo caricamento di pagina, mentre gli strumenti RUM raccolgono questi dati da migliaia di utenti reali per produrre valori affidabili al 75° percentile.

Ulteriori Letture: Guide all'Ottimizzazione

Per tecniche di ottimizzazione specifiche che migliorano il TTFB, esplora queste guide correlate:

• 103 Early Hints: invia suggerimenti sulle risorse prima che la risposta completa sia pronta, consentendo al browser di iniziare a caricare le risorse critiche mentre il server sta ancora elaborando.
• Configurare Cloudflare per le Performance: configura il CDN, il caching e le funzionalità edge di Cloudflare per ridurre il TTFB per un pubblico globale.

Sotto-parti del TTFB: Articoli di Approfondimento

Ogni sotto-parte del Time to First Byte ha strategie di ottimizzazione uniche. Esplora l'area specifica che i tuoi dati RUM identificano come collo di bottiglia:

• Durata di Attesa: redirect, accodamento del browser e ottimizzazione HSTS.
• Durata della Cache: performance del service worker, cache del browser e bfcache.
• Durata DNS: selezione del provider DNS, configurazione TTL e dns-prefetch.
• Durata della Connessione: handshake TCP, ottimizzazione TLS, HTTP/3 e preconnect.