Quando un sito diventa lento, la prima reazione è cercare un tool: bundler, minifier, plugin cache, CDN, pipeline. Tutti possono aiutare. Ma prima dei tool serve una cosa più semplice: una gerarchia degli asset.
Non tutto il CSS ha lo stesso peso nel rendering. Alcuni file servono subito per disegnare l’above-the-fold. Altri possono arrivare dopo. Altri ancora servono solo in pagine specifiche. Se li tratti tutti allo stesso modo, il browser deve indovinare le priorità.
Il problema dei CSS trattati come blocco unico
Per anni molti siti hanno caricato il CSS come un unico blocco. È un approccio comodo: un file, una richiesta, una cache. Ma non sempre è il più adatto.
Se dentro quel blocco ci sono stili per home, blog, form, cookie banner, footer, animazioni, card, pagine servizio e template speciali, stai chiedendo al browser di scaricare e valutare codice che magari non serve per la prima schermata.
Il risultato può pesare sui Core Web Vitals, soprattutto quando il CSS blocca il rendering iniziale o si somma a font, immagini e JavaScript non prioritizzati.
Critical, deferred, on-demand
Una gerarchia CSS semplice può partire da tre livelli.
Il primo livello è critical: reset, variabili, layout base, header, navigazione, hero e componenti visibili subito. Questo CSS deve arrivare presto, perché condiziona il primo rendering.
Il secondo livello è deferred: sezioni sotto la prima schermata, blocchi ricorrenti, footer, FAQ, contenuti che non servono immediatamente. Questo CSS può essere caricato senza bloccare la prima resa visiva.
Il terzo livello è on-demand: stili di template specifici, pagine particolari, componenti che non esistono ovunque. Se una pagina non usa quel componente, non ha motivo di scaricarne il CSS.
Questa logica è più importante del nome dello strumento usato per applicarla.
Il browser non conosce il tuo progetto
Il browser sa leggere priorità tecniche, ma non conosce l’intenzione del sito. Non sa che un file è solo per la pagina contatti. Non sa che una sezione appare sempre sotto il fold. Non sa che un componente viene usato una volta sola.
Queste informazioni devono arrivare dall’architettura frontend.
In un progetto ben ordinato, i CSS non sono solo “stili”. Sono una mappa di rendering: cosa serve subito, cosa può aspettare, cosa appartiene a una pagina specifica.
È lo stesso ragionamento che sta dietro a un buon design system orientato alla performance: estetica e velocità non si separano alla fine, si progettano insieme.
Grav, WordPress e il punto comune
Questa logica vale sia in Grav sia in WordPress. Cambia il modo in cui la applichi.
In Grav puoi gestire il tema con Twig, asset espliciti e una struttura molto leggibile. Il modello flat-file aiuta perché rende facile vedere dove vivono pagine, template e stili. Ne ho parlato nell’articolo su Grav CMS 2.0.
In WordPress, invece, bisogna fare più attenzione a enqueue, dipendenze del tema, plugin, blocchi e builder. Il rischio è caricare asset globali perché è più semplice, non perché servono ovunque.
In entrambi i casi, la domanda resta la stessa: questo CSS serve davvero per questa pagina, in questo momento?
Minificare non basta
Minificare riduce byte. Concatenare riduce richieste. Fare cache evita download ripetuti. Sono ottimizzazioni utili, ma non risolvono da sole un problema di priorità.
Un file minificato può essere comunque troppo grande. Un bundle in cache può essere comunque caricato troppo presto. Una CDN può consegnare velocemente CSS che non serviva nella prima schermata.
La performance non è solo quantità. È sequenza.
Come leggere un inventario CSS
Quando guardo un tema, non parto dal tool. Parto da un inventario:
- quali file sono globali;
- quali file sono above-the-fold;
- quali file sono sotto il fold;
- quali file sono legati a una pagina;
- quali file sono duplicati o legacy;
- quali componenti vengono usati davvero;
- quali stili arrivano da plugin o librerie esterne.
Da lì diventa possibile decidere cosa resta render-blocking, cosa si carica dopo e cosa si sposta sul template specifico.
Attenzione agli effetti collaterali
Spostare CSS non è solo un lavoro di ordine. Può creare regressioni visive, layout shift o componenti che appaiono senza stile per qualche istante.
Per questo ogni modifica va verificata su pagine reali:
- home;
- articolo blog;
- pagina servizio;
- form contatti;
- template con immagini;
- mobile e desktop;
- stato con JavaScript disabilitato, se il caricamento deferred dipende da JS.
La parte “noiosa” è proprio quella che evita problemi in produzione.
Collegare CSS e contenuto
Un sito veloce non è solo tecnico. Dipende anche da contenuti, immagini, struttura delle pagine e componenti editoriali.
Se ogni articolo carica stili di sezioni marketing, gallery, form complessi e animazioni che non usa, il problema non è solo CSS. È governance del frontend.
Qui i design tokens aiutano: separano decisioni visive da implementazioni ripetute, riducono duplicazioni e rendono più facile mantenere coerenza senza gonfiare il codice.
Una regola pratica
Prima di installare un plugin o cambiare bundler, farei queste tre cose:
- inventario degli asset caricati;
- classificazione critical, deferred e on-demand;
- verifica su pagine reali con metriche e controllo visivo.
Solo dopo sceglierei lo strumento. A volte basta riorganizzare il tema. A volte serve una pipeline più seria. A volte il problema non è il CSS, ma immagini, font o JavaScript.
Conclusione
La performance CSS non nasce dal tool più moderno. Nasce da una gerarchia chiara: cosa serve subito, cosa può arrivare dopo, cosa appartiene solo a certe pagine.
Quando questa gerarchia è esplicita, bundler, cache e minificazione diventano strumenti utili. Senza gerarchia, rischiano solo di rendere più veloce un ordine sbagliato.