Dal 2022, con WordPress 5.9, esistono due modi molto diversi di costruire un tema. I temi classici, quelli che WordPress usa da vent’anni, sono insiemi di file PHP, come header.php, single.php e footer.php, accompagnati da fogli di stile e script. I temi a blocchi descrivono invece l’intera struttura del sito, compresi intestazione, piè di pagina e modelli delle pagine, con gli stessi blocchi usati nei contenuti, in file HTML, e configurano colori, caratteri e spaziature in un file theme.json. È il modello su cui si basa il Site Editor, e su cui WordPress sta concentrando lo sviluppo.
La scelta tra i due modelli viene di solito discussa in termini di flessibilità, autonomia dei redattori e compatibilità con i plugin. Ma ha anche conseguenze concrete sulle prestazioni: su quanto CSS e JavaScript arrivano al browser, su come vengono caricati, su quanto è grande la pagina. In questo articolo vediamo cosa cambia davvero, dove i temi a blocchi hanno un vantaggio strutturale, dove invece possono pesare, e come valutare un tema indipendentemente dal modello.
Il caricamento degli stili dei blocchi
La differenza più importante riguarda il CSS dei blocchi. WordPress include decine di blocchi, dal paragrafo alla galleria, dalla tabella al calendario, ciascuno con i propri stili. Per molto tempo tutti questi stili sono stati caricati in un unico foglio, wp-block-library, su ogni pagina, indipendentemente dai blocchi effettivamente usati: una pagina con soli paragrafi e titoli scaricava anche gli stili di gallerie, tabelle e lettori audio.
Dalla versione 5.8, WordPress può caricare separatamente gli stili di ciascun blocco, e solo per i blocchi presenti nella pagina. Nei temi a blocchi questo comportamento è attivo per impostazione predefinita, perché WordPress conosce in anticipo tutti i blocchi che compongono la pagina, compresi quelli dei modelli. Gli stili dei blocchi più piccoli vengono inoltre inseriti direttamente nell’HTML, entro una soglia di dimensione complessiva, evitando richieste aggiuntive.
Anche i temi classici possono attivare il caricamento separato con il filtro should_load_separate_core_block_assets, ma con un limite: poiché intestazione e piè di pagina sono generati da PHP, WordPress scopre i blocchi solo man mano che li incontra, e alcuni stili possono finire in fondo al documento. Per questo l’opzione è disattivata di default nei temi classici e va attivata con attenzione, verificando che non compaiano spostamenti del layout.
// In un tema classico: caricare solo gli stili dei blocchi usati
add_filter( 'should_load_separate_core_block_assets', '__return_true' );
// Soglia per l’inserimento diretto nell’HTML degli stili piccoli (byte)
add_filter(
'styles_inline_size_limit',
function () {
return 30000;
}
);theme.json e gli stili globali
Nei temi a blocchi, colori, caratteri, dimensioni del testo, spaziature e stili dei singoli blocchi sono definiti in theme.json. WordPress li trasforma in un foglio di stile globale, generato automaticamente e inserito nella pagina, che definisce una serie di proprietà personalizzate CSS e le regole che le applicano. È un approccio ordinato: i valori sono centralizzati, il CSS generato è coerente, e il redattore può modificarli dal Site Editor senza toccare il codice.
Ha però un costo da tenere d’occhio. Ogni colore della tavolozza, ogni dimensione del testo, ogni gradiente e ogni spaziatura predefinita genera proprietà personalizzate e classi di utilità, e il foglio globale può crescere fino a diverse decine di kilobyte, inserito in ogni pagina. I temi che definiscono tavolozze molto ampie, o che mantengono attive le tavolozze predefinite di WordPress oltre alle proprie, producono un CSS globale sproporzionato. La soluzione è semplice: disattivare le preimpostazioni predefinite non usate e limitare le proprie a quelle realmente necessarie.
{
"version": 3,
"settings": {
"color": {
"defaultPalette": false,
"defaultGradients": false,
"defaultDuotone": false
},
"typography": {
"defaultFontSizes": false,
"fluid": true
},
"spacing": {
"defaultSpacingSizes": false
}
}
}La tipografia fluida, attivabile in theme.json, è un vantaggio indiretto: le dimensioni del testo si adattano alla larghezza dello schermo con la funzione CSS clamp(), eliminando molte regole specifiche per i diversi dispositivi. Anche i font possono essere dichiarati in theme.json e ospitati nel tema, con le regole @font-face generate automaticamente: una buona base per il lavoro di subsetting e ottimizzazione dei font.
JavaScript: meno di quanto si pensi
Un tema a blocchi ben costruito carica sul front-end pochissimo JavaScript. I modelli sono generati sul server, i blocchi del core producono HTML e CSS, e il JavaScript arriva solo per i blocchi che ne hanno bisogno, come la navigazione con il menu mobile o la ricerca. Dalla versione 6.5, i blocchi interattivi del core usano la Interactivity API, un piccolo sistema basato su moduli JavaScript nativi che viene caricato solo quando nella pagina c’è almeno un blocco che lo richiede.
I temi classici, al contrario, includono spesso jQuery e una serie di script propri caricati su tutte le pagine: slider, animazioni, menu, lightbox, spesso anche quando la pagina non li usa. Non è una caratteristica intrinseca del modello classico, ma un’abitudine diffusa, eredità di un’epoca in cui jQuery era lo standard. Il risultato, nel confronto tipico tra un tema classico ricco di funzioni e un tema a blocchi essenziale, è una differenza di peso considerevole.
Dove i temi a blocchi possono pesare
Sarebbe un errore concludere che un tema a blocchi sia automaticamente veloce. Alcune caratteristiche del modello possono produrre pagine più pesanti del necessario.
- Annidamento dei gruppi. Costruire layout complessi nel Site Editor porta facilmente a gruppi dentro gruppi, colonne dentro colonne, ciascuno con i propri involucri: lo stesso problema dei page builder, in forma più contenuta, visto nell’articolo sul costo del DOM.
- Stili generati per ogni elemento. Quando il redattore personalizza margini, colori o layout di un singolo blocco, WordPress genera classi e regole specifiche per quell’istanza, inserite nella pagina. Molte personalizzazioni puntuali producono molto CSS non riutilizzabile.
- Stili globali ingombranti. Come visto sopra, tavolozze e preimpostazioni numerose gonfiano il CSS inserito in ogni pagina.
- Plugin di blocchi. Le raccolte di blocchi aggiuntivi caricano spesso i propri fogli di stile e script per tutti i blocchi della raccolta, su tutte le pagine, annullando il vantaggio del caricamento selettivo del core.
- Pattern pesanti. I pattern pronti, sezioni preconfezionate da inserire con un clic, possono includere immagini grandi, animazioni e strutture profonde che finiscono nella pagina senza che nessuno le rivaluti.
Buone pratiche per chi lavora nel Site Editor
Con un tema a blocchi, una parte delle scelte che incidono sulle prestazioni passa da chi sviluppa il tema a chi costruisce e aggiorna le pagine. Alcune abitudini aiutano a mantenere il sito leggero nel tempo. Preferire gli stili globali alle personalizzazioni del singolo blocco: se tutti i pulsanti devono avere lo stesso aspetto, va definito una volta negli stili del blocco Pulsanti, non ripetuto su ogni istanza. Usare i pattern sincronizzati per le sezioni ricorrenti, invece di copiarle e modificarle pagina per pagina. Evitare gruppi annidati quando un solo gruppo con il layout giusto basta.
Per le immagini, caricare file di dimensioni adeguate e lasciare che WordPress generi le varianti, invece di inserire immagini enormi ridimensionate dall’editor. E prima di installare una raccolta di blocchi per usarne uno solo, verificare quali risorse carica e su quali pagine: spesso un pattern costruito con i blocchi del core ottiene lo stesso risultato senza aggiungere nulla.
Temi ibridi e temi classici moderni
Tra i due modelli esiste una zona intermedia. Molti temi classici adottano oggi theme.json per gestire colori, caratteri e impostazioni dell’editor, pur mantenendo i modelli in PHP: sono i cosiddetti temi ibridi. Beneficiano degli stili globali e della coerenza con l’editor, e possono attivare il caricamento separato degli stili dei blocchi. Allo stesso tempo, esistono temi classici costruiti con grande attenzione alle prestazioni, con CSS essenziale, nessun jQuery e script caricati solo dove servono, che non hanno nulla da invidiare a un buon tema a blocchi.
Il tipo di tema, quindi, conta meno della qualità della sua costruzione. Il modello a blocchi offre alcuni vantaggi strutturali, come il caricamento selettivo degli stili, la generazione dei modelli sul server e l’assenza di dipendenze storiche, che rendono più facile ottenere buone prestazioni. Ma non le garantisce.
L’immagine LCP e i blocchi del core
Un vantaggio meno evidente dei temi a blocchi riguarda l’LCP. Le ottimizzazioni automatiche di WordPress, come l’aggiunta di fetchpriority="high" all’immagine principale e l’esclusione delle prime immagini dal lazy loading, funzionano meglio quando le immagini sono prodotte dai blocchi e dalle funzioni del core: WordPress conosce la struttura della pagina e può stimare con buona precisione quale immagine sarà l’elemento LCP. Con temi e costruttori che generano il markup delle immagini in modo proprio, la stima è meno affidabile e spesso va corretta a mano.
Anche le immagini in evidenza, le copertine e le immagini di sfondo dei blocchi Copertina sono gestite dal core con attributi di dimensione e varianti responsive, riducendo il rischio di immagini sovradimensionate e di spostamenti del layout.
Un esempio concreto: questo sito
Il sito che state leggendo usa un tema a blocchi costruito su misura. I modelli di pagina sono file HTML con blocchi del core, gli stili globali sono definiti in theme.json con preimpostazioni ridotte al minimo, gli stili dei blocchi vengono caricati solo quando servono e i fogli di stile specifici di alcune sezioni, come quelli del blog, vengono caricati solo nelle pagine che li usano. Il JavaScript sul front-end è ridotto al minimo, tanto che anche l’indice dei contenuti degli articoli è generato sul server, e i font sono ospitati localmente e ridotti ai caratteri necessari. Il risultato è una pagina con poche richieste, un CSS contenuto e nessuno script che blocchi il rendering, senza rinunciare a un editor visuale per i contenuti.
Passare a un tema a blocchi?
Per un sito esistente, cambiare tema è un progetto con costi e rischi, e le prestazioni sono solo uno dei fattori. Conviene valutarlo quando il tema attuale è datato, pesante e difficile da ottimizzare, quando si prevede comunque un rinnovamento grafico, o quando il sito è già costruito prevalentemente con i blocchi nei contenuti. In molti altri casi, un intervento sul tema esistente, come l’attivazione del caricamento separato degli stili, la rimozione di jQuery e degli script non necessari e l’adozione di theme.json, porta gran parte dei benefici con un costo molto minore.
Per un sito nuovo, invece, un tema a blocchi essenziale è oggi un ottimo punto di partenza: allineato alla direzione di sviluppo di WordPress, leggero per costruzione e con meno dipendenze da gestire nel tempo.
Come valutare un tema
Indipendentemente dal modello, alcuni controlli rapidi dicono molto sulla qualità di un tema dal punto di vista delle prestazioni. Su una pagina di esempio con contenuti realistici, nel pannello Network dei DevTools: quanti fogli di stile e quanti script vengono caricati, quanto pesano, se jQuery è presente, se ci sono script nell’intestazione che bloccano il rendering. Nella console: il numero di elementi della pagina con document.querySelectorAll('*').length. In PageSpeed Insights: l’elemento LCP, la presenza di CSS e JavaScript inutilizzati, gli avvisi sulla dimensione del DOM.
Il confronto va fatto sempre con gli stessi contenuti e senza plugin aggiuntivi, per isolare il contributo del tema. E va ripetuto dopo aver aggiunto i plugin che il sito userà davvero: un tema leggero non basta se ogni plugin aggiunge i propri stili e script a tutte le pagine.
In sintesi
I temi a blocchi hanno alcuni vantaggi strutturali per le prestazioni: caricano solo gli stili dei blocchi presenti, generano i modelli sul server, usano pochissimo JavaScript e si integrano meglio con le ottimizzazioni automatiche di WordPress sulle immagini. Possono però pesare per stili globali ingombranti, annidamenti profondi, personalizzazioni puntuali e plugin di blocchi poco attenti.
La qualità della costruzione conta più del modello: un tema classico ben fatto può essere più leggero di un tema a blocchi trascurato. Per i siti nuovi, un tema a blocchi essenziale è la scelta più naturale; per quelli esistenti, conviene prima portare nel tema attuale le buone pratiche del modello a blocchi, e valutare il cambio solo quando i benefici giustificano il progetto.
