Performance
preload, prefetch e fetchpriority: quale usare
preload anticipa una risorsa critica, prefetch prepara la pagina successiva, fetchpriority cambia l'ordine. Tre strumenti diversi, tre errori da evitare.
In sintesi
- preload serve alla pagina corrente, prefetch alla navigazione successiva, fetchpriority cambia la priorità di una richiesta già nel markup.
- La home del sito dichiara 5 preload, tutti font, misurati il 1 novembre 2026.
- Un preload senza crossorigin corretto scarica il font due volte.
preload scarica subito una risorsa che serve a questa pagina, prefetch prepara una risorsa per la pagina successiva, fetchpriority cambia la priorità di una richiesta già presente nell'HTML. Sono tre strumenti diversi e si sostituiscono male.
Le tre direttive in una tabella
| Direttiva | Cosa fa | Quando usarla |
|---|---|---|
rel="preload" | scarica subito con priorità alta | font, immagine LCP, CSS critico |
rel="prefetch" | scarica con priorità bassa, per dopo | la rotta successiva probabile |
fetchpriority | alza o abbassa la priorità di una richiesta presente | l'immagine LCP già nel markup |
L'errore uno: preload su tutto
Ogni preload compete con le altre richieste. Con cinque preload il browser li mette davanti al CSS e la pagina aspetta la risorsa sbagliata. Un preload non usato entro 3 secondi produce un avviso in console.
curl -s https://ui.eneawork.it/ | grep -o 'rel="preload"' | wc -l
Il comando conta i preload dichiarati nell'HTML servito. Sulla home il risultato è 5 e sono tutti font: nessuna immagine ha bisogno di un preload in più.
Il preload che scarica due volte
Un preload senza as, o con crossorigin diverso dal tag che lo riusa, produce due richieste. I font richiedono sempre crossorigin, anche quando arrivano dallo stesso dominio.
La prima riga anticipa il font. La seconda dichiara l'immagine LCP senza aggiungere una richiesta, perché il browser la trova comunque nel markup.
prefetch: quando conviene
prefetch consuma banda per una pagina che l'utente può non aprire. Usalo su una sola rotta con probabilità alta, per esempio il link ai prezzi dalla home, e mai su mobile con dati a consumo.
La limitazione
Queste direttive sono suggerimenti: il browser può ignorarle e cambiare priorità in base alla connessione e al viewport. Anche l'ordine HTTP/2 conta, quindi una priorità più alta nel markup non garantisce un arrivo prima.
Dove continuare
Il catalogo EneUI indicizza 111.985 componenti e 12.808 icone con preview. Il record scroll expansion hero è una hero con immagine grande: è il caso in cui vale la pena misurare il preload. Per il lazy loading leggi quando il lazy loading peggiora, per le soglie Core Web Vitals, per le immagini in Next.js next/image.
Domande frequenti
Devo fare preload del font?
Sì, se il font è quello usato dall'elemento LCP. Il preload deve dichiarare as="font", type e crossorigin, altrimenti il browser scarica il file due volte.
preload sostituisce fetchpriority?
No. preload crea una richiesta anticipata, fetchpriority cambia la priorità di una richiesta che esiste già nell'HTML. Sull'immagine LCP di solito basta fetchpriority.
prefetch è dannoso?
Può esserlo: consuma banda e cache per una pagina che l'utente può non visitare. Va limitato a una rotta con probabilità alta e alleggerito su mobile.
Perché la console segna un preload non usato?
Perché la risorsa è stata scaricata e non richiesta entro pochi secondi. Di solito è un preload duplicato, un as sbagliato o una risorsa che il layout non usa più.
Funziona anche su Safari?
preload e prefetch sono supportati; fetchpriority è arrivato più tardi e sulle versioni vecchie viene ignorato senza errori. Il peggior caso è l'ordine predefinito.