Quando il preload dei fogli di stile (non) ha senso
Perché di solito il preload del CSS non aiuta e l'unico caso in cui lo fa
Quando il Preload dei Fogli di Stile (Non) ha Senso
Incontro regolarmente fogli di stile in preload e molta disinformazione che li circonda. Il preload di una risorsa cambia il momento in cui viene programmata per il download. Ma la maggior parte delle volte, il preload dei fogli di stile non aiuta. In cinque casi ti mostrerò quando funziona e quando no.
Ultima revisione di Arjen Karel a Marzo 2026
Table of Contents!
- Quando il Preload dei Fogli di Stile (Non) ha Senso
- L'idea del preload dei fogli di stile
- Caso 1: preload del foglio di stile appena prima di dichiararlo
- Caso 2: preload del foglio di stile con un link header
- Caso 3: 103 Early Hints per i fogli di stile
- Caso 4: preload dei fogli di stile per ottenere CSS asincrono
- Caso 5: pre-cache dei fogli di stile
- Cosa funziona realmente per le performance del CSS
L'idea del preload dei fogli di stile
I fogli di stile sono render blocking. Mentre i fogli di stile vengono scaricati, la pagina non verrà renderizzata dal browser e tutto ciò che il visitatore vedrà è uno schermo bianco.
Per minimizzare il tempo necessario per scaricare i fogli di stile, gli sviluppatori a volte ricorrono al loro preload. Il preload dice al browser di recuperare una risorsa prima di scoprirla nell'HTML, in modo che sia pronta prima. Questo viene fatto utilizzando il tag <link> con l'attributo rel="preload".
Secondo il Web Almanac 2025, solo il 13% delle pagine desktop supera l'audit delle risorse render-blocking. Il preload non è la soluzione. Eliminare le risorse render-blocking non necessarie e differire i fogli di stile non critici lo è.
Caso 1: preload del foglio di stile appena prima di dichiararlo
A volte gli sviluppatori, in tutto il loro entusiasmo, cercano di minimizzare l'impatto del CSS effettuando il preload nell'HTML appena prima della dichiarazione CSS vera e propria. Questo avrà un aspetto simile a:
<link rel="preload" as="style" href="style.css"> <link rel="stylesheet" href="style.css">
Questo non ha affatto senso e nella migliore delle ipotesi non rallenterai la pagina. I browser hanno un preload scanner integrato che analizza l'HTML alla ricerca di risorse da scaricare prima che il parser principale le raggiunga. Se il tuo <link> del foglio di stile è già nell'<head>, il preload scanner lo trova immediatamente. Aggiungere un suggerimento rel="preload" per lo stesso URL fornisce al browser informazioni che possiede già. Hai solo aggiunto una riga extra, tutto qui.
3 fogli di stile in preload
3 fogli di stile normali
Caso 2: preload del foglio di stile con un link header
Questa idea è interessante. Possiamo usare l'header del server Link per il preload di un foglio di stile. L'aspetto sarebbe simile a questo:
Link: <style.css>; rel=preload; as=style
L'idea è di far accodare al browser il foglio di stile prima che inizi il parsing dell'HTML. Mi piace come funziona la mente di uno sviluppatore che ha pensato a questo! Ma nella vita reale otterrai pochissimi benefici. Stiamo parlando di pochi microsecondi. Risultati piuttosto deludenti, ma questa idea ci porta a qualcosa che funziona davvero.
Caso 3: 103 Early Hints per i fogli di stile
Questa è l'unica idea che ti farà effettivamente ottenere risultati nei Core Web Vitals. Inviare early hints per i fogli di stile migliorerà metriche come il First Contentful Paint e il Largest Contentful Paint.
Gli header 103 Early Hint vengono inviati prima della risposta HTML effettiva. Ciò significa che mentre stai scaricando l'HTML, il browser può anche iniziare a scaricare i fogli di stile in parallelo. Lo scenario migliore è che nel momento in cui l'HTML ha finito di essere scaricato, anche i fogli di stile siano stati scaricati. Zero tempo di render blocking da parte di quei fogli di stile. Questo può accadere e accade su reti più lente. Su reti più veloci l'effetto è meno ovvio, ma l'utilizzo delle 103 Early Hints è comunque più veloce in quasi tutti i casi.
Una risposta 103 Early Hint assomiglia molto a un header link in preload. Per utilizzare le 103 Early Hints dovrai configurare il tuo webserver o la tua CDN.
HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style
Alcune CDN come Cloudflare ti permetteranno di attivare un 103 Early Hint impostando semplicemente un header preload link (come descritto nel Caso 2). Per una guida completa sull'implementazione e sul supporto dei browser, vedi 103 Early Hints: Preload Critical Resources During Server Think Time.
Nei siti monitorati da CoreDash, le pagine che utilizzano 103 Early Hints per il loro foglio di stile principale mostrano un FCP più veloce di 120ms al 75° percentile rispetto alle pagine senza Early Hints. Il miglioramento è più visibile sulle connessioni mobili dove il tempo di elaborazione del server e la latenza di rete si sovrappongono maggiormente.
Caso 4: preload dei fogli di stile per ottenere CSS asincrono
Un trucco ben noto per rendere il CSS non-render-blocking è effettuare il preload del foglio di stile e, una volta caricato, aggiungerlo alla pagina. L'idea è semplice ed è simile a questa:
<link rel="preload" href="style.css" as="style" onload="this.onload=null;this.rel='stylesheet'" >
Si basa sul normale codice di preload <link rel="preload" as="style" href="style.css"> e aggiunge un event listener onload onload="this.onload=null;this.rel='stylesheet'" che cambia il link nella sua forma finale <link rel="stylesheet" href="style.css">
Questa è un'altra idea che ha semplicemente senso. Se un foglio di stile non è render blocking, il browser può continuare il parsing e renderizzare la pagina senza aspettare il foglio di stile. Tuttavia, fai attenzione!
- Non usare CSS asincrono nella viewport visibile. Questo causerà probabilmente un Cumulative Layout Shift e porterà a una scarsa user experience.
- Considera il compromesso. Il CSS asincrono causerà probabilmente un re-render di diverse parti della pagina. Questo impatterà metriche come l'Interaction to Next Paint.
Un'alternativa moderna più semplice è usare fetchpriority="low" su un normale link al foglio di stile: <link rel="stylesheet" href="style.css" fetchpriority="low">. Questo dice al browser di depotenziare la priorità del download senza l'hack JavaScript. Raccomando questo approccio rispetto al trucco dell'onload per la maggior parte dei casi d'uso.
Caso 5: pre-cache dei fogli di stile
In rare occasioni vedo soluzioni ingegnose che cercano di pre-riscaldare i file in cache per le pageview successive. E sebbene applauda l'entusiasmo con cui vengono realizzate queste soluzioni: per favore NON farlo.
L'idea è semplice: sulla homepage potresti, volendo, già pre-memorizzare in cache gli stili per un'altra pagina. Diciamo la pagina del prodotto. Ad un certo punto dopo il caricamento della pagina faresti il preload dei fogli di stile per aggiungerli alla cache del browser.
function preloadStylesheet(url) {
var link = document.createElement('link');
link.rel = 'preload';
link.href = url;
link.as = 'style';
document.head.appendChild(link);
}
window.addEventListener('load', function () {
preloadStylesheet('cart.css');
preloadStylesheet('shop.css');
});
A prima vista non sembra per niente male. Su qualsiasi pagina prodotto cart.css e shop.css sono ora disponibili e non bloccheranno più il render. Ci sono alcuni motivi per non farlo:
- Ci sono modi migliori, per esempio il prerendering speculativo con Speculation Rules o utilizzando un service worker.
- Probabilmente sprecherai risorse e il compromesso non ne varrà la pena. Se il preload delle risorse fosse facile, i browser sarebbero stati più bravi a farlo.
- Soluzioni come questa sono difficili da mantenere e probabilmente causeranno problemi prima o poi in futuro.
- Dovrai fare il preload di tutti i fogli di stile, non solo di alcuni. Poiché tutti i fogli di stile sono render blocking e scaricati in parallelo, un solo foglio di stile può avere lo stesso effetto di più fogli di stile.
Cosa funziona realmente per le performance del CSS
Invece di ricorrere ai preload hints, concentrati su questi fondamentali della prioritizzazione delle risorse:
- Rimuovere il CSS inutilizzato e ridondante. I file più piccoli si scaricano più velocemente. Questa è la singola vittoria più grande per la maggior parte dei siti.
- Usa le 103 Early Hints per i tuoi fogli di stile critici se il tuo server o la tua CDN lo supporta.
Nei nostri dati di Real User Monitoring, i siti che rimuovono il CSS ridondante e utilizzano 103 Early Hints superano costantemente l'LCP al 75° percentile. I siti che eseguono solo il preload dei loro fogli di stile senza affrontare la causa principale (troppo CSS, caricato troppo tardi) raramente vedono miglioramenti significativi.
The RUM tool I built for my own clients.
CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.
Create Free Account
