Tutti usano Elementor come page builder. Pochissimi lo usano come framework di sviluppo.
Ho passato anni a sentire developer lamentarsi: “è lento”, “gonfia il codice”, “non scala”. E capisco. Se guardi un sito Elementor costruito nel modo standard — widget nativi impilati, plugin di terze parti per ogni funzionalità, CSS generato automaticamente per cose che potevano essere scritte in venti righe a mano — la critica è legittima.
Ma il problema non è Elementor. È il livello di sviluppo che ci metti sopra.
Il malinteso di fondo
Elementor è stato progettato per essere accessibile. Drag and drop, widget visivi, anteprima in tempo reale — è pensato per permettere a chiunque di costruire un sito senza scrivere codice.
E funziona. Milioni di siti lo dimostrano.
Il problema è quando uno sviluppatore lo usa esattamente come lo userebbe un cliente finale — trascinando widget standard, installando plugin per ogni necessità, lasciando che sia Elementor a decidere come strutturare il codice — e poi si stupisce che il risultato sia pesante e difficile da mantenere.
Usare Elementor come developer non significa usarlo meno. Significa usarlo diversamente.
Cosa cambia quando smetti di usare i widget standard per tutto
Elementor espone un’API PHP completa per registrare widget custom. Non è una feature nascosta o sperimentale — è documentata, stabile, e pensata esattamente per questo.
Quando sviluppo una funzionalità complessa — un sistema di prenotazione, una griglia dinamica collegata a un Custom Post Type, un modulo con logica condizionale — non cerco un plugin che faccia quella cosa. Costruisco un widget che fa esattamente quella cosa, niente di più.
La differenza pratica è enorme.
Un plugin preconfezionato per le prenotazioni carica il suo JavaScript su ogni pagina del sito, anche su quelle in cui non c’è nessun calendario. Ha il suo CSS con classi che spesso entrano in conflitto con il tema. Ha opzioni che non userai mai e che comunque pesano. E soprattutto — quando il plugin si aggiorna, devi sperare che non rompa nulla.
Un widget custom carica solo quello che serve, solo dove serve. Il CSS è scritto per quel progetto specifico. Non ci sono conflitti perché non c’è nulla con cui entrare in conflitto. E quando Elementor si aggiorna, il widget si aggiorna con lui — perché estende l’API ufficiale, non la bypassa.
Un esempio concreto
Ho sviluppato un sistema di prenotazione per uno studio medico. Requisiti: slot dinamici sincronizzati con Google Calendar, logica di disponibilità custom, differenziazione per tipo di visita, interfaccia gestibile dall’editor Elementor senza toccare una riga di codice.
Con un plugin preconfezionato avrei avuto: 400kb di JavaScript inutile, almeno tre plugin in conflitto tra loro, un tema che si comporta in modo strano sulla pagina di prenotazione, e un cliente che mi chiama ogni settimana perché qualcosa non funziona dopo un aggiornamento.
Con un widget custom: zero conflitti, LCP sotto il secondo, cliente completamente autonomo. L’editor mostra solo i controlli che gli servono — tipo di visita, durata dello slot, orari disponibili. Il resto è gestito dalla logica PHP nel backend.
Questo non è possibile con i widget standard di Elementor. È possibile solo quando lo tratti come un framework su cui costruire, non come uno strumento da usare.
Il controllo che recuperi
C’è un altro aspetto che chi non ha mai sviluppato widget custom sottovaluta: il controllo totale sul markup.
Con i widget nativi di Elementor, l’HTML generato è quello che è. Puoi aggiustarlo con CSS fino a un certo punto, ma la struttura di base è fuori dal tuo controllo. Se il designer ha fatto un mockup con una struttura specifica — e quasi sempre lo ha fatto — prima o poi ti trovi a fare acrobazie per avvicinarti al risultato.
Con un widget custom, il markup è esattamente quello che scrivi. Nessun div extra, nessuna classe generata automaticamente che poi devi sovrascrivere. Il risultato rispetta pixel per pixel quello che il designer aveva in mente, perché hai deciso tu ogni singolo elemento.
Questo conta soprattutto quando lavori con clienti strutturati — studi professionali, cliniche, aziende — che hanno brand identity precisi e non accettano “quasi uguale” come risposta.
L’editor resta pulito
Un vantaggio che tende a emergere solo dopo la consegna è la qualità dell’esperienza di gestione per il cliente.
Un sito costruito con widget custom e ACF ha un editor che mostra solo quello che il cliente deve toccare. Vuole aggiornare i servizi? C’è una sezione dedicata con i campi giusti. Vuole aggiungere un membro del team? Compila un form con nome, ruolo, foto e bio. Il layout si aggiorna automaticamente, senza che il cliente debba avvicinarsi al visual editor.
Confronta questo con un sito costruito interamente con widget standard, dove il cliente — per aggiornare qualsiasi cosa — deve aprire Elementor, navigare tra sezioni e colonne, trovare il widget giusto, modificarlo, e sperare di non spostare accidentalmente qualcosa. Nei siti complessi, questo porta inevitabilmente a layout rotti e telefonate di supporto.
Un sito ben costruito è un sito che il cliente può gestire senza di te. Questo non riduce il tuo valore — lo aumenta, perché ti permette di concentrarti su nuovi progetti invece di fare supporto continuo su quelli vecchi.
Performance: il nodo che tutti ignorano
Le performance di un sito Elementor dipendono quasi interamente da come viene sviluppato. Elementor in sé, usato correttamente, non è intrinsecamente lento.
Tre ottimizzazioni che fanno la differenza reale:
Disabilita i widget che non usi. Elementor carica gli stili di tutti i widget registrati per impostazione predefinita — anche quelli che non compaiono in nessuna pagina del sito. Disabilitare quelli inutilizzati dal pannello di impostazioni riduce il CSS caricato di una percentuale significativa, senza toccare nulla di tecnico.
Carica script e stili solo dove servono. Un widget custom dichiara esplicitamente le sue dipendenze JS e CSS. Elementor le carica solo nelle pagine in cui il widget è presente. Questo da solo elimina il problema principale di performance che si vede nei siti con molti plugin — script caricati globalmente che rallentano pagine che non li usano affatto.
Se lavori in agenzia
Se gestisci progetti dove Elementor sta diventando un limite tecnico — funzionalità che non riesci a costruire nel modo giusto, performance che non riesci a tenere sotto controllo, codice che cresce in modo ingestibile — il problema raramente è il builder.
È l’approccio allo sviluppo.
Io collaboro in white-label con agenzie che vogliono gestire la relazione con il cliente mantenendo il controllo del progetto, ma hanno bisogno di qualcuno che gestisca la parte di sviluppo custom. La parte tecnica rimane mia, la parte commerciale rimane tua.
Se hai un progetto di questo tipo, parliamoci.