Ogni volta che un browser chiede una pagina, c’è un momento in cui non succede nulla. La richiesta è partita, il server la sta elaborando, interroga il database, esegue il codice dell’applicazione, compone l’HTML. Il browser aspetta. Solo quando riceve la risposta scopre quali fogli di stile, font e immagini servono per mostrare la pagina, e comincia a scaricarli. Su un sito con cache di pagina questo intervallo dura poche decine di millisecondi; su pagine dinamiche, come carrello, area riservata o risultati di ricerca, può durare centinaia di millisecondi, a volte più di un secondo.
Early Hints, il codice di stato HTTP 103, serve a sfruttare questo tempo morto. Il server, o la CDN davanti a lui, può inviare subito una risposta preliminare che dice al browser: mentre preparo la pagina, comincia a scaricare queste risorse, perché ti serviranno. Quando arriva la risposta vera, le risorse critiche sono già in arrivo o già scaricate.
Come funziona il codice 103
I codici di stato della famiglia 1xx sono risposte informative: non concludono la richiesta, ma possono precederne la risposta definitiva. Il 103 Early Hints contiene uno o più header Link, con la stessa sintassi usata per il preload e il preconnect. Una sequenza tipica è questa:
HTTP/2 103
link: </wp-content/themes/tema/style.css>; rel=preload; as=style
link: </wp-content/themes/tema/fonts/plex.woff2>; rel=preload; as=font; crossorigin
link: <https://cdn.esempio.it>; rel=preconnect
HTTP/2 200
content-type: text/html; charset=UTF-8
link: </wp-content/themes/tema/style.css>; rel=preload; as=style
<!doctype html>…Il browser, ricevuto il 103, avvia subito il download del foglio di stile e del font e apre la connessione verso il dominio indicato. Poi continua ad attendere la risposta 200, che arriva quando il server ha finito. A quel punto, le risorse annunciate sono già disponibili o a buon punto, e il browser può costruire e disegnare la pagina senza la solita catena di attese.
Perché non basta il preload nell’HTML
Un <link rel="preload"> nell’intestazione HTML ha lo stesso scopo, ma un limite evidente: il browser lo legge solo quando riceve l’HTML, cioè dopo che il server ha finito il suo lavoro. Il preload accelera la scoperta delle risorse rispetto a quando verrebbero trovate nel CSS o più in basso nel documento, ma non può anticiparla rispetto alla risposta stessa. Early Hints sposta questo momento all’inizio della richiesta, prima che il server abbia prodotto anche un solo byte della pagina.
È stato proposto come erede di HTTP/2 Server Push, il meccanismo con cui il server poteva inviare risorse al browser senza che le chiedesse. Il push si è rivelato difficile da usare bene, perché il server non sapeva quali risorse il browser avesse già in cache e finiva per inviare dati inutili; Chrome lo ha rimosso nel 2022. Early Hints lascia invece la decisione al browser: il server suggerisce, il browser scarica solo ciò che non ha già, usando la propria cache.
Quando conviene davvero
Il beneficio di Early Hints è proporzionale al tempo di attesa del server. Se una pagina arriva dalla cache con un TTFB di 40 millisecondi, non c’è quasi nessun tempo morto da sfruttare, e il guadagno è trascurabile. Se una pagina richiede 600 millisecondi di elaborazione, il browser può usarli per scaricare fogli di stile, font e perfino l’immagine principale, e il guadagno sull’LCP può essere di diverse centinaia di millisecondi.
I casi più favorevoli sono quindi le pagine che non possono essere messe in cache: carrello e checkout di un e-commerce, aree riservate, pagine personalizzate, risultati di ricerca interna, pagine con parametri. Sono anche pagine importanti per il business, e spesso le più lente del sito. Per le pagine già servite dalla cache, Early Hints è un piccolo miglioramento; per quelle dinamiche, può essere uno dei pochi interventi possibili senza riscrivere l’applicazione.
Un esempio concreto
Immaginiamo la pagina del carrello di un negozio online, che non può essere messa in cache e che il server genera in circa 700 millisecondi, tra sessione, calcolo dei prezzi, spedizioni e prodotti consigliati. Senza Early Hints, il browser resta inattivo per tutto questo tempo; poi riceve l’HTML, scopre il foglio di stile principale, lo scarica in 150 millisecondi su una rete mobile, scopre il font, lo scarica, e finalmente disegna. L’LCP arriva dopo oltre un secondo, anche se il testo e le miniature dei prodotti sono leggerissimi.
Con un 103 che annuncia foglio di stile e font, il browser li scarica durante i 700 millisecondi di elaborazione. Quando arriva l’HTML, ha già tutto ciò che serve per disegnare, e l’LCP si avvicina molto al TTFB. Il server non è diventato più veloce, ma la pagina appare prima di qualche centinaio di millisecondi, proprio nel punto del percorso d’acquisto in cui l’utente è più vicino a concludere, come abbiamo visto parlando delle Core Web Vitals per WooCommerce.
Chi può inviarlo: la CDN in prima fila
Inviare un 103 significa rispondere prima di avere la risposta, e questo non è banale per molte applicazioni. PHP, per esempio, nella configurazione tradizionale con PHP-FPM, non ha un modo semplice per inviare una risposta informativa e poi continuare a elaborare la pagina. Per questo il modo più diffuso di usare Early Hints passa per la CDN.
Alcune CDN, come Cloudflare, adottano un approccio elegante: osservano gli header Link con rel=preload o rel=preconnect presenti nelle risposte 200 dell’origine, li memorizzano per quella URL e, alle richieste successive, li inviano subito al browser come 103, mentre inoltrano la richiesta all’origine. Il sito non deve fare altro che includere gli header Link nelle proprie risposte e attivare la funzione nel pannello della CDN.
Anche alcuni server web supportano l’invio di Early Hints: Apache, con il modulo HTTP/2, può trasformare in 103 gli header Link configurati, e altri server e ambienti applicativi moderni offrono funzioni dedicate. Il supporto resta però meno uniforme di quello delle CDN, e va verificato caso per caso.
Il caso WordPress
Su WordPress l’approccio più pratico è aggiungere gli header Link alle risposte HTML e lasciare alla CDN il compito di anticiparli. Il foglio di stile principale del tema e il font più usato sopra la piega sono i candidati ideali, perché sono gli stessi su tutte le pagine:
add_action(
'send_headers',
function () {
if ( is_admin() ) {
return;
}
$tema = get_template_directory_uri();
header( "Link: <{$tema}/style.css>; rel=preload; as=style", false );
header( "Link: <{$tema}/fonts/plex.woff2>; rel=preload; as=font; crossorigin", false );
}
);Le URL devono corrispondere esattamente a quelle usate nella pagina, compresi eventuali parametri di versione come ?ver=1.2: se differiscono, il browser scarica due volte la stessa risorsa. Per questo conviene generare gli header con le stesse funzioni che il tema usa per registrare gli stili, oppure affidarsi a plugin di ottimizzazione che li producono automaticamente in modo coerente.
Cosa annunciare e cosa no
Early Hints è uno strumento da usare con parsimonia. Ogni risorsa annunciata compete per la banda con le altre, e annunciare troppo equivale a non dare priorità a nulla. Alcune regole pratiche:
- Il CSS critico, sempre. Il foglio di stile che blocca il rendering è il candidato migliore: senza di esso la pagina non può essere disegnata.
- Uno o due font. Quelli usati nel testo sopra la piega, nel formato WOFF2, meglio se già ridotti con il subsetting.
- Preconnect ai domini critici. La CDN delle immagini o un dominio di terze parti indispensabile al primo disegno. Un preconnect costa poco e fa risparmiare i viaggi di apertura della connessione.
- L’immagine LCP solo se è la stessa. Una copertina che cambia da pagina a pagina non può essere annunciata da una CDN che memorizza gli header per URL solo dopo la prima visita; ha senso per un’immagine fissa, come quella di una home.
- Niente script non critici. Anticipare il download di JavaScript che verrà eseguito dopo non accelera il primo disegno e sottrae banda a ciò che serve.
Gli errori più comuni
Il primo errore è l’URL non coincidente. Se l’header annuncia style.css e la pagina carica style.css?ver=6.8, per il browser sono due risorse diverse: la prima viene scaricata e poi ignorata, la seconda viene richiesta di nuovo. Il risultato è peggiore che non usare Early Hints, perché si spreca banda nel momento più delicato del caricamento. I DevTools lo segnalano con un avviso di risorsa precaricata ma non utilizzata entro pochi secondi.
Il secondo errore riguarda i font: il preload di un font richiede l’attributo crossorigin, anche quando il font è sullo stesso dominio, perché i font vengono sempre richiesti in modalità CORS. Senza, il browser scarica il font due volte. Il terzo è annunciare risorse diverse da quelle realmente necessarie, per esempio dopo un aggiornamento del tema che ha cambiato nomi o percorsi dei file: gli header restano quelli vecchi, e la CDN continua ad anticipare file che la pagina non usa più. Dopo ogni modifica strutturale conviene quindi ricontrollare che le risorse annunciate e quelle usate coincidano.
Infine, Early Hints non va confuso con una soluzione ai problemi del server. Se una pagina impiega due secondi a essere generata, anticipare CSS e font migliora la situazione, ma l’utente vede comunque una pagina bianca finché l’HTML non arriva. Il lavoro sul TTFB, con cache di pagina, cache degli oggetti e ottimizzazione delle query, resta la priorità; Early Hints è il complemento che recupera il tempo che non si riesce a eliminare.
Supporto dei browser
Chrome ed Edge supportano Early Hints per il preload e il preconnect nelle richieste di navigazione, su connessioni HTTP/2 e HTTP/3. Firefox lo supporta nelle versioni recenti; Safari supporta il preconnect ma, al momento della scrittura, non il preload tramite 103. I browser che non lo supportano ignorano la risposta informativa e attendono la risposta definitiva, come sempre: anche in questo caso, come per le Speculation Rules, si tratta di un miglioramento progressivo senza effetti negativi per chi non ne beneficia.
Come verificare
Nei DevTools di Chrome, le risorse scaricate grazie a Early Hints mostrano nel pannello Network un iniziatore dedicato, e l’API Resource Timing le segnala con initiatorType uguale a early-hints. È il modo più affidabile per verificare che gli header arrivino davvero al browser e che le URL coincidano con quelle usate dalla pagina:
performance.getEntriesByType( 'resource' )
.filter( ( r ) => r.initiatorType === 'early-hints' )
.forEach( ( r ) => console.log( r.name, Math.round( r.responseEnd ) ) );Da riga di comando, curl -I con un’URL servita dalla CDN mostra le eventuali risposte 103 prima della 200. Per misurare l’effetto, conviene confrontare TTFB e LCP delle pagine dinamiche prima e dopo l’attivazione, con dati di campo o con un sistema di monitoraggio degli utenti reali: sulle pagine in cache la differenza sarà piccola, su quelle dinamiche dovrebbe essere evidente.
In sintesi
Early Hints permette al server, o più spesso alla CDN, di dire al browser quali risorse critiche scaricare mentre la pagina è ancora in preparazione. Trasforma il tempo di attesa del server in tempo utile, e il beneficio cresce con la lentezza della pagina: modesto per le pagine in cache, rilevante per carrello, checkout, aree riservate e pagine personalizzate.
Si attiva con pochi header Link ben scelti e una CDN che li trasformi in 103; va limitato alle risorse davvero critiche, con URL identiche a quelle della pagina, e verificato con i DevTools. Non sostituisce una cache efficiente né un server veloce, ma quando la pagina non può essere più veloce da generare, è uno dei modi migliori per far sì che l’attesa non vada sprecata.
