Il 22 ottobre 2026 uno status 103 non è la risposta della pagina. La guida Chrome Early Hints, pubblicata il 23 giugno 2022 e aggiornata il 10 luglio 2026, lo descrive come una risposta preliminare, mentre il server sta ancora generando il documento. RFC 8297, Kazuho Oku, dicembre 2017, categoria Experimental, dice la stessa cosa in forma di norma: i campi del 103 sono suggerimenti, non sostituiscono gli header della risposta finale. Non è un preload nell’HTML e non è l’attributo fetchpriority.
In breve: 103 Early Hints, informativo, prima del 200. In Chrome, stando alla sezione limitazioni della guida 2026, solo sulle navigazioni del documento principale, solo preconnect e preload, prefetch no. Se il server può mandare subito il 200, la guida dice di non usarlo. RFC 8297 resta Experimental. Non ho misurato un sito.
Il 103 non chiude la richiesta
La guida di Kenji Baheux e Barry Pollard parte dal «server think-time»: il tempo in cui l’origine, o una CDN che aspetta l’origine, non ha ancora l’HTML. Senza Early Hints la connessione resta ferma. Con il 103 il server manda prima alcuni header Link, e il browser può aprire connessioni o chiedere sottorisorse mentre aspetta il documento. Poi arriva la risposta finale, nell’esempio un 200 OK.
La nota in cima alla sezione «How to use» è netta. Se il server può inviare subito un 200, o un’altra risposta finale, Early Hints non serve. In quel caso la guida rimanda al preload o al preconnect normali, header Link sulla risposta principale oppure elementi link nell’HTML. Il 103 non è un modo più elegante di scrivere quei tag. È un anticipo, utile solo se c’è un’attesa.
RFC 8297, sezione 2, letta il 22 ottobre sul testo HTML dell’RFC Editor: il 103 indica che il server probabilmente manderà una risposta finale con gli header inclusi nell’informational. Di solito quegli header stanno anche nella finale. Possono però risultare sbagliati prima dell’invio finale, e allora non è desiderabile copiarli. Il client può valutarli in modo speculativo, per esempio un Link rel=preload, e iniziare a scaricare. «These header fields only provide hints to the client; they do not replace the header fields on the final response.» Fuori dalle ottimizzazioni di performance, quella valutazione MUST NOT cambiare il modo in cui si processa la finale. Il client MUST NOT trattare gli header del 103 come metadati del 103 stesso.
La stessa sezione: un server MAY mandare solo alcuni degli header attesi. Un client SHOULD NOT leggere l’assenza di un header nel 103 come il segnale che quell’header non starà nella finale. Manca, nella risposta anticipata, non significa «non arriverà».
Cosa dicono la guida e la RFC
| Domanda | Risposta nelle fonti lette il 22 ottobre 2026 |
|---|---|
| Il 103 è la pagina? | No. È preliminare. La finale arriva dopo, per esempio 200. |
| Sostituisce gli header finali? | No. RFC 8297: sono hint. La guida chiede di ripetere i Link anche sulla finale, per compatibilità. |
| Se il 200 è immediato? | La guida: Early Hints non è utile. Usare preload o preconnect sulla risposta vera. |
| Cosa si può anticipare, in Chrome? | La sezione limitazioni: solo preconnect e preload. Prefetch no. |
| Su quali richieste? | Solo navigazione, documento di primo livello. La guida suggerisce sec-fetch-mode: navigate anche per evitare client vecchi. |
| Stato della RFC | Experimental, dicembre 2017. Non è uno Standard Track. |
La guida avvisa che copiare di peso i preload dell’HTML dentro il 103 può non essere la scelta giusta. Nell’HTML si precarica ciò che lo scanner scopre tardi, per esempio un font. Nel 103 l’HTML non c’è ancora: ha più senso un preconnect a un dominio critico, o il preload di un CSS o di uno script che starebbero comunque in testa. Un file con hash che cambia spesso, nell’esempio main.abcd100.css contro il vero main.abcd105.css, è il caso in cui l’anticipo scarica la versione sbagliata. La guida suggerisce di spezzare: una parte stabile per l’hint, una parte dinamica dopo.
L’esempio di risposta, nella guida, è questo ordine e non un tag nel body: prima 103 con Link rel=preconnect e Link rel=preload; as=style e as=script; poi 200 con gli stessi Link, più un CSS sperimentale che il server ha scoperto solo generando l’HTML, e nel corpo i link e lo script veri. Non ho eseguito quella sequenza.
Dove la guida del 2026 si ferma
Limiti scritti per Chrome. Solo richieste di navigazione. Solo preconnect e preload. Se la finale è un redirect cross-origin, il browser butta risorse e connessioni ottenute con l’hint. Il preload finisce nella cache HTTP e la pagina lo rilegge da lì: se la risorsa non è cacheabile viene scaricata due volte. Con un certificato HTTPS non fidato la cache di Chrome è disattivata, anche se si prosegue. Immagini responsive con imagesrcset, imagesizes o media, via header Link, possono non partire finché il documento non esiste, perché il viewport non c’è ancora: a quel punto il vantaggio del 103 sparisce.
La guida dice che il 103 è supportato nei browser principali, ma che le direttive ammesse non coincidono. La tabella è fatta di icone e di numeri (per il preload compare anche una x). Nel testo estratto i nomi dei browser non stanno accanto alle cifre: non assegno io 103, 120 o 17 a Chrome, Firefox o Safari. In DevTools, per vedere le risorse Early Hints, «Disable cache» non deve essere attivo. L’initiator di un preload hintato è «Early-hints». Firefox, scrive la guida, non ha un initiator 103 esplicito: le risorse risultano cached e, al click, hanno l’header di richiesta X-Moz: early hint.
I client vecchi e i bot possono inciampare sulle risposte 1xx, rare prima del 103. La pratica consigliata in pagina: emettere il 103 solo se la richiesta ha sec-fetch-mode: navigate, e solo su HTTP/2 o HTTP/3. «Most browsers will only accept them over those protocols.» Server citati, senza che io li abbia provati: Apache con mod_http2, H2O, NGINX, Node per http e http2. CDN citate: Cloudflare, Fastly, Akamai. I millisecondi di LCP nominati (Shopify, Cloudflare, un prima/dopo WebPageTest su Moto G4) sono i casi della guida, non una misura di questo sito.
La RFC del 2017 parla anche di HTTP/2 server push come alternativa storica, con due limiti: solo risorse di cui il server è autorevole, e push anche se il client ha già la cache. Non aggiorno io lo stato del push nel 2026. La guida che ho letto il 22 ottobre non lo usa come ricetta. Non lo aggiungo.
Errori da evitare
Trattare il 103 come status finale. Il documento è il 200, o l’altra finale, che arriva dopo.
Togliere i Link dalla risposta finale perché «sono già nel 103». La RFC dice che gli hint non sostituiscono gli header finali. La guida li ripete.
Accendere Early Hints su un server che risponde subito. La guida dice che non serve.
Mettere un prefetch nel 103 e aspettarsi che Chrome lo onori. Nelle limitazioni Chrome: prefetch non è supportato.
Precaricare un CSS con hash che cambia a ogni build. L’esempio in guida scarica il file vecchio.
Leggere l’assenza di un header nel 103 come un «no». RFC 8297: SHOULD NOT.
Confonderlo con fetchpriority o con la bfcache. Sono altri meccanismi, già altrove su questo sito.
In sintesi
Il 22 ottobre 2026 Early Hints è lo status 103: una risposta informativa, Experimental in RFC 8297 (dicembre 2017), descritta da Chrome il 10 luglio 2026 come anticipo di preconnect e preload durante il think-time del server. Non è la pagina, non sostituisce gli header finali, non va usato se il 200 è immediato, e in Chrome non copre il prefetch né le richieste che non siano la navigazione del documento. I numeri di LCP in guida non sono una misura nuova. Il push del 2017 non l’ho promosso a pratica attuale.
Foto di copertina: sylvar, «Server room», Wikimedia Commons, CC BY 2.0. È una sala macchine, non un header Link e non uno status 103.
