Caricamenti delle pagine più rapidi grazie al momento di riflessione del server con i suggerimenti anticipati

Scopri come il tuo server può inviare suggerimenti al browser su risorse secondarie critiche.

Kenji Baheux
Kenji Baheux

Cosa sono i suggerimenti iniziali?

I siti web sono diventati più sofisticati nel tempo. Pertanto, non è insolito che un server debba eseguire operazioni non banali (ad esempio l'accesso ai database o le CDN che accedono al server di origine) per produrre il codice HTML per la pagina richiesta. Sfortunatamente, questo "tempo di riflessione del server" si traduce in un'ulteriore latenza prima che il browser possa iniziare a eseguire il rendering della pagina. In effetti, la connessione rimane inattiva per tutto il tempo necessario al server per preparare la risposta.

Immagine che mostra un intervallo di tempo di 200 ms tra il caricamento della pagina e quello di altre risorse.
Senza Early Hints: tutto viene bloccato sul server che determina la modalità di risposta per la risorsa principale.

Early Hints è un codice di stato HTTP (103 Early Hints) utilizzato per inviare una risposta HTTP preliminare prima di una risposta finale. Ciò consente a un server di inviare suggerimenti al browser su risorse secondarie critiche (ad esempio, foglio di stile per la pagina, JavaScript critico) o origini che verranno probabilmente utilizzate dalla pagina mentre il server è occupato a generare la risorsa principale. Il browser può utilizzare questi suggerimenti per il riscaldamento delle connessioni e la richiesta di risorse secondarie, in attesa della risorsa principale. In altre parole, i suggerimenti iniziali aiutano il browser a sfruttare il "tempo di riflessione del server" svolgendo del lavoro in anticipo, velocizzando così il caricamento delle pagine.

Immagine che mostra in che modo i suggerimenti iniziali consentono alla pagina di inviare una risposta parziale.
Con i suggerimenti iniziali: il server può fornire una risposta parziale con suggerimenti sulle risorse mentre determina la risposta finale

In alcuni casi, il miglioramento delle prestazioni di Largest Contentful Paint può passare da diverse centinaia di millisecondi, come osservato da Shopify e da Cloudflare, fino a un secondo più veloce, come si vede in questo confronto prima/dopo:

Confronto tra due siti.
Confronto prima/dopo i suggerimenti iniziali su un sito web di test eseguito con WebPageTest (Moto G4 - DSL)

Implementazione dei suggerimenti iniziali

Prima di approfondire l'argomento, tieni presente che i suggerimenti iniziali non sono utili se il tuo server può inviare subito un codice 200 (o altre risposte finali). In questi casi, valuta l'utilizzo di un valore normale link rel=preload o link rel=preconnect nella risposta principale (intestazione HTTP link rel) o nella risposta principale (elementi <link>). Per i casi in cui il server ha bisogno di un po' di tempo per generare la risposta principale, continua a leggere.

Il primo passaggio per sfruttare i primi suggerimenti consiste nell'identificare le pagine di destinazione principali, ovvero le pagine da cui in genere i tuoi utenti iniziano quando visitano il tuo sito web. Potrebbe essere la home page o le pagine delle schede di prodotto più popolari se hai molti utenti che provengono da altri siti web. Il motivo per cui questi punti di ingresso sono più importanti di altre pagine è perché l'utilità di Early Hints diminuisce man mano che l'utente naviga nel tuo sito web (in altre parole, è più probabile che il browser abbia tutte le risorse secondarie necessarie nella seconda o terza navigazione successiva). Inoltre, è sempre una buona idea pubblicare un'ottima prima impressione.

Ora che hai questo elenco di pagine di destinazione prioritarie, il passaggio successivo consiste nell'identificare le origini o le risorse secondarie che potrebbero essere ideali per i suggerimenti di preconnessione o precaricamento, come prima approssimazione. In genere, si tratta di origini e risorse secondarie che contribuiscono maggiormente alle metriche utente chiave, come Largest Contentful Paint o First Contentful Paint. Più concretamente, cerca risorse secondarie che bloccano la visualizzazione, ad esempio codice JavaScript sincrono, fogli di stile o persino caratteri web. Allo stesso modo, cerca le origini che ospitano risorse secondarie che contribuiscono molto alle metriche utente chiave. Nota: se le tue risorse principali utilizzano già <link rel=preconnect> o <link rel=preload>, puoi considerare queste origini o risorse tra i candidati per i suggerimenti iniziali. Per ulteriori dettagli, consulta questo articolo.

Il secondo passaggio consiste nel ridurre al minimo il rischio di utilizzare i suggerimenti iniziali su risorse o origini che potrebbero essere obsolete o non più utilizzate dalla risorsa principale. Ad esempio, le risorse che vengono aggiornate di frequente e sottoposte a controllo delle versioni (ad esempio example.com/css/main.fa231e9c.css) potrebbero non essere la scelta migliore. Tieni presente che questo problema non è specifico per i suggerimenti iniziali, ma si applica a qualsiasi link rel=preload o rel=preconnect ovunque possano essere presenti. Questo è il tipo di dettaglio più adeguato all'automazione o alla creazione di modelli (ad esempio, un processo manuale ha maggiori probabilità di generare errori di hash o di versioni tra link rel=preload e il tag HTML effettivo che utilizza la risorsa).

Prendiamo come esempio il flusso riportato di seguito:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Il server prevede che sarà necessario main.abcd100.css e suggerisce di precaricarlo tramite i suggerimenti iniziali:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Pochi istanti dopo, viene pubblicata la pagina web, incluso il CSS collegato. Purtroppo questa risorsa CSS viene aggiornata di frequente e la risorsa principale ha già cinque versioni (abcd105) in anticipo rispetto alla risorsa CSS prevista (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

In generale, punta a risorse e origini abbastanza stabili e in gran parte indipendenti dal risultato della risorsa principale. Se necessario, puoi prendere in considerazione l'idea di suddividere le risorse della chiave in due: una parte stabile progettata per essere utilizzata con i suggerimenti iniziali e una parte più dinamica da recuperare dopo che il browser ha ricevuto la risorsa principale:

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Infine, sul lato server, cerca le richieste di risorse principali inviate dai browser noti per supportare i primi suggerimenti e rispondi immediatamente con 103 Early Hints. Nella risposta 103, includi i suggerimenti di preconnessione e precaricamento pertinenti. Quando la risorsa principale è pronta, ripeti la risposta consueta (ad esempio, 200 OK in caso di esito positivo). Per la compatibilità con le versioni precedenti, è buona norma includere anche le intestazioni HTTP Link nella risposta finale, magari aggiungendo anche risorse critiche che sono diventate evidenti nell'ambito della generazione della risorsa principale (ad esempio, la parte dinamica di una risorsa chiave se hai seguito il suggerimento "diviso in due"). Ecco l'aspetto che potrebbe avere:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Qualche istante dopo:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Supporto del browser

Sebbene 103 Early Hints sia supportato in tutti i principali browser, le istruzioni che possono essere inviate con un Early Hint variano in base al browser:

Assistenza per il precollegamento:

Supporto dei browser

  • 103
  • 103
  • 120
  • 17

Precarica l'assistenza:

Supporto dei browser

  • 103
  • 103
  • x

Assistenza per server

Di seguito è riportato un breve riepilogo del livello di supporto per Early Hints tra i più diffusi software per server HTTP OSS:

Abilitare i suggerimenti iniziali in modo semplice

Se utilizzi una delle seguenti piattaforme o CDN, potrebbe non essere necessario implementare manualmente i suggerimenti iniziali. Consulta la documentazione online del tuo provider di soluzioni per sapere se supporta Early Hints o fai riferimento all'elenco non esaustivo qui:

Come evitare problemi per i client che non supportano Early Hints

Le risposte HTTP informative nell'intervallo di 100 fanno parte dello standard HTTP, ma alcuni client o bot meno recenti potrebbero avere difficoltà a utilizzarli perché, prima del lancio di 103 Early Hints, venivano utilizzati raramente per la navigazione generale del web.

L'emissione di 103 Early Hints solo in risposta ai client che inviano un'intestazione della richiesta HTTP sec-fetch-mode: navigate dovrebbe garantire che i suggerimenti vengano inviati solo ai client più recenti che comprendono di attendere la risposta successiva. Inoltre, poiché i primi suggerimenti sono supportati solo per le richieste di navigazione (vedi le limitazioni attuali), questo ha il vantaggio aggiuntivo di evitare l'invio inutile su altre richieste.

Inoltre, consigliamo di inviare i primi suggerimenti solo tramite connessioni HTTP/2 o HTTP/3.

Pattern avanzato

Se hai applicato completamente i suggerimenti iniziali alle tue pagine di destinazione chiave e ti ritrovi a cercare altre opportunità, potrebbe interessarti il seguente pattern avanzato.

Per i visitatori che si trovano alla loro nesima richiesta di pagina nell'ambito di un tipico percorso dell'utente, puoi adattare la risposta dei suggerimenti iniziali a contenuti più in basso e più profondi nella pagina, in altre parole utilizzando i suggerimenti iniziali per risorse con priorità inferiore. Questo potrebbe sembrare controintuitivo, dato che consigliamo di concentrarsi su sottorisorse o origini ad alta priorità che bloccano la visualizzazione. Tuttavia, quando un visitatore naviga da un po' di tempo, è molto probabile che il suo browser disponga già di tutte le risorse fondamentali. Da questo momento in poi, potrebbe avere senso distogliere l'attenzione dalle risorse con priorità più bassa. Ad esempio, questo potrebbe significare utilizzare i suggerimenti iniziali per caricare le immagini dei prodotti o codici JS/CSS aggiuntivi necessari solo per le interazioni meno comuni degli utenti.

Limitazioni attuali

Ecco le limitazioni della funzionalità Early Hints implementata in Chrome:

  • Disponibile solo per le richieste di navigazione (ovvero la risorsa principale per il documento di primo livello).
  • Supporta solo preconnect e preload (vale a dire, prefetch non è supportato).
  • Early Hint seguito da un reindirizzamento multiorigine nella risposta finale comporterà l'eliminazione delle risorse e delle connessioni ottenute tramite Early Hints.

Altri browser hanno limitazioni simili e limitano ulteriormente i primi 103 suggerimenti solo a preconnect.

Passaggi successivi

A seconda dell'interesse della community, potremmo ampliare l'implementazione di Early Hints con le seguenti funzionalità:

  • I primi suggerimenti inviati per le richieste di risorse secondarie.
  • Suggerimenti iniziali inviati per le richieste di risorse principali iframe.
  • Supporto del precaricamento nei suggerimenti iniziali.

Apprezziamo il tuo feedback su quali aspetti dare la priorità e come migliorare ulteriormente i suggerimenti iniziali.

Relazione con H2/Push

Se hai dimestichezza con la funzionalità HTTP2/Push deprecata, potresti chiederti in cosa differiscono i primi suggerimenti. Mentre Early Hints richiede un round trip per consentire al browser di iniziare a recuperare le risorse secondarie critiche, con HTTP2/Push il server potrebbe iniziare a eseguire il push delle risorse secondarie insieme alla risposta. Anche se sembra incredibile, ciò ha comportato un importante svantaggio strutturale: con HTTP2/Push era estremamente difficile evitare di inserire risorse secondarie già esistenti nel browser. Questo effetto di "sovra spinta" ha comportato un utilizzo meno efficiente della larghezza di banda della rete, il che ha ostacolato in modo significativo i vantaggi in termini di prestazioni. Nel complesso, i dati di Chrome hanno mostrato che HTTP2/Push era in effetti un netto negativo per le prestazioni sul web.

Al contrario, i suggerimenti iniziali hanno prestazioni migliori in pratica perché combinano la capacità di inviare una risposta preliminare con suggerimenti che lasciano al browser il compito di recuperare o connettersi a ciò di cui ha effettivamente bisogno. Sebbene Early Hints non riguardi tutti i casi d'uso che HTTP2/Push potrebbe affrontare in teoria, riteniamo che Early Hints sia una soluzione più pratica per accelerare le navigazioni.

Immagine in miniatura di Pierre Bamin.