Ottimizza il tempo per il primo byte

Scopri come eseguire l'ottimizzazione in base alla metrica Time to First Byte.

Jeremy Wagner

Barry Pollard

Il tempo di risposta (TTFB) è una metrica di base sulle prestazioni web che precede tutte le altre metriche significative sull'esperienza utente, come First Contentful Paint (FCP) e Largest Contentful Paint (LCP). Ciò significa che valori TTFB elevati aggiungono tempo alle metriche che li seguono.

Ti consigliamo di configurare il server in modo che risponda alle richieste di navigazione abbastanza rapidamente da garantire al 75° percentile degli utenti un FCP entro la soglia "buona". Come guida approssimativa, la maggior parte dei siti dovrebbe cercare di avere un TTFB di 0,8 secondi o meno.

Come misurare il TTFB

Prima di poter ottimizzare il tempo di risposta del server, devi osservare in che modo influisce sugli utenti del tuo sito web. Devi fare affidamento sui dati sul campo come fonte principale per osservare il tempo di risposta del browser influenzato dai reindirizzamenti, mentre gli strumenti basati su laboratorio vengono spesso misurati utilizzando l'URL finale, quindi non tengono conto di questo ritardo aggiuntivo.

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

Il tempo di risposta del server (TTFB) per gli utenti reali viene mostrato nella sezione Scopri com'è l'esperienza dei tuoi utenti reali in alto:

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

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

Esegui il debug di un TTFB elevato sul campo con Server-Timing

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

Serving-Timing può essere utilizzato per misurare molti processi di backend delle applicazioni, ma alcuni potrebbero richiedere un'attenzione particolare:

• Query sul database
• Tempo di rendering lato server, se applicabile
• Ricerche sul disco
• Hit/mancate hit della cache del server 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 la lingua scelta per il backend dell'applicazione. In PHP, ad esempio, puoi impostare l'intestazione nel seguente 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 - $dbReadStartTime) / 1e+6;

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

Quando questa intestazione è impostata, vengono visualizzate informazioni che puoi utilizzare sia nel lab sia sul campo.

Nel campo, qualsiasi pagina con un'intestazione di risposta Server-Timing impostata comporterà il completamento della 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 laboratorio, i dati dell'intestazione di risposta Server-Timing verranno visualizzati nel riquadro dei tempi della scheda Rete in Chrome DevTools:

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

Una volta stabilito che il tempo di risposta del browser è problematico analizzando i dati disponibili, puoi passare alla risoluzione del problema.

Modi per ottimizzare il tempo di risposta del browser

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

Indicazioni specifiche per la piattaforma

La piattaforma che utilizzi per il tuo sito web può influire notevolmente sul tempo di risposta del server. Ad esempio, le prestazioni di WordPress sono influenzate dal numero e dalla qualità dei plug-in o dai temi utilizzati. Altre piattaforme sono interessate in modo simile quando la piattaforma è personalizzata. Per consigli specifici del fornitore, consulta la documentazione della tua piattaforma per integrare i consigli più generali sul rendimento riportati in questo post. Il controllo 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 altri approcci di ottimizzazione, l'hosting dovrebbe essere la prima cosa da valutare. Non è possibile fornire molte indicazioni specifiche, ma una regola generale è assicurarti che l'host del tuo sito web sia in grado di gestire il traffico che gli invii.

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

Tuttavia, se utilizzi un'applicazione più grande con molti utenti che prevede personalizzazione, query sul database e altre operazioni lato server intensive, la scelta dell'hosting diventa fondamentale per ridurre il TTFB sul campo.

Ecco alcuni aspetti da tenere in considerazione quando scegli un provider host:

• Quanta memoria è allocata all'istanza dell'applicazione? Se la tua applicazione non dispone di memoria sufficiente, avrà difficoltà a pubblicare le pagine il più rapidamente possibile.
• Il tuo provider di hosting mantiene aggiornato lo stack di backend? Man mano che vengono rilasciate nuove versioni di linguaggi di backend delle applicazioni, implementazioni HTTP e software di database, le prestazioni di questo software miglioreranno nel tempo. È fondamentale collaborare con un provider di hosting che dia la priorità a questo tipo di manutenzione fondamentale.
• Se hai requisiti di applicazione molto specifici e vuoi l'accesso al livello più basso ai file di configurazione del server, chiedi se ha senso personalizzare il backend della tua istanza dell'applicazione.

Esistono molti fornitori di hosting che si occupano di questi aspetti per te, ma se inizi a osservare valori TTFB lunghi anche in fornitori di hosting dedicati, potrebbe essere un segno che potresti dover rivalutare le funzionalità del tuo attuale provider di hosting per offrire la migliore esperienza utente possibile.

Utilizza una rete CDN (Content Delivery Network)

L'argomento utilizzo della CDN è molto dibattuto, ma per una buona ragione: potresti avere un backend dell'applicazione molto ottimizzato, ma gli utenti lontani dal tuo server di origine potrebbero comunque riscontrare un TTFB elevato sul campo.

Le 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 agli utenti. Questi server sono chiamati server edge.

I provider di CDN possono offrire vantaggi anche oltre gli edge server:

• I fornitori di CDN in genere offrono tempi di risoluzione DNS estremamente rapidi.
• È probabile che una CDN pubblichi i tuoi contenuti da edge server utilizzando protocolli moderni come HTTP/2 o HTTP/3.
• In particolare, HTTP/3 risolve il problema di blocco della prima richiesta presente in TCP (su cui si basa HTTP/2) utilizzando il protocollo UDP.
• Una CDN fornirà probabilmente anche versioni moderne di TLS, che riducono la latenza del tempo di negoziazione TLS. TLS 1.3, in particolare, è progettato per mantenere la negoziazione TLS il più breve possibile.
• Alcuni fornitori di 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 di confine o riscriverle del tutto.
• I fornitori di CDN sono molto bravi a ottimizzare per la compressione. La compressione è difficile da ottenere correttamente autonomamente e potrebbe comportare tempi di risposta più lenti in alcuni casi con markup generato dinamicamente, che deve essere compresso in tempo reale.
• I fornitori di CDN memorizzano inoltre automaticamente nella cache le risposte compresse per le risorse statiche, ottenendo il miglior rapporto tra rapporto di compressione e tempo di risposta.

Sebbene l'adozione di una CDN richieda un impegno variabile, da trascurabile a significativo, l'ottimizzazione del TTFB dovrebbe essere una priorità assoluta se il tuo sito web non ne utilizza già una.

Utilizza i contenuti memorizzati nella cache, se possibile

Le CDN consentono di memorizzare nella cache i contenuti su server perimetrali fisicamente più vicini ai visitatori, a condizione che i contenuti siano configurati con le Cache-Control intestazioni HTTP appropriate. Sebbene 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 molto frequentati, poiché solo il primo visitatore durante questo periodo di tempo sperimenta la latenza completa fino al server di origine, mentre tutti gli altri visitatori possono riutilizzare la risorsa memorizzata nella cache dal server edge. Alcune CDN consentono l'invalidazione della cache nelle release del sito, offrendo il meglio di entrambi i mondi: tempi di cache lunghi, ma aggiornamenti istantanei in caso di necessità.

Anche se la memorizzazione nella cache è configurata correttamente, può essere ignorata tramite l'utilizzo di parametri della stringa di query univoci per la misurazione di Analytics. Per la CDN potrebbero sembrare contenuti diversi, anche se sono gli stessi, 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. Aumentare i tempi di memorizzazione nella cache può ridurre l'impatto di questo problema, ma tieni presente che con l'aumento dei tempi di memorizzazione nella cache aumenta la possibilità di pubblicare contenuti potenzialmente obsoleti.

L'impatto dei contenuti memorizzati nella cache non riguarda solo chi utilizza le CDN. L'infrastruttura del server potrebbe dover generare contenuti da ricerche nel database costose quando i contenuti memorizzati nella cache non possono essere riutilizzati. I dati a cui si accede più di frequente o le pagine memorizzate nella cache possono spesso avere un rendimento migliore.

Evita i reindirizzamenti tra più pagine

Un fattore comune che contribuisce a un TTFB elevato è rappresentato dai redirect. 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. Ciò può influire in modo particolare sui siti che ricevono elevati volumi di visitatori da annunci o newsletter, poiché spesso vengono reindirizzati tramite servizi di analisi per scopi di misurazione. L'eliminazione dei reindirizzamenti sotto il tuo controllo diretto può contribuire a ottenere un buon TTFB.

Esistono due tipi di reindirizzamenti:

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

Devi concentrarti sull'eliminazione dei reindirizzamenti della stessa origine, perché è un aspetto su cui hai il controllo diretto. Dovrai controllare i link sul tuo sito web per verificare se uno di questi genera un codice di risposta 302 o 301. Spesso questo può essere il risultato della mancata inclusione dello schema https:// (per cui i browser utilizzano per impostazione predefinita http://, che poi reindirizza) o perché le barre finali non sono incluse o escluse in modo appropriato nell'URL.

I reindirizzamenti tra origini sono più complicati in quanto spesso non sono sotto il 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 questi servizi.

Un'altra importante fonte di tempo di reindirizzamento può derivare dai reindirizzamenti da HTTP a HTTPS. Un modo per aggirare il problema è utilizzare l'intestazione Strict-Transport-Security (HSTS), che impone HTTPS alla prima visita a un'origine e poi indica al browser di accedere immediatamente all'origine tramite lo schema HTTPS nelle visite future.

Una volta impostato un criterio HSTS valido, puoi velocizzare la prima visita a un'origine aggiungendo il tuo sito all'elenco di precaricamento HSTS.

Eseguire lo streaming del markup nel 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 man mano che arriva dal server. Questo è fondamentale per i payload di markup di grandi dimensioni, in quanto il browser può analizzare i blocchi di markup in modo incrementale, anziché attendere l'arrivo dell'intera risposta prima che possa iniziare l'analisi.

Sebbene i browser siano molto bravi a gestire il markup in streaming, è fondamentale fare tutto il possibile per mantenere attivo lo stream in modo che i bit iniziali di markup vengano inviati il prima possibile. Se il backend rallenta, è un problema. Poiché gli stack di backend sono numerosi, non rientra nell'ambito di questa guida trattare ogni singolo stack e i problemi che potrebbero sorgere in ogni caso specifico.

React, ad esempio, e altri framework che possono 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 del server per lo streaming del markup durante il rendering. Ciò significa che non devi attendere che un metodo dell'API server React visualizzi l'intera risposta prima che venga inviata.

Un altro modo per assicurarti che il markup venga trasmesso rapidamente al browser è fare affidamento sul rendering statico, che genera file HTML durante la compilazione. Con il file completo disponibile immediatamente, i server web possono iniziare a inviarlo immediatamente e la natura intrinseca di HTTP comporterà lo streaming del markup. Sebbene questo approccio non sia adatto a tutte le pagine di ogni sito web, ad esempio quelle che richiedono una risposta dinamica nell'ambito dell'esperienza utente, può essere utile per le pagine che non richiedono la personalizzazione del markup per un utente specifico.

Utilizzare un worker di servizio

L'API Service Worker può avere un grande impatto sul TTFB sia per i documenti sia per le risorse che caricano. Il motivo è che un worker di servizio funge da proxy tra il browser e il server, ma l'impatto sul TTFB del tuo sito web dipende da come configuri il worker di servizio e se questa configurazione è in linea con i requisiti dell'applicazione.

• Utilizza una strategia di aggiornamento dei dati non validi per le risorse. Se una risorsa si trova nella cache del service worker, che si tratti di un documento o di una risorsa richiesta dal documento, la strategia stale-while-revalidate la servirà prima dalla cache, quindi la scaricherà in background e la servirà dalla cache per le interazioni future.
  • Se hai risorse di documenti che non cambiano molto spesso, l'utilizzo di una strategia di aggiornamento durante la convalida può rendere il TTFB di una pagina quasi istantaneo. Tuttavia, questo non funziona molto bene se il tuo sito web invia markup generato dinamicamente, ad esempio markup che cambia in base all'autenticazione di un utente. In questi casi, ti consigliamo sempre di pubblicare il documento prima sulla rete, in modo che sia il più aggiornato possibile.
  • Se il documento carica risorse non critiche che cambiano con una certa frequenza, ma il recupero della risorsa obsoleta 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 di convalida in stato di attesa.
• Utilizza il modello di shell dell'app per le applicazioni con rendering lato client. Questo modello è più adatto alle SPA in cui la "shell" della pagina può essere caricata 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.

Utilizza 103 Early Hints per le risorse fondamentali per il rendering

Indipendentemente dall'ottimizzazione del backend dell'applicazione, il server potrebbe dover svolgere una quantità significativa di lavoro per preparare una risposta, inclusi operazioni costose (ma necessarie) sul database che ritardano l'arrivo della risposta di navigazione il più rapidamente possibile. Il potenziale effetto di questo è che alcune risorse fondamentali per il rendering successivo 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 anticipato che il server può inviare al browser mentre il backend è impegnato a preparare il markup. Questa intestazione può essere utilizzata per suggerire al browser che esistono risorse fondamentali per il rendering che la pagina deve iniziare a scaricare durante la preparazione del markup. Per i browser supportati, l'effetto può essere una visualizzazione più rapida dei documenti (CSS) e una disponibilità più rapida delle funzionalità di base della pagina (JavaScript).

Conclusione

Poiché esistono così tante combinazioni di stack di applicazioni di backend, non esiste un articolo che possa descrivere tutto ciò che puoi fare per ridurre il TTFB del tuo sito web. Tuttavia, ecco alcune opzioni che puoi esplorare per provare ad accelerare un po' le cose lato server.

Come per l'ottimizzazione di ogni metrica, l'approccio è in gran parte simile: misura il TTFB sul campo, utilizza gli strumenti di laboratorio per esaminare in dettaglio le cause e poi applica le ottimizzazioni, se possibile. Non tutte le tecniche riportate potrebbero essere valide per la tua situazione, ma alcune lo saranno. Come sempre, dovrai tenere d'occhio i dati sul campo e apportare le modifiche necessarie per garantire un'esperienza utente il più rapida possibile.

Immagine hero di Taylor Vick, tratta da Unsplash.