Elementor O Tema Su Misura: Il Costo Reale

La discussione fra Elementor e un tema su misura viene condotta di solito come questione di gusto, e a volte come identità tribale. Non è né l’una né l’altra: è una questione di costo, dalla forma prevedibile. Un page builder sposta il costo dalla costruzione alla vita operativa del sito. Se lo scambio convenga dipende da due numeri che quasi nessuno mette sul tavolo, quante pagine ha il sito e quanto spesso cambiano.

Il dibattito resta irrisolto perché entrambe le parti argomentano per aneddoti. Qualcuno dice che i builder sono lenti, qualcun altro pubblica un punteggio Lighthouse verde, e non si risolve nulla. Le prestazioni sono un costo reale, ma sono una riga di un conto più lungo che porta anche i rinnovi di licenza, uno stack di plugin, la produttività redazionale, la messa a norma dell’accessibilità e, alla fine, il prezzo per riportare fuori i tuoi contenuti.

Elementor non è un cattivo strumento. Per una vasta categoria di siti è la risposta corretta, e un confronto onesto lo dice per primo. La domanda utile non è se il builder sia buono, ma dove smette di convenire, e quel confine è più netto di quanto le urla lascino intendere.

Cosa costa davvero meno, Elementor o un tema su misura? Elementor costa meno da costruire e di più da mantenere; il tema su misura fa l’inverso. Il punto di incrocio sta più o meno dove un sito supera le 25 pagine ricavate da un piccolo insieme di layout ripetuti, paga già tempo di sviluppo e deve rispettare uno standard di prestazioni o accessibilità invece di limitarsi ad aspirarvi. Sotto quella linea il builder di solito vince sul costo totale. Sopra, il risparmio di costruzione si consuma in due o tre anni.

Cosa fa davvero un page builder al tuo markup

Sostenere che i builder siano lenti non serve, perché a volte non lo sono. Ciò che è stabile è il meccanismo, e ha tre parti. Ognuna è una tendenza e non una certezza, ed è esattamente per questo che i duelli a colpi di screenshot non risolvono mai nulla.

La profondità del documento

Un builder visuale deve rappresentare il layout come contenitori, e i contenitori sono elementi. Una sezione contiene una colonna, la colonna contiene un widget, il widget contiene il proprio wrapper e poi il contenuto. Un markup scritto a mano esprimerebbe lo stesso design in due o tre elementi dove il builder ne emette sei o sette.

Quella profondità non è gratuita. Ricalcolo degli stili, layout e paint scalano tutti con quanti nodi il browser deve percorrere e con quanto sono complessi i selettori che li intercettano. La guida di Google su dimensione del DOM e interattività fissa i riferimenti pratici: Lighthouse avvisa oltre gli 800 nodi e considera eccessiva una pagina oltre i 1.400. Le pagine costruite con un builder superano i 1.400 di routine, e una pagina lunga con vari slider e un mega menu arriva a tre o quattromila.

Il costo si paga due volte. Una al primo rendering, e di nuovo a ogni interazione che modifica l’albero, perché aprire una fisarmonica o filtrare un elenco riporta il browser sullo stesso lavoro.

Fogli di stile generati pagina per pagina

L’articolo tecnico di Elementor sulle prestazioni di rendering del CSS descrive senza giri di parole le due modalità di output: il CSS viene stampato dentro un tag <style> nel documento oppure scritto in un file che si carica con la pagina. L’output su file è statico e viene rigenerato solo quando la pagina cambia.

Entrambe le modalità hanno un costo facile da non vedere. Lo stile è generato per singola pagina anziché condiviso su tutto il sito, così un visitatore che passa dalla home a una pagina di servizio scarica un foglio di stile nuovo invece di riusarne uno in cache. Con l’incorporamento interno il CSS viaggia dentro l’HTML a ogni richiesta, il che gonfia il documento e vanifica del tutto la cache.

Un tema costruito a mano ribalta la situazione. Un foglio di stile, messo in cache una volta, riusato ovunque, e la seconda pagina che un visitatore apre costa quasi nulla in CSS.

Script che girano prima che il layout si assesti

I widget portano con sé il proprio JavaScript. Slider, tab, fisarmoniche, contatori, popup e moduli registrano ciascuno i propri handler, e diversi di essi decidono le dimensioni finali a runtime. Quando la posizione di un contenuto si conosce solo dopo che uno script è girato, il browser disegna un layout e poi ne disegna un altro.

È il classico schema dello spostamento del layout, e si somma a media senza dimensioni e a web font caricati tardi. Nulla di tutto ciò è irrimediabile, ma le correzioni sono per singolo widget, vanno rifatte a ogni modifica della pagina, e chi modifica la pagina di solito non è la persona che le ha applicate.

Core Web Vitals, e quale metrica un builder peggiora davvero

Prima fissiamo l’insieme giusto di metriche, perché buona parte dei commenti sui builder discute ancora di una metrica che non esiste più. I Core Web Vitals sono tre, e le definizioni di Google ne danno con precisione le soglie di una buona esperienza: il Largest Contentful Paint dovrebbe avvenire entro 2,5 secondi dall’inizio del caricamento, l’Interaction to Next Paint dovrebbe stare a 200 millisecondi o meno, e il Cumulative Layout Shift a 0,1 o meno. Tutte e tre si valutano al 75esimo percentile dei caricamenti, misurate separatamente per mobile e desktop.

Il First Input Delay non esiste più. L’Interaction to Next Paint lo ha sostituito come Core Web Vital stabile il 12 marzo 2024, e il cambio conta qui perché il FID misurava solo il ritardo prima che la prima interazione venisse gestita, il che lusingava le pagine pesanti. L’INP misura l’intero percorso dall’input al frame successivo disegnato, su tutte le interazioni della pagina, e prende un valore vicino al peggiore.

Perché l’INP è la metrica che resiste

Il Largest Contentful Paint è in larga parte un problema di consegna. Hosting migliore, una CDN, immagini dimensionate e compresse come si deve, un’immagine principale precaricata, meno risorse che bloccano il rendering, e la maggior parte dei siti con builder scende sotto i 2,5 secondi senza toccare il builder.

Il Cumulative Layout Shift è un problema di disciplina. Imposta le dimensioni dei media, riserva lo spazio per tutto ciò che viene iniettato, carica i font in modo che non rifluiscano la pagina, e 0,1 diventa raggiungibile.

L’Interaction to Next Paint è un problema strutturale. Misura quanto lavoro deve fare il thread principale prima di poter rispondere, e un markup profondo più una pila di script dei widget sono esattamente quel lavoro. Non ne esci con la cache e un server più veloce non aiuta. È qui che una pagina Elementor e un tema su misura leggero divergono di più, ed è la metrica che resta divergente dopo che l’ottimizzazione facile è finita. La nostra guida all’audit delle prestazioni WordPress spiega come separare questi tre problemi su un sito in produzione.

Cosa è migliorato davvero

Essere onesti qui non è cortesia, è precisione, perché molte delle critiche rivolte a Elementor sono rivolte alla sua versione del 2019.

Elementor oggi è pubblicato in versione 4.2.4 nella directory dei plugin WordPress, richiede WordPress 6.8 o superiore e PHP 7.4 o superiore, e dichiara oltre 10 milioni di installazioni attive. L’editor V4 ha ricostruito l’architettura degli elementi attorno a ciò che Elementor chiama elementi atomici, con un approccio CSS first e, nelle parole dell’azienda, senza «il sovraccarico del vecchio gonfiore del DOM». Elementor dichiara che l’Atomic Editor è l’esperienza predefinita per tutti i nuovi siti a partire dalla 4.0.

Due precisazioni pesano più del titolo. Primo, i siti esistenti non lo ottengono aggiornando. Elementor è esplicito nel dire che l’aggiornamento alla 4.0 non tocca i siti già in produzione e che le nuove funzioni si abilitano manualmente, quindi un sito costruito nel 2022 conserva il proprio output del 2022 finché qualcuno non lo ricostruisce. Secondo, durante la migrazione gli elementi V3 e V4 convivono sulla stessa pagina, il che significa che una pagina migrata a metà porta entrambe le architetture ed entrambi i carichi.

Considera il miglioramento reale e rivolto in avanti. Cambia ciò che un nuovo sito Elementor può essere. Non cambia ciò che il tuo sito attuale è adesso.

Il meccanismo di lock in, formulato come si deve

È l’argomento più forte contro un builder ed è quasi sempre formulato male. La versione consueta, quella per cui ti resta una schermata di shortcode rotti, non è proprio ciò che accade ed è facile da liquidare. La versione esatta è peggiore.

La documentazione di Elementor sulla struttura dati dice esattamente dove vivono le tue pagine: l’editor salva dati di pagina e layout in formato JSON come metadati dell’articolo WordPress, nella tabella wp_postmeta, e la documentazione nota che sono conservati in un campo personalizzato privato, non visibile nella bacheca di WordPress. Il tuo layout, il tuo stile e buona parte dei tuoi testi stanno in una struttura serializzata che solo Elementor sa leggere.

Confrontalo con il core di WordPress. L’editor a blocchi serializza i blocchi in post_content come HTML con delimitatori in commenti HTML, con gli attributi portati come letterali JSON dentro i commenti. L’obiettivo dichiarato del core è un’unica fonte di verità che resti leggibile e compatibile con tutto il resto che tocca i contenuti WordPress. Togli l’editor a blocchi e nel campo del contenuto resta comunque HTML valido.

La differenza è tutta qui. Un sistema tiene i tuoi contenuti dove WordPress ha sempre tenuto i contenuti. L’altro li mette in un campo privato accanto.

Cosa significa per il restyling fra tre anni

Disattiva Elementor e le pagine non degradano con grazia. WordPress renderizza post_content, che per una pagina costruita con il builder è tipicamente vuoto o un frammento, quindi la pagina diventa bianca anziché essenziale. Non è stato cancellato nulla, ma non viene renderizzato nulla.

In pratica questo trasforma un restyling in due progetti. Non stai cambiando tema, stai facendo una migrazione di contenuti: estrarre l’HTML renderizzato pagina per pagina, oppure interpretare il JSON, e poi ricostruire ogni layout nel nuovo sistema. Mettilo a budget come migrazione ed è gestibile. Scoprirlo a metà di un restyling è la cosa che fa saltare i tempi. Vale la stessa disciplina di qualsiasi migrazione di CMS, dove il lavoro che decide l’esito avviene prima che qualcosa venga spento.

Le ragioni oneste a favore di Elementor

Esiste una categoria reale di siti in cui il builder non è un compromesso ma la decisione tecnica giusta, ed è una categoria ampia.

Un sito vetrina da dieci a venti pagine. Nessuno sviluppatore interno e nessuna intenzione di assumerne uno. Una persona del marketing che deve cambiare un titolo, sostituire una foto o pubblicare una landing page questo pomeriggio, senza ticket, senza branch e senza deploy. Un budget che davvero non arriva a una costruzione su misura, dove l’alternativa non è un sito migliore ma uno peggiore, o nessun sito.

Per questo profilo un builder converte una dipendenza da sviluppatore in un abbonamento, e di solito è un buon scambio. Un sito che nessuno in azienda sa aggiornare è un asset peggiore di un sito un po’ più pesante che il team marketing possiede davvero. Il modo in cui fallisce la strada su misura non è la lentezza, è un sito che invecchia perché ogni modifica richiede qualcuno di esterno.

C’è una seconda ragione onesta, la velocità fino al primo fatturato. Portare online un sito credibile in tre settimane anziché in tre mesi ha un valore che nessun numero dei Core Web Vitals cattura, e per un’impresa giovane quel valore è spesso più grande di tutto quanto discusso sopra.

La regola di decisione fra Elementor e tema su misura

Ecco una regola da applicare al tuo sito e non a uno generico. Valuta questi sei punti e considera tre o più di essi come il momento in cui un builder costa più di quanto faccia risparmiare.

Numero di pagine contro numero di template. Più di 25 pagine circa costruite con meno di otto layout distinti significa che stai pagando la ripetizione. Un tema esprime quella ripetizione una volta, un builder te la fa mantenere in 25 posti.

Produttività redazionale. Più di poche modifiche ai contenuti a settimana, fatte da più di una persona, significa che gli strumenti e il processo di revisione contano più dell’esperienza di editing.

Un design system che esiste già. Se in Figma c’è un vero insieme di token, un tema può codificarlo una volta e imporlo. Un builder non può imporre nulla, perché ogni pagina può sovrascrivere tutto.

Contenuti multilingua. Ogni lingua moltiplica le strutture del builder da mantenere, e i plugin di traduzione vanno d’accordo male con un layout conservato fuori da post_content.

Un budget di prestazioni contrattuale. Se i Core Web Vitals compaiono in una gara, in uno SLA o in un contratto con il cliente, ti serve una soglia che controlli tu e non un numero che speri.

Un obbligo di accessibilità. Trattato più sotto, e da solo spesso decisivo.

Se nessuno di questi punti è vero, usa il builder e investi il risparmio nei contenuti. Se ne sono veri quattro o più, un tema su misura non è un lusso, è l’opzione più economica sull’arco di vita del sito.

La via di mezzo che quasi tutti i confronti saltano

Esiste una terza opzione, e non è né un tema su misura né un builder di terze parti. Il core di WordPress rilascia il full site editing dalla 5.9, di gennaio 2022, e il Site Editor è ormai una parte matura del prodotto.

Il vincolo importante è dichiarato senza mezzi termini nella documentazione del Site Editor: il Site Editor è disponibile solo se installi e attivi un tema a blocchi. Con uno attivo, i redattori ottengono Identity, Styles, Pages, Navigation, Patterns e Templates, e da WordPress 6.3 possono gestire e modificare le pagine da lì dentro. Stili globali, tipografia, palette di colori e layout si impostano una volta nel theme.json del tema e valgono per tutto il sito.

Questo risolve gran parte del valore reale del builder. Il marketing può cambiare una pagina, modificare un header, ridisegnare il sito e pubblicare senza un deploy. In più ti dà ciò che il builder non dà: contenuti in post_content, un design system definito dallo sviluppatore, nessuna licenza di terze parti e un export nel Site Editor che produce uno zip del tema con i tuoi template e i tuoi stili.

Ciò che non risolve è la disciplina. Un tema a blocchi con un theme.json lasco e una pila di plugin di blocchi di terze parti riproduce i problemi del builder dentro il core, lock in compreso, perché quei blocchi lasciano le tue pagine quando se ne va il plugin. Serve comunque uno sviluppatore per impostarlo bene, e spostarci sopra un sito Elementor esistente resta una migrazione di contenuti.

Accessibilità, dove i builder falliscono in silenzio

È il modo di fallire che nessuno mostra in demo, ed è quello che diventa un problema legale anziché una pagina lenta.

L’ordine dei titoli segue il layout, non il significato. Qualcuno sceglie H3 perché H2 sembrava troppo grande, e la struttura del documento smette di descrivere il contenuto. È il criterio 1.3.1 Info and Relationships di WCAG 2.2 a livello A, con 2.4.6 Headings and Labels a livello AA. Nel builder nulla lo impedisce, perché il controllo del titolo è un controllo di stile.

I contrasti predefiniti. 1.4.3 Contrast (Minimum) a livello AA richiede un rapporto di almeno 4,5:1 per il testo normale e 3:1 per il testo grande, e 1.4.11 Non-text Contrast almeno 3:1 per i componenti di interfaccia e gli oggetti grafici rispetto ai colori adiacenti. Testo grigio chiaro su bianco e icone pallide su una sezione colorata sono i due difetti più comuni che troviamo, entrambi presi da un template che in demo stava bene.

L’ordine di focus dentro contenitori annidati. 2.4.3 Focus Order a livello A richiede che i componenti attivabili ricevano il focus in un ordine che preservi significato e operatività, e 2.4.7 Focus Visible a livello AA richiede un indicatore di focus visibile. Contenitori molto annidati, overlay posizionati in assoluto e popup rompono spesso entrambi, e i temi dei builder tolgono di frequente il contorno di focus predefinito perché sembrava poco curato.

Nel Regno Unito questo non è facoltativo per molte organizzazioni. GOV.UK dice esplicitamente che gli enti pubblici devono rispettare WCAG 2.2 a livello AA ai sensi dei Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, e pubblicare una dichiarazione di accessibilità. Il requisito si propaga sempre più agli acquisti privati tramite i questionari fornitori. Correggere markup generato è molto più difficile che correggere markup scritto da te.

Quanto costa davvero ciascuna strada

La riga di licenza che puoi verificare da solo

Prima i prezzi di licenza, perché sono l’unico dato di questa sezione che non è nostro. Elementor pubblica i prezzi direttamente in GBP, quindi non c’è alcuna conversione. Sulla pagina prezzi di Elementor, letta il 2 settembre 2026, i piani annuali vanno da 48 GBP l’anno per Essential, passando per 72 GBP per Advanced Solo e 84 GBP per Advanced, fino a 168 GBP l’anno per Expert. Le fasce in bundle più recenti sono 144 GBP l’anno per Elementor One e 348 GBP l’anno per One Agency.

Gli altri numeri qui sotto sono le fasce che quotiamo noi, non prezzi pubblicati, e presuppongono il sito di una piccola o media impresa britannica anziché un progetto di e-commerce.

Costruzione, costo annuo e restyling finale

Leggilo come prosa, perché la tabella si limita a riassumere. Un sito con builder è il più economico da costruire di un fattore tre o più, e il più caro da mantenere, perché la cifra annua porta la licenza Elementor più gli addon premium che quasi sempre l’accompagnano, più lo stack di plugin che cresce attorno, più il lavoro periodico sulle prestazioni che non finisce mai del tutto.

La colonna del restyling è quella in cui il confronto si scioglie. Ricostruire un sito con builder costa più che ricostruirne uno a tema, per la ragione esposta sopra: il contenuto va estratto prima di poter essere ricostruito. Su cinque anni, un sito con builder da 4.000 GBP e uno su misura da 20.000 GBP finiscono più vicini di quanto entrambe le parti si aspettino, e chi vince dipende dal numero di pagine e dalla frequenza delle modifiche, non dal gusto. La nostra analisi dei costi di un sito spiega come si comportano queste fasce sui progetti più grandi, e la nostra pagina sviluppo di siti web indica cosa comprende una costruzione su misura.

Se sei già su un builder e vuoi uscirne

La migrazione è trattabile se la ordini bene, e dolorosa se non lo fai.

Comincia da un inventario invece che da un piano. Interroga i metadati degli articoli per scoprire quali pagine portano davvero dati del builder, perché sulla maggior parte dei siti sono molte meno del previsto, e gli articoli del blog di solito sono già contenuto semplice. Poi fai il triage: ricostruire, convertire o cancellare. Quasi tutti i siti portano una lunga coda di pagine che nessuno visita da un anno e per la cui migrazione nessuno dovrebbe pagare.

Estrai prima di ricostruire. Renderizza ogni pagina superstite e conserva l’HTML, oppure interpreta il JSON dai metadati, così hai il contenuto in una forma indipendente dal plugin. Fallo anche per le pagine che intendi ricostruire a mano, perché è la tua unica copia una volta che il plugin se ne va.

Tieni gli URL. Una ricostruzione non è un motivo per cambiare indirizzi, e ogni indirizzo cambiato ha bisogno di un redirect verso il suo equivalente preciso.

Poi lavora pagina per pagina, tenendo Elementor installato finché l’ultima pagina non ne è uscita, e misura l’Interaction to Next Paint prima e dopo su dati di campo reali anziché su un punteggio di laboratorio, perché un punteggio di laboratorio su un portatile veloce ti dirà che il problema non c’è mai stato.

Dove porta tutto questo

La scelta non è ideologica. Un builder è una risposta legittima per un sito piccolo e poco mutevole senza sviluppatore, ed è la risposta giusta molto più spesso di quanto agli sviluppatori piaccia ammettere. Smette di essere la risposta giusta quando entrano in gioco il numero di pagine, il riuso dei template, la produttività redazionale o un requisito rigido di prestazioni o accessibilità, e il costo di restarci oltre quel punto si paga in silenzio, in licenze annuali, in correzioni e infine in una migrazione.

Mecanik costruisce entrambe le cose. Gestiamo siti con builder per i clienti in cui è l’economia sensata, e li sostituiamo quando smette di esserlo, di solito con un tema a blocchi sul core anziché con una costruzione interamente su misura. Se vuoi una risposta netta su quale lato della linea si trovi il tuo sito, le nostre pagine sviluppo di siti web e sviluppo WordPress spiegano come lo inquadriamo, e la guida su cosa chiedere quando assumi uno sviluppatore WordPress spiega come mettere alla prova chiunque ti parli, noi compresi.

Domande frequenti

Elementor fa male alla SEO? No. Elementor non blocca l’indicizzazione, e una pagina Elementor fatta bene si posiziona come qualunque altra. La pressione che esercita sulla ricerca è indiretta e ricade sui Core Web Vitals, soprattutto sull’Interaction to Next Paint, perché markup generato profondo e script dei widget danno più lavoro al thread principale. I Vitals sono uno dei tanti segnali, quindi una pagina lenta con contenuti migliori batte ancora una pagina veloce con contenuti peggiori.

Cosa succede alle mie pagine se disattivo Elementor? Il layout sparisce. Elementor tiene la struttura della pagina come JSON in un campo personalizzato privato della tabella wp_postmeta anziché in post_content, quindi disattivando il plugin WordPress renderizza solo ciò che sta in post_content, che per una pagina del builder di solito è vuoto o un frammento. Non viene cancellato nulla, ma non viene nemmeno renderizzato nulla, e recuperare le pagine è una migrazione di dati, non un cambio di tema.

Quanto costa un tema WordPress su misura nel Regno Unito? Le fasce che quotiamo vanno all’incirca da 12.000 a 40.000 GBP per un tema su misura, da 6.000 a 18.000 GBP per un tema a blocchi costruito sul core di WordPress e da 2.000 a 6.000 GBP per un sito con builder. La cifra su misura sembra la peggiore il primo giorno e la migliore sull’arco di cinque anni, perché non porta licenze, ha uno stack di plugin più piccolo e un restyling finale molto più economico.

Un sito Elementor può superare i Core Web Vitals? Sì, e molti ci riescono. Un Largest Contentful Paint sotto i 2,5 secondi e un Cumulative Layout Shift sotto 0,1 sono di solito raggiungibili con buon hosting, media dimensionati e moderazione sui widget. L’Interaction to Next Paint sotto i 200 millisecondi è quella che resiste, perché riflette il lavoro del thread principale e non la consegna, ed è la metrica in cui markup del builder e script dei widget ti costano di più.

Un tema a blocchi è un’alternativa migliore a Elementor? Spesso sì, ed è l’opzione che quasi tutti i confronti saltano. Il contenuto a blocchi è conservato in post_content come HTML con delimitatori in commenti, quindi sopravvive a un cambio di tema, e il Site Editor consente al marketing di modificare template e stili senza un deploy. Non è a costo zero: il Site Editor richiede un tema a blocchi, e qualcuno deve definire il design system come si deve, altrimenti hai ricostruito lo stesso problema dentro il core.