103 Early Hints: Precarica le risorse critiche durante il tempo di elaborazione del server

Ultima revisione di Arjen Karel a marzo 2026

Cosa sono i 103 Early Hints?

Early Hints è un codice di stato HTTP (103) inviato prima che il web server invii la risposta finale. Permette al server di dire al browser, all'inizio del processo di caricamento, che alcune risorse come un'immagine o un foglio di stile sono critiche per renderizzare la pagina.

La maggior parte delle pagine dinamiche richiede tempo per essere generata. Il server interroga un database, esegue la logica dell'applicazione e assembla l'HTML. Durante questo tempo di elaborazione il browser semplicemente aspetta. I 103 Early Hints riempiono questo vuoto dicendo al browser cosa scaricare mentre aspetta la risposta reale.

Gli Early Hints sostituiscono il deprecato HTTP/2 Server Push, che Chrome ha rimosso nella versione 106. Il Server Push raggruppava le risorse con la risposta finale e spesso inviava byte che il browser aveva già in cache. Gli Early Hints evitano questo problema perché forniscono solo un suggerimento; il browser decide se agire di conseguenza.

Supporto dei browser

I 103 Early Hints sono supportati dal 93% dei browser a livello globale:

• Chrome 103+ e Edge 103+: supporto completo per preconnect e preload (da giugno 2022)
• Firefox 123+: supporto completo per preconnect e preload (da febbraio 2024)
• Safari 17+: solo preconnect. Safari non supporta preload nelle risposte 103

La limitazione di Safari è importante. Se la tua strategia di Early Hints si basa interamente sul preload di immagini o font, gli utenti Safari non ne trarranno vantaggio. Includi hint di preconnect insieme agli hint di preload in modo che Safari almeno riscaldi la connessione alle origini delle tue risorse.

Gli Early Hints funzionano solo su HTTP/2 o HTTP/3. Non funzionano su HTTP/1.1, dagli iframe o per le richieste non di navigazione. Il browser elabora gli hint solo per preload e preconnect; dns-prefetch e prefetch non sono supportati nelle risposte 103.

Come si presentano i 103 Early Hints?

Quando un browser richiede una pagina, il server restituisce immediatamente una risposta 103 prima di aver finito di generare l'HTML. Questa risposta dice al browser di iniziare a scaricare l'immagine LCP e il foglio di stile:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Nel frattempo, il server genera la pagina. Una volta pronta, invia la risposta finale:

HTTP/2 200 OK
Content-Length: 1234
[il resto della risposta]

Quando il browser riceve la risposta 200, ha già iniziato a scaricare l'immagine e il foglio di stile. Questo vantaggio iniziale è ciò che rende il Largest Contentful Paint più veloce.

Come inviare i 103 Early Hints

Hai tre opzioni principali, dalla più semplice a quella con maggiore controllo.

Cloudflare (più semplice)

Se usi già Cloudflare per le performance, abilitare gli Early Hints richiede un solo toggle. Naviga su Speed > Settings > Content Optimization e attiva Early Hints. È disponibile su tutti i piani, incluso il livello gratuito.

Cloudflare mette in cache gli header Link dalle risposte 200 della tua origine. Nelle richieste successive, invia quegli header in cache come risposta 103 prima di inoltrare la richiesta alla tua origine. Fornisci gli hint inviando header Link dalla tua applicazione:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (nativo dalla versione 1.29.0)

NGINX ha aggiunto il supporto nativo per i 103 Early Hints nella versione 1.29.0 (giugno 2025). La direttiva early_hints inoltra le risposte 103 dal tuo backend al client:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

La map sec-fetch-mode assicura che gli hint vengano inviati solo per le richieste di navigazione su HTTP/2 o HTTP/3. La tua applicazione di backend deve generare la risposta 103; NGINX la lascia passare.

Apache (2.4.58+)

Apache può generare da solo le risposte 103 usando mod_http2. Abilitalo con la direttiva H2EarlyHints e definisci le risorse da suggerire:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

A differenza di NGINX, Apache genera la risposta 103 a livello di server senza bisogno che la tua applicazione la produca.

Quando gli Early Hints aiutano (e quando no)

I 103 Early Hints sono più efficaci quando il tuo server impiega un tempo notevole per rispondere: pagine dinamiche che interrogano database, chiamano API o renderizzano template. Più lento è il Time to First Byte, più tempo ha il browser per agire sugli hint.

Gli Early Hints offrono meno benefici quando:

• Il tuo server risponde in meno di 100ms. Se il TTFB è già veloce, non c'è nessun vuoto che il browser debba riempire. Concentrati invece sulla prioritizzazione delle risorse nel tuo HTML.
• Le pagine sono servite dalla cache. Una risposta HTML completamente in cache si carica così velocemente che la risposta 103 ha a malapena un vantaggio iniziale.
• Suggerisci troppe risorse. Suggerire oltre 10 risorse satura la connessione e può rallentare il caricamento. Shopify ha scoperto che sui dispositivi mobili, un hinting aggressivo portava a un degrado delle performance su TTFB, FCP e LCP. Limitati a 2 o 4 risorse critiche.

Nonostante il supporto del 93% dei browser, l'adozione rimane bassa. Secondo il Web Almanac 2025, solo circa il 5% dei siti principali usa i 103 Early Hints. L'ostacolo principale è sapere quali risorse suggerire per ogni pagina, qualcosa che la maggior parte dei CMS non gestisce automaticamente.

Come verificare che gli Early Hints funzionino

Apri i DevTools di Chrome, vai al pannello Network e ricarica la pagina. Clicca sulla richiesta del documento e controlla gli header di risposta. Se gli Early Hints funzionano, vedrai uno stato 103 prima del 200 nel dettaglio delle tempistiche.

Dalla riga di comando, puoi verificare con curl:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Dovresti vedere sia una risposta 103 che una 200.

Risultati dei test

Ho testato due scenari per misurare l'impatto sul First Contentful Paint e sul Largest Contentful Paint.

1. Early Hints solo sull'immagine LCP

L'immagine LCP è apparsa a schermo il 35% prima con i 103 Early Hints rispetto a un normale preload nell'HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints con un grande foglio di stile e l'immagine LCP

Aggiungere un file CSS di 85kb agli hint ha reso la differenza ancora più evidente. Il FCP è migliorato da 1,8 secondi a 1,4 secondi e il LCP è migliorato da 3,2 secondi a 2,0 secondi.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Questi numeri sono in linea con quanto Cloudflare ha misurato su oltre 100.000 clienti: un miglioramento del LCP del 6% al 50esimo percentile e del 16% al 75esimo percentile su desktop. Shopify ha registrato un miglioramento del LCP di 500ms al p50 durante il Black Friday e il Cyber Monday. I vantaggi maggiori si ottengono su pagine con tempi di risposta del server lenti, che è esattamente quando gli Early Hints hanno più tempo per funzionare.

Early Hints e TTFB

C'è un dettaglio di misurazione da tenere a mente. A partire da Chrome 133, la tempistica responseStart del browser (usata dalla maggior parte degli strumenti per riportare il TTFB) include la risposta 103. Questo significa che il tuo TTFB riportato scenderà dopo aver abilitato gli Early Hints, anche se l'effettivo tempo di elaborazione del tuo server non è cambiato.

Se hai bisogno di misurare il tempo di elaborazione del server separatamente, Chrome 133 ha introdotto un nuovo timestamp firstResponseHeadersStart che riporta quando arrivano gli header della risposta 200 finale. Gli strumenti di Real User Monitoring che tracciano entrambi i valori ti danno il quadro completo: quanto tempo gli Early Hints hanno fatto risparmiare al browser e quanto tempo ha effettivamente impiegato il tuo server per rispondere.