Preload, prefetch e preconnect: quando ciascuno aiuta davvero
I resource hint sono utili quando corrispondono a reali colli di bottiglia del browser. Usati alla cieca, aggiungono rumore nelle priorità e a volte rendono le pagine più lente.
Indice
- I resource hint non sono magia
- Che cosa il browser fa già bene
- Preload: per risorse della pagina corrente scoperte troppo tardi
- Preload e immagini LCP
- Prefetch: per la prossima pagina, non per questa
- Preconnect: per connessioni costose a origini importanti
- DNS-prefetch: il cugino più leggero
- Come decidere: un workflow pratico
- 1. Identifica il collo di bottiglia
- 2. Aggiungi un hint alla volta
- 3. Controlla gli effetti collaterali sulle priorità
- 4. Verifica header e caching
- Errori comuni
- Fare preload di troppo
- Usare prefetch per risorse richieste
- Fare preconnect a ogni terza parte
- Dimenticare le condizioni mobili
- Una semplice tabella decisionale
- La regola calma
I resource hint non sono magia
preload, prefetch e preconnect vengono spesso trattati come una checklist per le prestazioni. Aggiungi qualche tag al <head>, rilanci Lighthouse, ti senti meglio. Non funzionano così.
Questi hint sono istruzioni per la pipeline di caricamento del browser. Possono aiutare quando sai qualcosa che il browser non può scoprire abbastanza presto. Possono danneggiare quando vai a intuito, dai troppa priorità a lavoro non critico o prepari connessioni che gli utenti non useranno mai.
La versione breve:
- Usa
preloadper le risorse necessarie alla pagina corrente, ma scoperte troppo tardi. - Usa
prefetchper probabili risorse di navigazioni future, non per elementi essenziali della pagina corrente. - Usa
preconnectper origini di terze parti importanti, dove l’impostazione della connessione è un ritardo reale.
La domanda pratica non è “quale hint è più veloce?” È “che cosa sta aspettando il browser, e questo hint può eliminare quell’attesa?”
Che cosa il browser fa già bene
I browser moderni non sono downloader passivi di file. Analizzano l’HTML, scandiscono in anticipo alla ricerca di risorse, assegnano priorità, riutilizzano connessioni, rimandano il lavoro non visibile e si adattano alle condizioni di rete.
Questo significa che i resource hint dovrebbero essere selettivi. Se un foglio di stile, uno script, un’immagine o un font viene già scoperto presto e riceve la priorità giusta, aggiungere un hint può non fare nulla. Peggio, può competere con risorse più importanti.
Prima di aggiungere hint, guarda un waterfall trace in DevTools o un report di laboratorio. Se usi Lighthouse, parti dalle diagnostiche invece che dal punteggio; abbiamo una guida separata su come leggere un report Lighthouse senza farsi prendere dal panico — ma nota che l’URL corretto è sensibile a maiuscole e minuscole, quindi usa l’articolo collegato dalla navigazione del tuo sito se necessario.
La prova reale di solito è visibile in tre punti:
- Una risorsa critica parte tardi perché il browser la scopre tardi.
- Una connessione a un’origine importante richiede tempo percepibile prima della prima richiesta.
- Una risorsa della pagina successiva è altamente prevedibile ed economica da recuperare nei momenti di inattività.
Se nessuna di queste condizioni è vera, probabilmente un hint è solo decorazione.
Preload: per risorse della pagina corrente scoperte troppo tardi
preload dice al browser: “Recupera questa risorsa ora perché la pagina corrente ne avrà bisogno.”
Un esempio tipico è un web font referenziato dentro il CSS. Il browser deve scaricare l’HTML, scoprire il CSS, scaricare il CSS, analizzarlo, scoprire il font e poi richiedere il font. Se quel font è importante per il testo above-the-fold, la scoperta può avvenire abbastanza tardi da causare layout shift o ritardare il rendering del testo.
Un preload può anticipare quella richiesta:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>L’attributo as è importante. Dice al browser che tipo di risorsa è, influenzando priorità, caching, content security policy e header della richiesta. Anche i font di solito richiedono crossorigin, persino quando sono serviti dallo stesso sito, perché il recupero dei font usa la modalità CORS.
Buoni candidati per preload includono:
- Il web font principale usato per il testo visibile.
- Un’immagine hero che è l’elemento Largest Contentful Paint e non è scopribile presto.
- Un file CSS critico caricato indirettamente.
- Un modulo o uno script necessario molto presto, ma nascosto dietro un altro script.
Cattivi candidati per preload includono:
- Ogni peso di font nel design system.
- Immagini below-the-fold.
- Script non necessari per il rendering iniziale.
- Risorse che il browser scopre già nel primo blocco di HTML.
Preload è potente perché influenza la priorità della pagina corrente. Ed è anche per questo che è facile usarlo male. Se fai preload di cinque asset grandi, non stai più aiutando il browser. Stai discutendo con lui.
I font sono il caso classico. Fare preload di un singolo file di font principale può aiutare. Fare preload di sei pesi e corsivi di solito peggiora le cose. Se i font sono il tuo collo di bottiglia, prima correggi il set di font; la nostra guida sul perché i web font sono ancora il miglior intervento facile per le prestazioni sulla maggior parte dei siti tratta questa pulizia in maggiore dettaglio.
Preload e immagini LCP
Fare preload di un’immagine LCP può essere utile quando l’immagine non è visibile nell’HTML iniziale. Le cause comuni includono immagini di sfondo CSS, componenti renderizzati dal client o logica di immagini responsive che compare tardi.
Ma se la tua immagine hero è già nell’HTML come <img> con srcset, sizes, dimensioni sensate e senza lazy loading, probabilmente il browser può trovarla rapidamente. In quel caso, aggiungere fetchpriority='high' può essere più appropriato del preload, a seconda della pagina.
Un buon test: se la richiesta dell’immagine parte tardi nel waterfall e diventa l’elemento LCP, considera il preload. Se parte presto ma si scarica lentamente, il problema è dimensione, formato, comportamento della CDN o latenza del server — non la scoperta. Per le decisioni sui formati immagine, vedi quando AVIF batte WebP e quando no.
Prefetch: per la prossima pagina, non per questa
prefetch dice al browser: “Questa risorsa potrebbe servire presto, ma non è richiesta adesso.”
La distinzione è importante. Prefetch è intenzionalmente a bassa priorità. Il browser può recuperarla durante i momenti di inattività e conservarla per un uso successivo. Può anche saltarla su connessioni scarse, modalità di risparmio dati o sotto pressione di memoria.
Usa prefetch quando l’intento dell’utente è abbastanza forte da rendere probabile la prossima risorsa.
Buoni candidati per prefetch includono:
- Il passaggio successivo in un checkout multi-pagina.
- Risultati di ricerca dopo che un utente inizia a digitare una query, se la route successiva è prevedibile.
- Pagine di documentazione collegate da un sommario quando l’utente sta leggendo attivamente contenuti vicini.
- Chunk di route in una single-page app dopo che un utente passa sopra o mette a fuoco una voce di navigazione.
Cattivi candidati per prefetch includono:
- L’intero albero di navigazione.
- Video grandi o gallerie di immagini.
- Script di terze parti “per sicurezza”.
- Pagine che gli utenti visitano raramente subito dopo.
Prefetch è il punto in cui la moderazione ripaga. Una risorsa recuperata e mai usata non è gratuita. Consuma banda, capacità del server, energia e potenzialmente dati dell’utente. Sulle reti mobili, il fetching speculativo può essere attivamente poco rispettoso.
Per molti siti, la migliore strategia di prefetch è basata sull’intento. Non fare prefetch della pagina prezzi appena si carica la home page. Fallo quando l’utente apre il menu dei prezzi, passa sopra il link dei prezzi o scorre vicino a una call-to-action che predice fortemente la navigazione.
Ricorda anche che il comportamento dei browser varia. Alcuni browser sono conservativi con prefetch; alcune impostazioni di privacy riducono o disabilitano il caricamento speculativo. Considera prefetch come un miglioramento opportunistico, non come un meccanismo di correttezza.
Preconnect: per connessioni costose a origini importanti
preconnect dice al browser: “Inizia ora a impostare una connessione a questa origine.”
Questo può includere lookup DNS, connessione TCP e negoziazione TLS. Per origini di terze parti, questa impostazione può richiedere centinaia di millisecondi, soprattutto su reti ad alta latenza. Se la pagina avrà presto bisogno di una richiesta critica da quell’origine, preconnect può rendere più veloce la richiesta successiva.
Esempio:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Buoni candidati per preconnect includono:
- Un’origine di font usata per testo bloccante per il rendering.
- Un’origine API critica necessaria durante l’interazione iniziale.
- Un’origine CDN che serve asset above-the-fold.
- Un provider di pagamenti o identità necessario subito dopo un’azione dell’utente.
Cattivi candidati per preconnect includono:
- Endpoint di analytics e advertising che non sono critici per l’utente.
- Origini usate solo in alcune sessioni.
- Lunghe liste di terze parti.
- Risorse same-origin, dove il browser ha già o aprirà presto la connessione.
Preconnect ha un costo di mantenimento. I socket aperti consumano memoria e risorse di rete. I browser chiuderanno le connessioni inutilizzate, ma questo non rende innocui i preconnect non necessari.
Una regola utile: fai preconnect al massimo a una o due origini di terze parti ad alta confidenza su una pagina. Se ti viene voglia di aggiungerne altre, probabilmente la tua architettura di terze parti ha più bisogno di revisione di quanto i tuoi hint abbiano bisogno di espansione.
DNS-prefetch: il cugino più leggero
Potresti vedere anche dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Questo risolve solo il nome di dominio. Non apre una connessione TCP o TLS. È più economico di preconnect, ma anche meno utile.
DNS-prefetch può essere ragionevole per origini di terze parti a minore confidenza, dove un preconnect completo sembra troppo aggressivo. In pratica, se un’origine è critica e sarà sicuramente usata presto, preferisci preconnect. Se è solo possibile, usa DNS-prefetch oppure non fare nulla.
Come decidere: un workflow pratico
Parti dalla misurazione, non dai tag.
1. Identifica il collo di bottiglia
Apri un performance trace e cerca la scoperta tardiva. La richiesta del font, dell’immagine hero o dello script è partita solo dopo che un altro file è stato scaricato e analizzato? Quello è un candidato per preload.
Se una richiesta parte solo dopo una lunga impostazione DNS/TCP/TLS verso un’origine di terze parti, quello è un candidato per preconnect.
Se la pagina corrente va bene ma la navigazione successiva è prevedibilmente lenta, prefetch può aiutare.
2. Aggiungi un hint alla volta
I resource hint interagiscono. Aggiungine uno, testalo e tienilo solo se il waterfall migliora e le metriche percepite dall’utente non peggiorano.
Per preload, controlla se la risorsa indicata viene davvero usata presto. Chrome può avvisare quando una risorsa preloaded non viene usata poco dopo il caricamento. Prendi sul serio quell’avviso.
3. Controlla gli effetti collaterali sulle priorità
Un preload può sottrarre banda a CSS, JavaScript o immagini più importanti. Un preconnect può occupare uno slot di connessione. Un prefetch può aggiungere traffico in background.
Il risultato giusto non è “il file indicato parte prima.” Il risultato giusto è “la pagina diventa significativamente migliore per gli utenti.” Guarda LCP, INP, CLS e, dove possibile, il monitoraggio degli utenti reali.
4. Verifica header e caching
Gli hint possono essere inviati nell’HTML o negli header HTTP Link. Gli header sono utili quando il server sa presto di cosa avrà bisogno la pagina, ma sono più difficili da ispezionare casualmente. Se stai facendo debug per capire se un hint è davvero presente in produzione, gli header grezzi contano; è esattamente il tipo di situazione trattato in la nostra guida al debug di redirect e header HTTP.
Anche il caching conta. Fare preload di una risorsa con credenziali non corrispondenti, as sbagliato o parametri URL diversi può causare download duplicati. È uno dei modi più comuni in cui un preload ben intenzionato diventa un bug di prestazioni.
Errori comuni
Fare preload di troppo
Se tutto è critico, niente lo è. Limita preload alle risorse necessarie per il rendering iniziale o l’interattività immediata. Una pagina tipica dovrebbe avere da zero a tre preload, non venti.
Usare prefetch per risorse richieste
Prefetch è a bassa priorità e opzionale. Non usarlo per asset richiesti dalla pagina corrente. Se la pagina ne ha bisogno ora, considera preload o la normale scoperta nell’HTML.
Fare preconnect a ogni terza parte
Le pagine ricche di terze parti spesso hanno dieci o più origini esterne. Fare preconnect a tutte crea rumore. Scegli quella o quelle due che sono sia critiche sia usate in modo prevedibile.
Dimenticare le condizioni mobili
I resource hint sono più preziosi sulle connessioni lente, ma sono anche più pericolosi lì. Un prefetch sprecato su una connessione desktop veloce è un errore trascurabile. Su un piano mobile limitato, è uno scambio sfavorevole.
Una semplice tabella decisionale
| Situazione | Hint migliore | Perché | |---|---:|---| | Font critico scoperto tramite CSS | preload | La pagina corrente ne ha bisogno, la scoperta è tardiva | | Immagine hero nascosta dietro CSS o rendering client | preload | Può migliorare LCP se l’immagine parte tardi | | Probabile route successiva dopo intento dell’utente | prefetch | Aiuta la navigazione futura senza bloccare la pagina corrente | | Origine critica di font/API di terze parti | preconnect | Rimuove l’impostazione della connessione dal percorso critico | | Origine di terze parti possibile ma incerta | dns-prefetch o nessuno | Costo più basso, confidenza più bassa | | Immagine below-the-fold | nessuno | Lascia lavorare lazy loading e priorità del browser |
La regola calma
I resource hint funzionano meglio quando sono noiosi e specifici. Un font. Un’immagine LCP. Un’origine di terze parti importante. Una probabile route successiva dopo l’intento.
Funzionano male quando vengono usati come ottimismo: forse l’utente ne avrà bisogno, forse il browser dovrebbe recuperare quello, forse più hint significano più velocità.
I browser ottimizzano già in modo aggressivo. Il tuo compito non è microgestire ogni richiesta. Il tuo compito è correggere i pochi casi in cui al browser manca l’informazione nel momento giusto.
Domande frequenti
Dovrei fare preload di tutti i miei font?
Prefetch è sicuro da usare per ogni link interno?
Qual è la differenza tra preconnect e dns-prefetch?
I resource hint possono migliorare Core Web Vitals?
I resource hint dovrebbero essere aggiunti nell’HTML o negli header HTTP?
Fonti e letture ulteriori
