Ridurre la sottocomponente Waiting Duration del Time to First Byte

Ridurre la Waiting Duration del Time to First Byte

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). La waiting duration è la prima sottocomponente del TTFB e consiste principalmente nel tempo di redirect e nell'accodamento del browser (browser queuing). Una waiting duration elevata è quasi sempre causata da redirect non necessari che aggiungono round trip prima che il server possa iniziare a elaborare la richiesta effettiva.

Il Time to First Byte (TTFB) può essere suddiviso nelle seguenti sottocomponenti:

• Waiting + Redirect (o waiting duration)
• Worker + Cache (o cache duration)
• DNS (o DNS duration)
• Connection (o connection duration)
• Request (o request duration)

Vuoi ottimizzare il Time to First Byte? Questo articolo tratta la parte relativa alla waiting duration del Time to First Byte. Se vuoi capire o risolvere i problemi del Time to First Byte e non sai cosa significhi waiting duration, leggi cos'è il Time to First Byte e come identificare e risolvere i problemi di Time to First Byte prima di iniziare questo articolo.

I redirect possono avere un grande impatto sul Time to First Byte (TTFB) perché ogni redirect viene aggiunto al tempo necessario affinché un browser riceva il primo byte di dati da un server. Ecco come i redirect influenzano il TTFB:

In che modo i redirect aumentano il Time to First Byte?

I redirect sono tipicamente inclusi nella misurazione completa del TTFB (vedi riquadro blu). Ciò significa che il tempo impiegato per tutti i redirect viene calcolato nel punteggio TTFB complessivo, facendolo potenzialmente apparire più alto del previsto.

Quando una pagina viene reindirizzata, questi sono i passaggi abituali che si verificano:

• Il browser invia una richiesta iniziale all'URL originale.
• Il server elabora questa richiesta e risponde con un codice di stato di redirect (ad esempio, 301 o 302).
• Il browser invia quindi una nuova richiesta all'URL reindirizzato.
• Il server elabora questa seconda richiesta e inizia a inviare il contenuto effettivo.

Tipi di redirect e il loro impatto

Non tutti i redirect sono uguali. Capire i diversi tipi ti aiuta a dare priorità a quali redirect eliminare per primi:

Un singolo redirect aggiunge tipicamente da 50 a 300 millisecondi al TTFB, a seconda delle condizioni della rete e del tempo di risposta del server. Quando due o tre redirect si concatenano, questi tempi si sommano e possono spingere il TTFB ben oltre la soglia "buona" di 800ms.

Aumento del tempo di elaborazione del server

Questa elaborazione aggiuntiva aumenta il TTFB complessivo, poiché ogni passaggio richiede tempo affinché il server gestisca la richiesta e risponda.

Catene di redirect

In alcuni casi, possono verificarsi più redirect prima di raggiungere la destinazione finale. Questo crea una "catena di redirect" che aumenta il TTFB. Ogni redirect nella catena aggiunge il proprio tempo di elaborazione, aumentando il ritardo prima che venga ricevuto il primo byte del contenuto effettivo.

Un esempio comune di catena di redirect:

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

In questo esempio, si verificano tre redirect prima che il browser riceva qualsiasi contenuto. Il primo redirect (da HTTP a HTTPS) può essere eliminato con HSTS. Il secondo e il terzo redirect possono essere eliminati aggiornando i link interni in modo che puntino direttamente all'URL finale.

Latenza di rete

I redirect spesso comportano ulteriori round trip di rete tra il client e il server. Ciò introduce un'ulteriore latenza di rete, specialmente se i redirect coinvolgono domini o server diversi. La distanza fisica tra il client e il server per ogni redirect può influire ulteriormente sul TTFB.

Redirect JavaScript vs redirect lato server: solo i redirect lato server (che funzionano con un header di redirect 30x) vengono aggiunti al Time to First Byte. I redirect JavaScript non vengono aggiunti al Time to First Byte perché il server ha inviato una risposta completa (200).

Si potrebbe pensare che i redirect JavaScript siano preferibili poiché non si aggiungono al Time to First Byte. Sfortunatamente, i redirect JavaScript sono molto più lenti per gli utenti reali e causano una cattiva User Experience.

Impatto sulla User Experience (e SEO)

Sebbene i redirect siano a volte necessari, il loro impatto sul TTFB può avere implicazioni più ampie:

• User Experience: un TTFB più lento dovuto ai redirect può ritardare il rendering iniziale della pagina, frustrando potenzialmente gli utenti.
• SEO: sebbene il TTFB non sia un fattore di ranking diretto, influenza altre metriche come il Largest Contentful Paint (LCP), che è un Core Web Vital considerato dai motori di ricerca.
• Crawl budget: i crawler dei motori di ricerca seguono i redirect, il che significa che ogni redirect consuma ulteriore crawl budget. Per i siti web di grandi dimensioni, ciò può rallentare la scoperta di contenuti nuovi o aggiornati.

Come misurare i problemi di TTFB causati dai redirect

Per trovare l'impatto che gli utenti reali sperimentano a causa dei redirect, dovrai utilizzare uno strumento RUM come CoreDash. Il Real User Monitoring ti consentirà di monitorare i Core Web Vitals in grande dettaglio.

In CoreDash, fai semplicemente clic su "redirect count" per visualizzare i tuoi dati segmentati per numero di redirect. Quindi, ad esempio, fai clic sul segmento "1 redirect" per filtrare i dati RUM per "1 redirect" e visualizzare tutti gli URL interessati.

Come controllare il tuo sito per i redirect

Un controllo sistematico dei redirect prevede tre passaggi:

Passaggio 1: Scansiona il tuo sito

Usa uno strumento di scansione (come MarketingTracer, Screaming Frog o Sitebulb) per scansionare l'intero sito web. Il crawler segnalerà tutti gli URL interni che rispondono con un codice di stato 3xx. Esporta l'elenco e ordinalo in base al numero di link interni in entrata che puntano a ciascun URL reindirizzato.

Passaggio 2: Identifica le catene di redirect

Filtra i risultati della scansione per qualsiasi URL che reindirizza a un altro URL che a sua volta reindirizza. Queste catene dovrebbero essere corrette per prime perché moltiplicano la penalità TTFB.

Passaggio 3: Correggi e verifica

Aggiorna i tuoi link interni in modo che puntino direttamente all'URL di destinazione finale. Dopo aver aggiornato i link, scansiona di nuovo per verificare che i redirect non vengano più attivati dalla navigazione interna. Usa il seguente snippet JavaScript per rilevare i redirect dal browser:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Come ridurre al minimo l'impatto dei redirect

Come regola generale, segui questi 3 semplici passaggi per evitare problemi di redirect:

• Riduci al minimo l'uso di redirect ove possibile.
• Evita le catene di redirect aggiornando i link affinché puntino direttamente all'URL di destinazione finale.
• Usa i redirect lato server invece dei redirect lato client quando possibile, poiché sono generalmente più veloci.

Redirect della stessa origine (Same origin). I redirect della stessa origine provengono da link sul tuo sito web. Dovresti avere il pieno controllo su questi link e dovresti dare la priorità alla correzione di questi link quando lavori sul Time to First Byte. Il metodo tipico per trovare questi redirect interni consiste nell'utilizzare uno qualsiasi degli strumenti disponibili che ti consentiranno di controllare l'intero sito web per i redirect.

Redirect cross-origin. I redirect cross-origin provengono da link su altri siti web. Hai pochissimo controllo su questi. Per i link ad alto impatto che generano molto traffico, considera di contattare il webmaster del sito per aggiornare l'URL collegato.

Catene di redirect. Più redirect o catene di redirect si verificano quando un singolo redirect non reindirizza alla posizione finale della risorsa. Questi tipi di redirect mettono più a dura prova il Time to First Byte e dovrebbero essere evitati a tutti i costi. Ancora una volta, usa uno strumento per trovare questi tipi di redirect e correggerli.

Redirect da HTTP a HTTPS e HSTS

I redirect da HTTP a HTTPS sono uno dei tipi di redirect più comuni. Ogni visitatore che digita il tuo dominio senza "https://" o segue un vecchio link HTTP sperimenterà un redirect 301. L'header Strict-Transport-Security (HSTS) elimina questo redirect per i visitatori ricorrenti dicendo al browser di usare sempre HTTPS.

Per abilitare HSTS, aggiungi il seguente header alla risposta del tuo server:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Ecco cosa significa ogni direttiva:

• max-age=31536000: il browser si ricorderà di usare HTTPS per questo dominio per un anno (31.536.000 secondi).
• includeSubDomains: applica il requisito HTTPS anche a tutti i sottodomini.
• preload: consente al tuo dominio di essere incluso nell'elenco di precaricamento HSTS integrato nel browser, il che significa che anche la primissima visita userà HTTPS senza redirect.

Per sottoporre il tuo dominio all'elenco di precaricamento HSTS, visita hstspreload.org. Una volta che il tuo dominio è nell'elenco di precaricamento, i browser non effettueranno mai una richiesta HTTP al tuo dominio, eliminando completamente il redirect da HTTP a HTTPS per tutti i visitatori.

In Apache, puoi aggiungere HSTS con:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

In Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

In generale raccomandiamo di:

1. Controllare e aggiornare regolarmente i link interni. Ogni volta che cambi la posizione di una pagina, aggiorna i tuoi link interni a quella pagina per assicurarti che non rimangano riferimenti alla posizione precedente della pagina.
2. Gestire i redirect a livello di server. Il metodo di redirect preferito è il redirect 301. Un redirect 301 è un redirect permanente, mentre un redirect 302 è un redirect temporaneo. I redirect temporanei, ad esempio, potrebbero non venire aggiornati nei motori di ricerca.
3. Usare URL relativi: quando colleghi pagine sul tuo sito web, usa URL relativi invece di URL assoluti. Questo aiuterà a prevenire redirect non necessari.
4. Usare URL canonici: se hai più pagine con contenuti simili, usa un URL canonico per indicare la versione preferita della pagina. Questo aiuterà a prevenire contenuti duplicati e redirect non necessari.

Ulteriori letture: guide all'ottimizzazione

Guide correlate:

• 103 Early Hints: riduci il TTFB percepito inviando suggerimenti sulle risorse mentre il server elabora la risposta completa.
• Configurare Cloudflare per la Performance: ottimizza la configurazione della tua CDN per ridurre le catene di redirect e migliorare il TTFB globale.

Sottocomponenti del TTFB: guide complete

La waiting duration è una delle cinque sottocomponenti del TTFB. Esplora le altre sottocomponenti per comprendere il quadro completo:

• Identificare e risolvere i problemi di TTFB: il punto di partenza diagnostico per ogni ottimizzazione del TTFB.
• Cache Duration: performance del service worker, ricerche nella cache del browser e bfcache.
• DNS Duration: scelta del provider DNS, configurazione TTL e dns-prefetch.
• Connection Duration: handshake TCP, ottimizzazione TLS, HTTP/3 e preconnect.
• Request Duration: tempo di elaborazione del server, query al database e ottimizzazione backend.