fetchpriority non è un preload

fetchpriority dice al browser quanto sta a cuore una risorsa rispetto alle altre dello stesso tipo. rel="preload" è un’altra cosa: è un fetch obbligatorio, fatto presto, con la priorità di default di quel tipo di risorsa. Uno non sostituisce l’altro. Non è la bfcache, non è la cache HTTP, e non è il passaggio da FID a INP. Rilettura del 17 ottobre 2026: HTML living standard, sezione «Fetch priority attributes», e web.dev/articles/fetch-priority, pagina aggiornata il 14 novembre 2023 UTC.

In breve: i valori sono high, low e auto. Manca l’attributo, o il valore non è valido: lo standard ricade su auto. È un hint. Il preload non lo è. Su un’immagine LCP che il parser già vede, il preload in cima all’head spesso basta. Su un’immagine di sfondo CSS, che il parser non vede, servono tutti e due.

Due strumenti, due lavori

web.dev, nella nota di implementazione, separa le due frasi. Il preload fa scoprire una risorsa prima, e la scarica con la priorità di default. Fetch Priority non aiuta la scoperta: alza o abbassa la priorità del fetch, quando il fetch c’è. Il preload è «a mandatory fetch, not a hint». L’attributo è «a hint, not a directive»: il browser prova a rispettarlo e può applicare le proprie regole se vanno in conflitto.

Lo stesso articolo ricorda il nome vecchio. Nel 2018 e poi nel 2021 Chrome lo provò come origin trial con l’attributo importance, sotto il nome Priority Hints. Nello standard è diventato fetchpriority in HTML e priority nel Fetch API. Chi cerca ancora importance="high" sta leggendo l’esperimento, non l’attributo di oggi.

Il cluster è Performance. Il confronto fra laboratorio e campo, che è un altro pezzo, sta in Lighthouse e CrUX.

high, low, auto

Lo standard elenca tre keyword. high: fetch ad alta priorità rispetto alle altre risorse con la stessa destinazione. low: il contrario, sempre rispetto alla stessa destinazione. auto: la decisione automatica. Se l’attributo manca, o se il valore non è uno di questi tre, lo stato è auto. Non esiste, nello standard, un quarto gradino da inventare.

web.dev traduce l’effetto pratico così. high chiede una priorità più alta del solito, se le euristiche del browser non lo impediscono. low chiede di abbassarla, con lo stesso limite. auto lascia scegliere il browser, ed è il default.

L’attributo sta su link, img e script, per CSS, font, script e immagini scaricati da quei tag. Il fetch() non usa l’attributo: usa la proprietà priority, con gli stessi nomi. Un preload può portare l’attributo, ed è il caso in cui i due strumenti stanno sulla stessa riga: <link rel="preload" href="/js/script.js" as="script" fetchpriority="low">. Si chiede di scoprirlo presto e di non farlo competere con il resto.

Non fissa la priorità in assoluto

web.dev è esplicito: Fetch Priority imposta una priorità relativa. Alza o abbassa il default «by an appropriate amount», non scrive «High» o «Low» come valore assoluto. Spesso il risultato è quello. Non sempre.

Il CSS critico con fetchpriority="high" resta a Very High o Highest. Lo stesso CSS con fetchpriority="low" resta High. In nessuno dei due casi la pagina dice che la priorità sia stata fissata su High o su Low. Un foglio di stile il cui media non coincide non passa dallo scanner di preload: lo prende il parser quando ci arriva, e resta tardi anche con fetchpriority="high".

Sulle immagini la stessa pagina, aggiornata il 14 novembre 2023, scrive una sequenza che non ho rimisurato il 17 ottobre 2026. Di default partono Low e, a layout fatto, salgono a High se sono nel viewport. Da Chrome 117 le prime cinque immagini grandi partono Medium, e due di queste possono essere scaricate in parallelo nel «tight mode» iniziale. Con fetchpriority="high" nel markup, un’immagine importante parte High subito. È lo stato di quella pagina, non un test di oggi su Chrome corrente.

Un preload con as="style" usa la priorità Highest, perché prende la priorità della destinazione. Senza as, un fetch è trattato come un XHR asincrono. «Early», nella tabella di web.dev, vuol dire: chiesto prima di qualunque immagine non precaricata. «Late» è dopo.

Quando vanno insieme

Se l’immagine LCP è già un <img> e il preload è tra le prime righe dell’head, un high in più può non spostare il LCP in modo visibile. Se il preload arriva dopo altre risorse, il high conta di più. Se l’immagine LCP è uno sfondo CSS, il parser non la vede: va precaricata, e il preload va marcato fetchpriority="high". Il preload da solo la scopre con la priorità di default delle immagini, che in quella tabella è Low o Medium.

I precaricamenti di font, scrive la pagina, stanno meglio verso la fine dell’head o all’inizio del body. Un preload messo negli header HTTP parte prima di tutto il documento. I preload di priorità Medium o superiore seguono in genere l’ordine in cui il parser li incontra. Metterne una fila in cima all’HTML, senza un perché, li fa competere fra loro.

Il guadagno si vede dove le risorse si contendono la banda: HTTP/1.x, dove i download paralleli non ci sono, oppure HTTP/2 e HTTP/3 su una rete lenta. Le CDN, avvisa la stessa pagina, non applicano la priorità HTTP/2 in modo uniforme, e lo stesso vale per HTTP/3. Il browser può mandare la priorità e la CDN può non rispettarla. Resta l’effetto interno: il browser tiene indietro le risorse basse, per esempio le immagini, mentre lavora sull’head. Per questo la pagina dice che vale la pena usarlo anche se l’origine non riordina i byte.

Errori da evitare

• Sostituire un preload con fetchpriority="high" e credere di aver anticipato la scoperta. Lo hint non scopre nulla.

• Preloadare tutto ciò che è già un tag nel documento. Il preload serve a ciò che il parser non vede: font, import, sfondi LCP.

• Aspettarsi che low su un CSS critico lo mandi in fondo alla coda. In quella pagina resta High.

• Scrivere fetchpriority dentro fetch(). Lì la chiave è priority.

• Trattare la riga su Chrome 117 come una misura del 17 ottobre 2026. Sta su una pagina ferma al 14 novembre 2023.

• Dare per scontato che la CDN riordini le risposte perché il browser ha mandato la priorità.

In sintesi

fetchpriority ha tre valori, high, low e auto, ed è un hint relativo alle risorse della stessa destinazione. Il preload è un fetch obbligatorio e non cambia, da solo, la priorità di default. Insieme servono quando la risorsa va scoperta prima e va anche fatta pesare di più, o di meno: lo sfondo LCP è il caso che la pagina di web.dev scrive per esteso. Lo standard, riletto il 17 ottobre 2026, non ha aggiunto un quarto valore.

Foto di copertina: Martin Vorel, «Programming code», Wikimedia Commons, CC BY-SA 4.0. È uno schermo di codice, non un grafico di priorità misurato oggi.