La velocità di caricamento di una pagina web dipende in gran parte da come il browser gestisce le risorse necessarie: fogli di stile, font, script, immagini e connessioni a server esterni. HTML offre una serie di meccanismi chiamati resource hints che permettono agli sviluppatori di comunicare al browser quali risorse saranno necessarie e quando, ottimizzando così il processo di caricamento. In questa guida analizzeremo in dettaglio <link rel="preload">, <link rel="prefetch">, <link rel="preconnect"> e gli altri hint disponibili.
Panoramica dei Resource Hints
Quando un browser carica una pagina, segue un processo ben definito: scarica l’HTML, lo analizza, scopre le risorse necessarie e le scarica. Questo processo è intrinsecamente sequenziale: il browser non può sapere che avrà bisogno di un font finché non ha scaricato e analizzato il CSS che lo dichiara. I resource hints permettono di anticipare queste informazioni, inserendole direttamente nel <head> del documento HTML.
Ogni hint ha uno scopo diverso e un impatto differente sulle performance. Utilizzarli correttamente può ridurre i tempi di caricamento di centinaia di millisecondi, un miglioramento percepibile dall’utente e misurabile nei Core Web Vitals. Tuttavia, un uso eccessivo o scorretto può peggiorare le performance anziché migliorarle, poiché ogni hint consuma risorse del browser e banda di rete.
Preload: Caricare Subito le Risorse Critiche
Il <link rel="preload"> è il resource hint più potente e aggressivo. Dice al browser: “Avrai bisogno di questa risorsa molto presto nella pagina corrente, inizia a scaricarla immediatamente con alta priorità”. È fondamentale per le risorse che il browser scoprirebbe troppo tardi nel processo di analisi.
La sintassi richiede l’attributo <as> per indicare il tipo di risorsa, il che permette al browser di assegnare la priorità corretta e di applicare le policy di sicurezza appropriate:
<!-- Preload di un font -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<!-- Preload di un CSS critico -->
<link rel="preload" href="/css/critical.css" as="style">
<!-- Preload di uno script -->
<link rel="preload" href="/js/app.js" as="script">
<!-- Preload di un'immagine LCP -->
<link rel="preload" href="/img/hero.webp" as="image" type="image/webp">I font sono il caso d’uso più comune per preload. Senza preload, il browser deve: scaricare l’HTML, trovare il link al CSS, scaricare il CSS, trovare la dichiarazione @font-face, e solo allora iniziare a scaricare il font. Con preload, il download del font inizia immediatamente, in parallelo con le altre risorse. È obbligatorio aggiungere l’attributo crossorigin per i font, anche se sono ospitati sullo stesso dominio, poiché i font vengono sempre richiesti in modalità CORS.
Per le immagini hero (le immagini principali above-the-fold), il preload è particolarmente efficace quando l’immagine è referenziata dal CSS come background-image, poiché altrimenti il browser la scoprirebbe molto tardi. In alternativa, per immagini nel markup HTML, si può usare l’attributo fetchpriority="high" direttamente sul tag <img>.
Un errore comune è fare preload di troppe risorse. Il browser ha un limite di connessioni simultanee per dominio, e saturarlo con preload può rallentare il download di risorse che il browser avrebbe caricato naturalmente con priorità maggiore. La regola pratica è: preload solo 2-4 risorse veramente critiche per il rendering above-the-fold.
Prefetch: Anticipare le Risorse delle Pagine Successive
A differenza di preload che riguarda la pagina corrente, <link rel="prefetch"> anticipa le risorse che saranno necessarie nelle navigazioni future. Il browser scarica queste risorse con bassa priorità, durante i momenti di inattività, senza impattare il caricamento della pagina corrente.
<!-- Prefetch di una pagina che l'utente probabilmente visiterà -->
<link rel="prefetch" href="/prodotti/catalogo.html">
<!-- Prefetch di un CSS necessario nella pagina successiva -->
<link rel="prefetch" href="/css/product-page.css" as="style">
<!-- Prefetch di dati JSON -->
<link rel="prefetch" href="/api/products.json" as="fetch">Il prefetch è ideale per scenari in cui si può prevedere con ragionevole certezza quale pagina l’utente visiterà successivamente. Ad esempio, in un e-commerce, se l’utente è sulla pagina di elenco prodotti, è probabile che cliccherà su uno dei prodotti per vederne i dettagli. Fare prefetch della pagina del primo prodotto visibile può rendere la navigazione quasi istantanea.
È importante sottolineare che le risorse prefetchate vengono memorizzate nella cache HTTP del browser. Se l’utente non visita mai la pagina anticipata, la risorsa viene comunque scaricata, consumando banda. Per questo motivo, il prefetch va usato solo quando la probabilità di navigazione è alta. Inoltre, il browser può decidere di ignorare i prefetch hint in determinate condizioni, come connessioni lente o modalità di risparmio dati.
Preconnect e DNS-Prefetch: Preparare le Connessioni
Quando il browser deve scaricare una risorsa da un dominio esterno (CDN, API, font server), deve prima completare diversi passaggi di rete: risoluzione DNS, handshake TCP e negoziazione TLS. Questo processo può richiedere 100-300 millisecondi. <link rel="preconnect"> permette di completare questi passaggi in anticipo.
<!-- Preconnect a Google Fonts -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Preconnect a un CDN -->
<link rel="preconnect" href="https://cdn.example.com">
<!-- DNS-prefetch come fallback -->
<link rel="dns-prefetch" href="https://cdn.example.com">Il <link rel="dns-prefetch"> è una versione più leggera che esegue solo la risoluzione DNS, senza il TCP handshake e la negoziazione TLS. È supportato da tutti i browser, anche i più datati, e ha un costo praticamente nullo. Una pratica comune è inserire dns-prefetch come fallback dopo ogni preconnect, per garantire che almeno la risoluzione DNS venga anticipata anche nei browser che non supportano preconnect.
Limitate i preconnect a massimo 4-6 domini: ogni connessione aperta consuma risorse del browser, e troppe connessioni simultanee possono rallentare quelle veramente necessarie. Per domini da cui scaricherete solo una risorsa piccola, dns-prefetch è più che sufficiente.
Modulepreload e Casi Avanzati
<link rel="modulepreload"> è una variante specializzata di preload progettata per i moduli JavaScript ES. A differenza del preload standard, modulepreload non solo scarica il file ma lo analizza e lo compila immediatamente, e inoltre scarica ricorsivamente tutti i moduli importati:
<link rel="modulepreload" href="/js/app.mjs">
<link rel="modulepreload" href="/js/utils.mjs">Senza modulepreload, un albero di dipendenze di moduli viene scoperto e scaricato in modo sequenziale: il browser scarica il modulo principale, lo analizza, scopre le importazioni, scarica quei moduli, li analizza, e così via. Questo crea una cascata che può aggiungere centinaia di millisecondi al caricamento. Con modulepreload, tutti i moduli vengono scaricati in parallelo fin dall’inizio.
Un altro caso avanzato è l’uso dell’attributo imagesrcset con preload per anticipare il caricamento di immagini responsive. Questo permette di fare preload dell’immagine corretta in base alla viewport, senza caricare risorse inutili. La sintassi è la seguente: <link rel="preload" as="image" imagesrcset="..." imagesizes="...">.
Errori Comuni e Come Evitarli
L’errore più frequente è confondere preload con prefetch: preload è per la pagina corrente con alta priorità, prefetch è per le navigazioni future con bassa priorità. Usare preload quando si intende prefetch spreca banda e CPU nel momento più critico del caricamento.
Un altro errore comune è dimenticare l’attributo as nel preload, il che impedisce al browser di assegnare la priorità corretta e può causare il download doppio della risorsa. Allo stesso modo, dimenticare crossorigin per i font causa un doppio download. Se vedete warning nella console del browser relativi a risorse preloaded non utilizzate entro pochi secondi, è un segnale che il preload non è configurato correttamente.
Infine, evitate di fare preload di risorse che il browser avrebbe comunque scoperto velocemente. Un CSS linkato direttamente nel <head> viene già scaricato con alta priorità; fare preload in quel caso non aggiunge alcun beneficio. Concentrate il preload su risorse “nascoste” come font (referenziati dal CSS), immagini CSS background e script caricati dinamicamente.
Hai bisogno di aiuto con l’ottimizzazione del caricamento delle tue pagine web? G Tech Group offre servizi di sviluppo web professionale e consulenza tecnica. Contattaci a su*****@********up.it o via WhatsApp al 0465 84 62 45.