I page builder, i costruttori visuali come Elementor, Divi, WPBakery o Beaver Builder, hanno reso possibile a milioni di persone creare pagine curate senza scrivere codice. Trascini una sezione, scegli le colonne, inserisci un titolo, un’immagine, un pulsante, regoli margini e animazioni, e vedi il risultato in tempo reale. Per agenzie, freelance e aziende è una comodità enorme, che accorcia i tempi di sviluppo e rende autonomi i clienti.
Questa comodità ha però un costo, che non si vede nell’editor ma si paga a ogni visita: più codice HTML, più CSS, più JavaScript, e soprattutto un DOM, la struttura della pagina in memoria, molto più grande e profondo di quanto servirebbe. In questo articolo vediamo da dove nasce questo costo, come incide sulle Core Web Vitals e cosa si può fare senza necessariamente rifare il sito da zero.
Perché i costruttori producono più codice
Un costruttore visuale deve permettere di configurare ogni elemento in modo indipendente: margini, sfondi, bordi, allineamenti, comportamento su tablet e mobile, animazioni d’ingresso, visibilità condizionale. Per offrire tutte queste possibilità in modo generico, ogni elemento viene avvolto in più contenitori, ciascuno dei quali gestisce un aspetto: la sezione, il contenitore interno, la colonna, l’involucro del widget, il widget, il contenitore del contenuto. Un semplice titolo può così trovarsi sei o sette livelli sotto la sezione che lo contiene.
Moltiplicato per tutti gli elementi di una pagina, questo schema produce facilmente due o tremila nodi, a volte molti di più su home page ricche di sezioni, caroselli e menu complessi. A questo si aggiungono altri costi tipici: fogli di stile generati per ogni pagina o per ogni elemento, librerie JavaScript per animazioni, slider, lightbox e schede, raccolte complete di icone caricate per usarne poche, font aggiunti da singoli widget.
Che cosa costa un DOM grande
Il DOM non è solo testo da scaricare. È una struttura che il browser tiene in memoria e che deve ricalcolare ogni volta che qualcosa cambia: quali regole CSS si applicano a ciascun elemento, dove si trova e quanto è grande, cosa ridisegnare. Più nodi ci sono, e più sono annidati, più questo lavoro è pesante. Lighthouse segnala un DOM eccessivo oltre circa 800 elementi e lo considera critico oltre 1400, non perché esista un limite preciso, ma perché oltre queste dimensioni i costi diventano misurabili sui dispositivi di fascia media.
Sulle Core Web Vitals gli effetti si distribuiscono su tutte e tre le metriche. L’INP è quella che ne risente di più: ogni interazione che modifica la pagina, come aprire un menu, cambiare scheda o espandere una domanda frequente, richiede un ricalcolo di stile e layout il cui costo cresce con il DOM, e che si somma al JavaScript del gestore dell’evento. Un’interazione banale può superare i 200 millisecondi su uno smartphone economico semplicemente perché la pagina è enorme.
L’LCP risente di HTML e CSS più pesanti da scaricare e analizzare, del JavaScript che occupa il main thread durante il caricamento e di scelte tipiche dei costruttori, come l’immagine principale inserita come sfondo CSS di una sezione, che il browser scopre tardi, o dentro uno slider avviato da JavaScript. Il CLS, infine, può peggiorare per sezioni che cambiano altezza quando gli script si avviano, per menu che si ricompongono e per font caricati da più widget.
Le impostazioni di prestazioni dei costruttori
I principali costruttori sono consapevoli del problema e negli ultimi anni hanno introdotto funzioni specifiche, spesso disattivate sui siti creati con versioni precedenti per non rompere la compatibilità. È il primo posto dove guardare, perché con pochi clic si possono ottenere miglioramenti concreti.
Elementor, per esempio, ha introdotto un output del DOM ottimizzato che elimina alcuni involucri, il caricamento degli script e degli stili solo per i widget effettivamente usati nella pagina, le icone incorporate come SVG invece della libreria completa di font di icone e, soprattutto, i contenitori basati su Flexbox, che sostituiscono la combinazione di sezioni e colonne con una struttura più leggera. Divi offre nelle proprie opzioni di prestazioni il CSS e il JavaScript dinamici, che caricano solo ciò che serve alla pagina, e la generazione del CSS critico, e la nuova generazione del costruttore è stata riscritta anche per ridurre il peso dell’output. Altri costruttori offrono opzioni simili.
Queste opzioni vanno attivate con attenzione, su un ambiente di prova, perché alcune modificano la struttura HTML e possono alterare CSS personalizzati scritti per la struttura precedente. Ma quasi sempre il beneficio vale la verifica.
Buone pratiche nella costruzione delle pagine
Molto dipende anche da come vengono costruite le pagine. Due siti realizzati con lo stesso costruttore possono avere dimensioni del DOM molto diverse a seconda delle abitudini di chi li ha realizzati.
- Meno annidamento. Evitare sezioni dentro sezioni e colonne dentro colonne quando un solo contenitore con le impostazioni giuste ottiene lo stesso risultato. Con i contenitori Flexbox o Grid, un livello spesso basta dove prima ne servivano tre.
- Un elemento per un contenuto. Un titolo e un paragrafo possono stare in un unico widget di testo invece che in due widget separati, ciascuno con i propri involucri.
- Niente duplicati per dispositivo. Una pratica diffusa è creare due versioni di una sezione, una per desktop e una per mobile, nascondendo quella non pertinente. Entrambe restano nel DOM: si paga il doppio del codice per mostrare metà del contenuto. Meglio una sola sezione con impostazioni responsive.
- Stili globali. Colori, caratteri e spaziature definiti a livello globale producono meno CSS di impostazioni ripetute elemento per elemento, e rendono il sito più coerente.
- Parsimonia con effetti e widget pesanti. Slider, animazioni d’ingresso, contatori animati, effetti di parallasse: ciascuno aggiunge JavaScript e lavoro al browser. Vanno usati dove portano valore, non su ogni sezione.
- L’immagine principale come immagine. Per la sezione di apertura, un vero elemento immagine con priorità alta invece di uno sfondo CSS, come spiegato nell’articolo sul lazy loading.
Intestazione, menu e piè di pagina
Una parte del DOM spesso trascurata è quella che si ripete su ogni pagina. Intestazioni e piè di pagina costruiti con il builder portano con sé gli stessi involucri del resto della pagina, e i menu sono un caso particolare. Un mega menu con decine di categorie, immagini e descrizioni può contare da solo diverse centinaia di nodi, presenti nel DOM anche quando il menu è chiuso. Molti temi aggiungono poi un secondo menu per mobile, un pannello laterale che duplica l’intero albero di navigazione: stesso contenuto, due volte nella pagina.
Poiché questi elementi sono presenti su ogni pagina del sito, alleggerirli ha un effetto moltiplicato. Le soluzioni sono semplici da descrivere: un solo menu che si adatta ai diversi schermi invece di due versioni separate, sottomenu meno profondi, contenuti ricchi dei mega menu caricati solo quando l’utente apre la voce, piè di pagina essenziali invece di vere e proprie pagine con widget, mappe e feed dei social.
Un esempio tipico
Consideriamo la home di un sito aziendale realizzata qualche anno fa con un costruttore: un grande slider in apertura, sezioni di servizi con icone animate, contatori, testimonianze in un carosello, un modulo di contatto, un mega menu e una versione mobile di diverse sezioni. Il DOM supera i quattromila elementi, la pagina carica una dozzina di fogli di stile e altrettanti script, e l’INP da mobile è nello stato da migliorare, con picchi all’apertura del menu.
Un intervento mirato, senza cambiare costruttore, può procedere così: attivazione delle opzioni di prestazioni e dei contenitori moderni, sostituzione dello slider con un’immagine statica e un titolo, eliminazione delle sezioni duplicate per mobile, un solo menu responsive, contatori e animazioni rimossi dove non aggiungono informazioni. Il DOM scende sotto i millecinquecento elementi, il peso della pagina si dimezza e le interazioni tornano rapide. Nella maggior parte dei casi il sito resta visivamente molto simile, e spesso diventa anche più chiaro.
Ridurre ciò che viene caricato
Oltre al DOM, un sito costruito con un page builder carica spesso risorse di cui la singola pagina non ha bisogno: fogli di stile di widget non usati, librerie per funzioni presenti solo in altre pagine, font di icone completi. Oltre alle impostazioni del costruttore, strumenti di ottimizzazione possono rimuovere il CSS inutilizzato, generare il CSS critico e differire il JavaScript non essenziale fino alla prima interazione. Sono interventi efficaci, ma vanno verificati con cura proprio sui siti costruiti con i builder, dove molti elementi dipendono da classi e script che compaiono solo in determinati stati: menu aperti, schede attive, finestre modali.
Come misurare
Il numero di elementi di una pagina si può leggere in Lighthouse, nell’avviso sulla dimensione del DOM, che indica anche la profondità massima e l’elemento con più figli. In alternativa, basta una riga nella console del browser:
document.querySelectorAll( '*' ).length; // numero totale di elementiPer capire l’effetto sulle interazioni, il pannello Performance dei DevTools, con il rallentamento della CPU attivo, mostra per ogni clic il tempo speso in ricalcolo degli stili e layout, evidenziati in viola. Se queste fasi occupano decine di millisecondi per aprire un semplice menu, la dimensione del DOM è con ogni probabilità parte del problema. Il confronto più utile è tra i modelli di pagina: spesso home e pagine promozionali sono molto più pesanti di articoli e schede, e meritano la priorità.
Ottimizzare o ricostruire?
Arriva spesso il momento in cui ci si chiede se valga la pena continuare a ottimizzare un sito costruito con un page builder o se convenga ricostruirlo con un tema leggero o con l’editor a blocchi nativo di WordPress, che produce un markup molto più essenziale. Non esiste una risposta unica. Se le impostazioni di prestazioni e qualche intervento sulle pagine principali portano le Core Web Vitals nello stato buono, ricostruire raramente è giustificato dal solo punto di vista delle prestazioni. Se invece il sito resta lento nonostante gli interventi, il costruttore è datato o la manutenzione è diventata complessa, la ricostruzione può essere l’occasione per risolvere più problemi insieme.
La decisione va presa con i dati: Core Web Vitals di campo per modello di pagina, peso delle pagine principali, costo stimato degli interventi, frequenza con cui i contenuti vengono modificati dai non tecnici. Un page builder che fa risparmiare ore di lavoro ogni settimana ha un valore che va messo sulla bilancia, così come le conversioni perse da un sito lento.
In sintesi
I page builder rendono semplice creare pagine curate, ma producono un DOM più grande e profondo, più CSS e più JavaScript di quanto una pagina richiederebbe. Il costo si vede soprattutto sull’INP, perché ogni aggiornamento della pagina diventa più pesante, ma anche su LCP e CLS. Lighthouse segnala il problema oltre circa 800 elementi, e molte pagine costruite con un builder superano abbondantemente questa soglia.
Prima di pensare a ricostruire, conviene attivare le funzioni di prestazioni del costruttore, ridurre l’annidamento, eliminare le sezioni duplicate per dispositivo, limitare effetti e widget pesanti e caricare solo le risorse necessarie. Con queste accortezze molti siti raggiungono lo stato buono senza rinunciare allo strumento con cui sono stati costruiti; per gli altri, i dati diranno se è arrivato il momento di cambiare.
