Ottimizza il tempo per il primo byte

Scopri come ottimizzare la metrica Time to First Byte.

Jeremy Wagner

Barry Pollard

Time to First Byte (TTFB) è una metrica fondamentale per le prestazioni sul web che precede ogni altra metrica significativa relativa all'esperienza utente, come First Contentful Paint (FCP) e Largest Contentful Paint (LCP). Ciò significa che valori TTFB elevati aumentano il tempo necessario alle metriche che seguono.

Ti consigliamo di far sì che il tuo server risponda alle richieste di navigazione abbastanza rapidamente, in modo che il 75° percentile di utenti registri un valore FCP entro la soglia "buona". Come guida approssimativa, la maggior parte dei siti dovrebbe avere un TTFB di 0,8 secondi o meno.

Come misurare il TTFB

Prima di poter ottimizzare il TTFB, devi osservare come influisce sugli utenti del tuo sito web. Dovresti fare affidamento sui dati sul campo come fonte principale di osservazione del TTFB in quanto interessato dai reindirizzamenti, mentre gli strumenti basati su lab vengono spesso misurati utilizzando l'URL finale, per cui manca questo ritardo aggiuntivo.

PageSpeed Insights è un modo semplice per ottenere informazioni sul campo e di prova per i siti web pubblici disponibili nel Report sull'esperienza utente di Chrome.

Il TTFB per gli utenti reali viene mostrato nella sezione Scopri cosa stanno riscontrando i tuoi utenti reali in alto:

Un sottoinsieme di TTFB è mostrato nel controllo del tempo di risposta del server:

Per scoprire altri modi su come misurare il TTFB sia sul campo che nel lab, consulta la pagina delle metriche TTFB.

Comprendere un TTFB elevato con Server-Timing

L'intestazione della risposta Server-Timing può essere utilizzata nel backend dell'applicazione per misurare processi di backend distinti che potrebbero contribuire all'alta latenza. La struttura del valore dell'intestazione è flessibile e accetta, come minimo, un handle definito da te. I valori facoltativi includono un valore della durata (tramite dur) e una descrizione leggibile facoltativa (tramite desc).

Serving-Timing può essere utilizzato per misurare molti processi di backend delle applicazioni, ma ce ne sono alcuni a cui potresti voler prestare particolare attenzione:

• Query sul database
• Tempo di rendering lato server, se applicabile
• Ricerca su disco
• Hit/mancanti della cache perimetrale del server (se utilizzi una rete CDN)

Tutte le parti di una voce Server-Timing sono separate da due punti e più voci possono essere separate da una virgola:

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

L'intestazione può essere impostata utilizzando la lingua scelta per il backend dell'applicazione. In PHP, ad esempio, potresti impostare l'intestazione in questo modo:

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Una volta impostata, questa intestazione mostrerà informazioni che puoi utilizzare sia nel lab che nel campo.

Nel campo, qualsiasi pagina con un'intestazione della risposta Server-Timing impostata verrà compilata nella proprietà serverTiming nell'API Navigation Timing:

// Get the serverTiming entry for the first navigation request:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
    // Log the server timing data:
    console.log(entry.name, entry.description, entry.duration);
});

Nel lab, i dati dell'intestazione della risposta Server-Timing verranno visualizzati nel riquadro della sincronizzazione della scheda Rete in Chrome DevTools:

Intestazioni della risposta Server-Timing visualizzate nella scheda Rete di Chrome DevTools. In questo caso, Server-Timing viene utilizzato per misurare se una richiesta per una risorsa ha raggiunto la cache CDN e quanto tempo impiega la richiesta per raggiungere il server perimetrale della CDN, poi l'origine.

Una volta stabilito che si è verificato un problema con TTFB analizzando i dati disponibili, puoi passare alla risoluzione del problema.

Metodi per ottimizzare TTFB

L'aspetto più impegnativo dell'ottimizzazione del TTFB è che, sebbene lo stack di frontend del web sia sempre HTML, CSS e JavaScript, gli stack di backend possono variare significativamente. Esistono numerosi stack di backend e prodotti di database, ognuno dei quali ha le proprie tecniche di ottimizzazione. Pertanto, questa guida si concentrerà su ciò che si applica alla maggior parte delle architetture, piuttosto che esclusivamente sulle indicazioni specifiche dello stack.

Indicazioni specifiche per la piattaforma

La piattaforma che utilizzi per il tuo sito web può avere un impatto significativo su TTFB. Ad esempio, le prestazioni di WordPress sono influenzate dal numero e dalla qualità dei plug-in o dai temi utilizzati. La personalizzazione delle piattaforme ha un impatto simile anche sulle altre piattaforme. Consulta la documentazione della tua piattaforma per consigli specifici del fornitore nonché quelli più generali per il rendimento riportati in questo post. Il controllo Lighthouse per ridurre i tempi di risposta del server include anche alcune indicazioni specifiche per gli stack limitati.

Hosting, hosting, hosting

Prima ancora di prendere in considerazione altri approcci di ottimizzazione, l'hosting dovrebbe essere la prima cosa da considerare. Non c'è molto modo di fornire indicazioni specifiche da offrire in questa sede, ma una regola generale è quella di assicurarsi che l'host del sito web sia in grado di gestire il traffico che gli invii.

L'hosting condiviso è generalmente più lento. Se gestisci un piccolo sito web personale che pubblica principalmente file statici, probabilmente non c'è problema. Alcune delle tecniche di ottimizzazione che seguono ti aiuteranno a ridurre il più possibile questo TTFB.

Tuttavia, se esegui un'applicazione di grandi dimensioni con molti utenti che prevede la personalizzazione, l'esecuzione di query sul database e altre operazioni lato server intensive, la tua scelta di hosting diventa fondamentale per ridurre il TTFB sul campo.

Quando scegli un provider host, tieni in considerazione i seguenti aspetti:

• Quanta memoria è allocata l'istanza dell'applicazione? Se la tua applicazione ha una memoria insufficiente, si disattiverà e avrà difficoltà a pubblicare le pagine il più velocemente possibile.
• Il tuo provider host mantiene aggiornato lo stack di backend? Con il rilascio di nuove versioni dei linguaggi di backend dell'applicazione, delle implementazioni HTTP e del software di database, le prestazioni di tale software saranno migliorate nel tempo. È fondamentale collaborare con un provider host che dà la priorità a questo tipo di manutenzione fondamentale.
• Se hai requisiti delle applicazioni molto specifici e vuoi il livello più basso di accesso ai file di configurazione del server, chiedi se ha senso personalizzare il backend della tua istanza dell'applicazione.

Esistono molti provider host che si occuperanno di tutto questo per te, ma se inizi a osservare valori TTFB lunghi anche nei provider host dedicati, potrebbe essere necessario rivalutare le funzionalità del tuo attuale provider host in modo da offrire la migliore esperienza utente possibile.

Utilizzo di una rete CDN (Content Delivery Network)

L'argomento Utilizzo di CDN è ormai ampiamente utilizzato, ma per una buona ragione: potresti avere un backend dell'applicazione ottimizzato molto bene, ma gli utenti che si trovano lontano dal server di origine potrebbero comunque riscontrare un numero elevato di TTFB sul campo.

Le reti CDN risolvono il problema della vicinanza degli utenti dal tuo server di origine utilizzando una rete distribuita di server che memorizzano nella cache le risorse su server fisicamente più vicini ai tuoi utenti. Questi server sono chiamati server periferici.

I provider CDN possono anche offrire vantaggi oltre i server periferici:

• I provider CDN di solito offrono tempi di risoluzione DNS estremamente rapidi.
• È probabile che una rete CDN pubblichi i contenuti da server perimetrali utilizzando protocolli moderni come HTTP/2 o HTTP/3.
• In particolare, HTTP/3 risolve il problema di blocco di head-of-line presente in TCP (su cui si basa HTTP/2) utilizzando il protocollo UDP.
• È probabile che una rete CDN fornisca anche versioni moderne di TLS, che riducono la latenza associata ai tempi di negoziazione TLS. In particolare, TLS 1.3 è progettato per mantenere la negoziazione TLS il più breve possibile.
• Alcuni provider CDN forniscono una funzionalità spesso chiamata "edge worker", che utilizza un'API simile a quella dell'API Service Worker per intercettare le richieste, gestire in modo programmatico le risposte nelle cache perimetrali o riscrivere le risposte del tutto.
• I provider CDN sono molto bravi a ottimizzare la compressione. La compressione è difficile da fare in modo autonomo e può comportare tempi di risposta più lenti in alcuni casi con un markup generato dinamicamente, che deve essere compresso al volo.
• I provider CDN inoltre memorizzano automaticamente nella cache le risposte compresse per le risorse statiche, ottenendo la migliore combinazione di rapporto di compressione e tempo di risposta.

Sebbene l'adozione di una rete CDN richieda molto lavoro, da banale a significativo, dovrebbe essere una delle priorità per l'ottimizzazione del TTFB se il tuo sito web non ne utilizza già una.

Utilizzo di contenuti memorizzati nella cache ove possibile

Le reti CDN consentono di memorizzare nella cache i contenuti su server perimetrali che si trovano fisicamente più vicino ai visitatori, a condizione che i contenuti vengano configurati con le intestazioni HTTP Cache-Control appropriate. Sebbene non sia appropriato per i contenuti personalizzati, richiedere un viaggio fino all'origine può annullare gran parte del valore di una rete CDN.

Per i siti che aggiornano spesso i propri contenuti, anche un breve periodo di memorizzazione nella cache può comportare miglioramenti significativi delle prestazioni per i siti molto occupati, poiché solo il primo visitatore durante quel periodo sperimenta la latenza completa sul server di origine, mentre tutti gli altri visitatori possono riutilizzare la risorsa memorizzata nella cache dal server perimetrale. Alcune CDN consentono l'annullamento della convalida della cache sulle release del sito consentendo il meglio di entrambi i mondi: tempi di cache lunghi, ma aggiornamenti istantanei quando necessario.

Anche se la memorizzazione nella cache è configurata correttamente, questo può essere ignorato mediante l'uso di parametri di stringa di query univoci per la misurazione dell'analisi. Questi contenuti potrebbero apparire diversi rispetto alla rete CDN nonostante siano gli stessi, quindi la versione memorizzata nella cache non verrà utilizzata.

Inoltre, i contenuti meno recenti o meno visitati potrebbero non essere memorizzati nella cache, il che può comportare valori del TTFB più elevati su alcune pagine rispetto ad altre. L'aumento dei tempi di memorizzazione nella cache può ridurre l'impatto di questa situazione, ma tieni presente che con l'aumento dei tempi di memorizzazione nella cache aumentano le possibilità di pubblicare contenuti potenzialmente inattivi.

L'impatto dei contenuti memorizzati nella cache non riguarda solo chi utilizza le reti CDN. Se i contenuti memorizzati nella cache non possono essere riutilizzati, potrebbe essere necessario generare contenuti da costose ricerche nel database. I dati a cui si accede più di frequente o le pagine pre-memorizzate nella cache possono spesso funzionare meglio.

Evita reindirizzamenti di più pagine

Un fattore che contribuisce spesso a un TTFB elevato sono i reindirizzamenti. I reindirizzamenti si verificano quando una richiesta di navigazione per un documento riceve una risposta che informa il browser che la risorsa esiste in un'altra posizione. Un reindirizzamento può certamente aggiungere latenza indesiderata a una richiesta di navigazione, ma può peggiorare se il reindirizzamento rimanda a un'altra risorsa che genera un altro reindirizzamento e così via. Questo può influire in particolare sui siti che ricevono elevati volumi di visitatori da annunci o newsletter, poiché spesso effettuano il reindirizzamento tramite servizi di analisi a fini di misurazione. L'eliminazione dei reindirizzamenti sotto il tuo controllo diretto può aiutarti a ottenere una buona sintesi vocale.

Esistono due tipi di reindirizzamenti:

• Reindirizzamenti della stessa origine, in cui il reindirizzamento avviene interamente sul tuo sito web.
• Reindirizzamenti multiorigine, in cui il reindirizzamento avviene inizialmente su un'altra origine, ad esempio da un servizio di abbreviazione di URL di social media, prima di arrivare al tuo sito web.

Dovresti concentrare l'attenzione sull'eliminazione dei reindirizzamenti dalla stessa origine, poiché sarà un aspetto su cui potrai controllare direttamente. Potresti controllare i link sul tuo sito web per vedere se uno di essi genera un codice di risposta 302 o 301. Spesso questo può derivare dalla mancata inclusione dello schema https:// (per cui i browser vengono impostati in modo predefinito su http://, che in seguito esegue il reindirizzamento) o perché le barre finali non sono incluse o escluse in modo appropriato nell'URL.

I reindirizzamenti multiorigine sono più complessi in quanto spesso sfuggono al tuo controllo, ma cerca di evitare più reindirizzamenti se possibile, ad esempio utilizzando più abbreviatori di link durante la condivisione dei link. Assicurati che l'URL fornito a inserzionisti o newsletter sia l'URL finale corretto, in modo da non aggiungere un altro reindirizzamento a quelli utilizzati da tali servizi.

Un'altra importante fonte di tempo di reindirizzamento può provenire dai reindirizzamenti da HTTP a HTTPS. Un modo per risolvere questo problema è utilizzare l'intestazione Strict-Transport-Security (HSTS), che forzerà l'applicazione del protocollo HTTPS durante la prima visita a un'origine, dopodiché comunicherà al browser di accedere immediatamente all'origine tramite lo schema HTTPS durante le visite future.

Una volta implementato un criterio HSTS efficace, puoi velocizzare le operazioni durante la prima visita a un'origine aggiungendo il tuo sito all'elenco di precaricamento HSTS.

Trasmetti il markup al browser

I browser sono ottimizzati per elaborare il markup in modo efficiente quando viene trasmesso in streaming, il che significa che il markup viene gestito in blocchi quando arriva dal server. Questo è fondamentale per i payload di markup di grandi dimensioni, in quanto significa che il browser può analizzare i blocchi di markup in modo incrementale, invece di attendere l'intera risposta prima che l'analisi possa iniziare.

Sebbene i browser siano ottimi nella gestione del markup dei flussi di dati, è fondamentale fare tutto il possibile per garantire il flusso dello stream in modo che i bit iniziali del markup vengano inviati il prima possibile. Se il backend rallenta, esiste un problema. Poiché gli stack di backend sono numerosi, non sarebbe compreso nell'ambito di questa guida trattare ogni singolo stack e i problemi che potrebbero sorgere in ciascuno di essi.

Ad esempio, React e altri framework in grado di eseguire il rendering del markup on demand sul server hanno utilizzato un approccio sincrono al rendering lato server. Tuttavia, versioni più recenti di React hanno implementato metodi server per il markup dei flussi di dati durante il rendering. Ciò significa che non devi attendere un metodo API React Server per eseguire il rendering dell'intera risposta prima che venga inviata.

Un altro modo per garantire che il markup venga trasmesso rapidamente al browser consiste nell'utilizzare il rendering statico, che genera file HTML durante la creazione. Con l'intero file disponibile immediatamente, i server web possono iniziare a inviare il file immediatamente e la natura intrinseca di HTTP determina il markup di flussi di dati. Sebbene questo approccio non sia adatto a tutte le pagine di tutti i siti web, ad esempio quelle che richiedono una risposta dinamica per garantire l'esperienza utente, può essere utile per le pagine che non richiedono il markup per essere personalizzate per un utente specifico.

Utilizza un service worker

L'API Service Worker può avere un grande impatto sulla TTFB sia per i documenti sia per le risorse che caricano. Il motivo è che un service worker agisce da proxy tra il browser e il server, ma l'impatto sul TTFB del sito web dipende da come viene configurato e dal fatto che questa configurazione sia in linea con i requisiti dell'applicazione.

• Utilizza una strategia di riconvalida in caso di inattività per le risorse. Se un asset si trova nella cache del service worker (si tratta di un documento o di una risorsa richiesta dal documento), la strategia di riconvalida in caso di inattività durerà per prima la risorsa dalla cache, dopodiché scaricherà l'asset in background e lo pubblicherà dalla cache per le interazioni future.
  • Se disponi di risorse dei documenti che non cambiano molto spesso, l'utilizzo di una strategia di riconvalida "inattiva" può rendere quasi istantaneo il TTFB di una pagina. Tuttavia, questo non funziona molto bene se il tuo sito web invia markup generato dinamicamente, ad esempio un markup che cambia a seconda che l'utente sia autenticato. In questi casi, dovrai sempre contattare per primo la rete, in modo che il documento sia il più aggiornato possibile.
  • Se il documento carica risorse non critiche che cambiano con una certa frequenza, ma il recupero di risorse inattive non avrà effetti significativi sull'esperienza utente (ad esempio immagini selezionate o altre risorse non fondamentali), il TTFB di queste risorse può essere ridotto notevolmente utilizzando una strategia di riconvalida durante il periodo di inattività.
• Se possibile, utilizza un'architettura del service worker di streaming. Questa architettura dei service worker utilizza un approccio in cui parti di una risorsa documento vengono archiviate nella cache del service worker e combinate con i contenuti parziali durante la richiesta di navigazione. L'utilizzo di questo pattern del service worker ne deriva che la navigazione sarà piuttosto veloce, mentre i payload HTML più piccoli vengono scaricati dalla rete. Sebbene questo pattern del service worker non funzioni per tutti i siti web, il tempo di TTFB per le risorse del documento può essere praticamente istantaneo per i siti che possono utilizzarlo.
• Utilizza il modello shell dell'app per le applicazioni sottoposte a rendering dal client. Questo modello è ideale per le SPA, in cui la "shell" della pagina può essere distribuita immediatamente dalla cache del service worker e i contenuti dinamici della pagina vengono compilati e visualizzati in un secondo momento nel ciclo di vita della pagina.

Usa 103 Early Hints per le risorse critiche per il rendering

Indipendentemente da quanto sia efficace il backend dell'applicazione, il server potrebbe comunque richiedere una quantità significativa di lavoro per preparare una risposta, incluso lavoro di database costoso (ma necessario) che ritarda la risposta alla navigazione dall'arrivo il più velocemente possibile. Il potenziale effetto di ciò è che alcune risorse successive critiche per il rendering potrebbero subire ritardi, ad esempio CSS o, in alcuni casi, JavaScript che esegue il rendering del markup sul client.

L'intestazione 103 Early Hints è un codice di risposta iniziale che il server può inviare al browser mentre il backend è impegnato nella preparazione del markup. Questa intestazione può essere utilizzata per suggerire al browser che sono presenti risorse critiche per il rendering del file di pagina in attesa di essere scaricato durante la preparazione del markup. Per i browser supportati, l'effetto può essere un rendering più veloce dei documenti (CSS) e una disponibilità più rapida della funzionalità di base della pagina (JavaScript).

Conclusione

Poiché ci sono così tante combinazioni di stack di applicazioni di backend, non esiste un articolo che possa racchiudere tutto ciò che puoi fare per ridurre il TTFB del tuo sito web. Tuttavia, ecco alcune opzioni che puoi esplorare per provare a velocizzare le operazioni sul lato server.

Come per l'ottimizzazione di ogni metrica, l'approccio è molto simile: misura il tuo TTFB sul campo, utilizza gli strumenti di un lab per approfondire le cause e, se possibile, applica le ottimizzazioni. Non tutte le tecniche indicate qui possono essere valide per la tua situazione, ma alcune sì. Come sempre, dovrai tenere sotto controllo i dati sul campo e apportare le modifiche necessarie per garantire l'esperienza utente più rapida possibile.

Immagine hero di Taylor Vick, proveniente da Unsplash.