Ottimizza il tempo per il primo byte

Scopri come ottimizzare in base alla metrica Tempo per primo byte.

Jeremy Wagner

Barry Pollard

Time to First Byte (TTFB) è una metrica di base sul rendimento 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 aggiungono tempo alle metriche che seguono.

È consigliabile che il server risponda alle richieste di navigazione abbastanza rapidamente, in modo che il 75° percentile degli utenti rilevi un valore FCP entro la soglia "buona". In linea di massima, la maggior parte dei siti dovrebbe cercare di avere una 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 affidarti ai dati sul campo come fonte principale per osservare il TTFB in quanto interessato dai reindirizzamenti, mentre gli strumenti basati su lab vengono spesso misurati utilizzando l'URL finale, per cui manca questo ulteriore ritardo.

PageSpeed Insights è un modo per ottenere informazioni sia sul campo che sui lab per i siti web pubblici disponibili nel Report sull'esperienza utente di Chrome.

La TTFB per gli utenti reali viene mostrata nella sezione Scopri l'esperienza degli utenti reali in alto:

Nel controllo del tempo di risposta del server viene mostrato un sottoinsieme di TTFB:

Per scoprire altri modi per misurare la TTFB sia sul campo che in laboratorio, consulta la pagina della metrica TTFB.

Esegui il debug di un TTFB elevata sul campo 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 almeno un handle definito da te. I valori facoltativi includono un valore della durata (tramite dur) e una descrizione facoltativa leggibile (tramite desc).

Serving-Timing può essere utilizzato per misurare molti processi di backend dell'applicazione, ma ne potresti voler prestare particolare attenzione:

• Query database
• Tempo di rendering lato server, se applicabile
• Ricerche disco
• Hit/mancate della cache perimetrale (se utilizzi una 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 il linguaggio preferito del backend dell'applicazione. Ad esempio, in PHP, puoi 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à le informazioni che puoi utilizzare sia nel lab sia nel campo.

Nel campo, qualsiasi pagina con un'intestazione di risposta Server-Timing impostata completerà la 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 dei tempi della scheda Rete in Chrome DevTools:

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

Dopo aver determinato la presenza di una TTFB problematica analizzando i dati disponibili, puoi passare alla risoluzione del problema.

Modi per ottimizzare TTFB

L'aspetto più impegnativo dell'ottimizzazione del TTFB è che, mentre lo stack di frontend del web sarà sempre HTML, CSS e JavaScript, gli stack di backend possono variare in modo significativo. Esistono numerosi prodotti di database e stack di backend, ognuno con le proprie tecniche di ottimizzazione. Pertanto, questa guida si concentrerà su ciò che si applica alla maggior parte delle architetture, piuttosto che concentrarsi esclusivamente su indicazioni specifiche per lo stack.

Indicazioni specifiche per piattaforma

La piattaforma che utilizzi per il tuo sito web può avere un impatto significativo sul TTFB. Ad esempio, le prestazioni di WordPress sono influenzate dal numero e dalla qualità dei plug-in o dai temi utilizzati. La personalizzazione della piattaforma ha un impatto simile su altre piattaforme. Ti consigliamo di consultare la documentazione della tua piattaforma per consigli specifici del fornitore al fine di integrare i consigli più generali sul rendimento riportati in questo post. Il controllo di Lighthouse per la riduzione dei tempi di risposta del server include anche alcune indicazioni limitate specifiche per lo stack.

Hosting, hosting, hosting

Prima di prendere in considerazione anche altri approcci all'ottimizzazione, l'hosting dovrebbe essere la prima cosa da prendere in considerazione. Non è possibile fornire indicazioni specifiche in merito, 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 è un problema e alcune delle tecniche di ottimizzazione che seguono ti aiuteranno a ridurre il più possibile il TTFB.

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

Quando scegli un provider host, tieni presente quanto segue:

• Quanta memoria è allocata l'istanza dell'applicazione? Se la tua applicazione non dispone di memoria sufficiente, avrà difficoltà a pubblicare le pagine il più velocemente possibile.
• Il provider host mantiene aggiornato lo stack di backend? Man mano che vengono rilasciate nuove versioni dei linguaggi di backend delle applicazioni, delle implementazioni HTTP e del software di database, le prestazioni di questi software verranno migliorate nel tempo. È fondamentale collaborare con un provider host che dia 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 di applicazione.

Esistono molti provider host che si occupano di queste cose, ma se inizi a osservare valori TTFB lunghi anche nei provider host dedicati, potrebbe essere necessario rivalutare le capacità del tuo attuale provider host in modo da poter offrire la migliore esperienza utente possibile.

Utilizza una rete CDN (Content Delivery Network)

L'argomento Utilizzo CDN è molto frequente, ma per una buona ragione: il backend dell'applicazione potrebbe essere molto ben ottimizzato, ma gli utenti che si trovano lontano dal server di origine potrebbero comunque riscontrare un TTFB elevata sul campo.

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

I provider CDN possono anche offrire vantaggi oltre ai server perimetrali:

• I provider CDN di solito offrono tempi di risoluzione DNS estremamente rapidi.
• Una rete CDN probabilmente pubblicherà i tuoi contenuti da server perimetrali utilizzando protocolli moderni come HTTP/2 o HTTP/3.
• HTTP/3 in particolare risolve il problema del blocco head-of-line presente in TCP (su cui si basa HTTP/2) utilizzando il protocollo UDP.
• Una rete CDN probabilmente fornirà anche versioni moderne di TLS, il che riduce la latenza del tempo di negoziazione di TLS. In particolare, TLS 1.3 è progettato per garantire che la negoziazione TLS sia il più breve possibile.
• Alcuni provider CDN offrono una funzionalità spesso chiamata "lavoratore perimetrale", 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 nell'ottimizzazione per la compressione. La compressione è difficile da eseguire correttamente e, in alcuni casi, può portare a tempi di risposta più lenti con il markup generato dinamicamente, che deve essere compresso al volo.
• Inoltre, i provider CDN memorizzano automaticamente nella cache le risposte compresse per le risorse statiche, in modo da ottenere la migliore combinazione di rapporto di compressione e tempo di risposta.

Sebbene l'adozione di una CDN richieda una quantità di lavoro variabile da banale a significativa, se il tuo sito web non ne utilizza già una, dovrebbe essere una priorità elevata da perseguire per ottimizzare il tuo TTFB.

Utilizzo di contenuti memorizzati nella cache, ove possibile

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

Per i siti che aggiornano di frequente i contenuti, anche un breve tempo di memorizzazione nella cache può comportare notevoli miglioramenti delle prestazioni per i siti affollati, poiché solo il primo visitatore in quel periodo di tempo sperimenta la completa latenza nel server di origine, mentre tutti gli altri visitatori possono riutilizzare la risorsa memorizzata nella cache dall'edge server. Alcune CDN consentono l'invalidazione della cache sulle release del sito consentendo il meglio di entrambe le modalità: tempi lunghi della cache, ma aggiornamenti istantanei quando necessario.

Anche se la memorizzazione nella cache è configurata correttamente, questo può essere ignorato mediante l'uso di parametri univoci della stringa di query per la misurazione analitica. Questi contenuti potrebbero avere lo stesso aspetto della rete CDN, pertanto 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 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 si aumenta la possibilità di fornire contenuti potenzialmente obsoleti.

L'impatto dei contenuti memorizzati nella cache non riguarda solo gli utenti che utilizzano le reti CDN. L'infrastruttura server potrebbe dover generare contenuti da costose ricerche nei database quando i contenuti memorizzati nella cache non possono essere riutilizzati. I dati a cui si accede con maggiore frequenza o le pagine prememorizzate nella cache possono spesso avere un rendimento migliore.

Evita i reindirizzamenti tra più pagine

Un fattore comune a un TTFB elevata 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 questo 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 pubblicità o newsletter, in quanto spesso reindirizzano tramite servizi di analisi a fini di misurazione. Eliminare i reindirizzamenti sotto il tuo controllo diretto può aiutarti a ottenere un buon TTFB.

Esistono due tipi di reindirizzamenti:

• Reindirizzamenti della stessa origine, in cui il reindirizzamento si verifica 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.

Ti consigliamo di concentrarti sull'eliminazione dei reindirizzamenti della stessa origine, poiché si tratta di qualcosa su cui avrai il controllo diretto. Devi controllare i link sul tuo sito web per vedere se uno di questi genera un codice di risposta 302 o 301. Spesso questo può dipendere dal mancato inclusione dello schema https:// (quindi per impostazione predefinita dei browser http://, che esegue poi il reindirizzamento) o dal fatto che le barre finali non vengono incluse o escluse in modo appropriato nell'URL.

I reindirizzamenti multiorigine sono più complessi in quanto spesso esulano dal tuo controllo, ma cerca di evitare più reindirizzamenti se possibile, ad esempio utilizzando più abbreviatori di link quando condividi i link. Assicurati che l'URL fornito agli inserzionisti o alle newsletter sia l'URL finale corretto, in modo da non aggiungere un altro reindirizzamento a quelli utilizzati da quei servizi.

Un'altra importante fonte di tempo di reindirizzamento può provenire dai reindirizzamenti da HTTP a HTTPS. Un modo per aggirare questo problema è utilizzare l'intestazione Strict-Transport-Security (HSTS), che applica HTTPS alla prima visita a un'origine, quindi dirà al browser di accedere immediatamente all'origine tramite lo schema HTTPS per le visite future.

Una volta stabilito un criterio HSTS valido, puoi velocizzare le operazioni in occasione della 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 durante lo streaming, vale a dire che il markup viene gestito in blocchi quando arriva dal server. Questo è fondamentale se sono interessati 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'arrivo dell'intera risposta prima che l'analisi possa iniziare.

Sebbene i browser siano in grado di gestire in modo eccellente il markup dei flussi di dati, è fondamentale fare tutto il possibile per far sì che lo streaming continui in modo che le parti iniziali del markup vengano trasferite il prima possibile. Se il backend regge le cose, questo è un problema. Poiché gli stack di backend sono numerosi, non rientra nell'ambito di questa guida trattare tutti i singoli 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, le versioni più recenti di React hanno implementato metodi server per il markup dei flussi durante il rendering. Ciò significa che non devi attendere che un metodo dell'API React Server esegua il rendering dell'intera risposta prima che venga inviata.

Un altro modo per garantire che il markup venga trasmesso al browser rapidamente è utilizzare il rendering statico, che genera file HTML durante la creazione. Quando il file completo è disponibile immediatamente, i server web possono iniziare a inviarlo immediatamente e la natura intrinseca di HTTP comporterà il markup dello streaming. Sebbene questo approccio non sia adatto a ogni pagina di ogni sito web, ad esempio per quelle che richiedono una risposta dinamica come parte dell'esperienza utente, può essere utile per le pagine che non richiedono la personalizzazione del markup per un utente specifico.

Utilizza un service worker

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

• Usa una strategia inattiva durante la riconvalida delle risorse. Se un asset si trova nella cache del Service worker, che si tratti di un documento o di una risorsa richiesta dal documento, la strategia stale-while-reconfirm gestirà quella risorsa dalla cache prima, quindi scaricherà l'asset in background e lo pubblicherà dalla cache per le interazioni future.
  • Se disponi di risorse di documenti che non cambiano molto spesso, l'utilizzo di una strategia di tipo inattivo durante la riconvalida può rendere il TTFB di una pagina quasi istantaneo. Tuttavia, questa soluzione non funziona così bene se il tuo sito web invia un markup generato dinamicamente, ad esempio un markup che cambia a seconda che l'utente sia autenticato o meno. In questi casi, ti consigliamo di contattare prima 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 della risorsa inattiva non influisce notevolmente sull'esperienza utente, ad esempio immagini selezionate o altre risorse non critiche, il TTFB per queste risorse può essere notevolmente ridotto utilizzando una strategia inattiva durante la riconvalida.
• Utilizza il modello shell dell'app per le applicazioni sottoposte a rendering client. Questo modello è ideale per le APS in cui lo "shell" della pagina può essere distribuito istantaneamente dalla cache del service worker e il contenuto dinamico della pagina viene compilato e visualizzato 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 efficiente il backend dell'applicazione, potrebbe comunque esserci una notevole quantità di lavoro che il server deve svolgere per preparare una risposta, tra cui un lavoro costoso (ma necessario) del database che ritarda l'arrivo della risposta di navigazione il più rapidamente possibile. Il potenziale effetto è che alcune risorse successive critiche per il rendering potrebbero subire ritardi, come il CSS o, in alcuni casi, JavaScript che esegue il rendering del markup sul client.

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

Conclusione

Dal momento che ci sono così tante combinazioni di stack di applicazioni di backend, non esiste un solo articolo in grado di incorporare tutto ciò che puoi fare per abbassare il TTFB del tuo sito web. Tuttavia, queste sono alcune opzioni che puoi valutare per provare a portare le cose un po' più velocemente sul lato server.

Come per l'ottimizzazione di ogni metrica, l'approccio è molto simile: misura il TTFB sul campo, utilizza strumenti di laboratorio per analizzare in dettaglio le cause e poi applica le ottimizzazioni, ove possibile. Non tutte le tecniche in questo caso possono essere attuabili per la tua situazione, ma alcune lo sono. Come sempre, dovrai tenere sotto controllo i dati sul campo e apportare le modifiche necessarie per garantire l'esperienza utente più veloce possibile.

Immagine hero di Taylor Vick, proveniente da Unsplash.