La risposta breve: no, Elementor non è lento.
La risposta onesta: Elementor installato con le impostazioni di default, venti plugin attivi, widget caricati su ogni pagina e un tema generico — sì, quello è lento. Ma il problema non è Elementor. È l’approccio.
Il sito che stai leggendo gira su Elementor. Score PageSpeed mobile: 98. Accessibilità: 91. Best practice: 100. SEO: 100.
Questo articolo racconta esattamente cosa ho fatto per arrivarci — non teoria, ma configurazione reale.
Il punto di partenza: cosa rallenta davvero un sito Elementor
Elementor carica asset. Per ogni widget registrato — anche quelli che non usi — può accodare CSS e JavaScript. Su un’installazione standard con Elementor Pro attivo, il browser si trova a scaricare roba che quella pagina specifica non usa mai.
A questo si aggiunge tutto quello che WordPress porta di default: Gutenberg, i blocchi, l’editor classico, gli emoji, gli embed oEmbed, il heartbeat, xmlrpc, i commenti. Cose utili in certi contesti, peso morto in un sito costruito con Elementor dove non servono.
Il lavoro di ottimizzazione è quindi su due fronti: togliere quello che non serve, e configurare correttamente quello che rimane.
Setup di base: tema e struttura
Tema: Hello Elementor con child theme custom.
Hello Elementor è il tema ufficiale Elementor — zero stili superflui, nessun JavaScript aggiunto, nessuna feature del tema che si sovrappone a quello che fa Elementor. È il punto di partenza corretto per chiunque voglia performance serie.
Il child theme serve per le personalizzazioni CSS e PHP che devono sopravvivere agli aggiornamenti di Hello. Non si tocca il tema padre.
Container: vecchio sistema sezioni/colonne.
Sì, ancora il sistema classico. Flexbox Container è più pulito sul DOM ma introduce cambiamenti di comportamento che su progetti in produzione gestisco con attenzione. Il punto non è quale sistema usi — è che ogni elemento nel layout abbia uno scopo preciso e non ci siano wrapper annidati inutilmente.
Prima mossa: disabilitare i widget Elementor non usati
Elementor Pro ha decine di widget. Ogni widget registrato può caricare il proprio CSS anche su pagine dove non compare mai.
Dal pannello Elementor → Elementor → Elementi, disabilito tutto quello che non uso nel progetto. Su un sito per uno studio professionale bastano una manciata di widget — testo, immagine, bottone, form, qualche widget custom. Il resto è peso.
Questa singola operazione riduce sensibilmente il CSS totale caricato da Elementor su ogni pagina.
Immagini: WebP e lazy load
Tutte le immagini vengono convertite in WebP prima dell’upload. WebP pesa mediamente il 25-35% in meno rispetto a JPEG a parità di qualità visiva — su mobile è la differenza tra un LCP sotto i 2 secondi e uno sopra i 3.
Lazy load nativo del browser (loading="lazy") su tutte le immagini below the fold. L’immagine hero — quella above the fold che incide sul LCP — viene invece precaricata esplicitamente con <link rel="preload"> nell’head.
LiteSpeed Cache: configurazione
Uso LiteSpeed Cache come layer di cache e ottimizzazione degli asset.
Le configurazioni che fanno differenza reale:
- Minify HTML, CSS, JS: riduce il peso dei file trasferiti.
- Combine CSS: un solo file CSS invece di dieci richieste separate.
- Defer JS: i file JavaScript non bloccanti vengono caricati dopo il rendering della pagina.
- Critical CSS: LiteSpeed genera automaticamente il CSS critico per il rendering above the fold — il browser non deve aspettare l’intero foglio di stile per mostrare la pagina.
- Object cache: riduce le query al database su pagine che cambiano raramente.
Una nota sul Combine CSS con Elementor: a volte genera conflitti visivi. Si testa sempre in staging prima di attivare in produzione.
Il plugin custom per ripulire WordPress
Questa è la parte che fa la differenza maggiore su un sito Elementor dove Gutenberg e tutto l’ecosistema dei blocchi non serve.
Ho un piccolo plugin custom — una decina di filtri e action hook — che disabilita quello che WordPress carica di default e che in questo contesto è solo rumore.
'disable_gutenberg' => 1, // rimuove l'editor a blocchi e i suoi asset
'disable_comments' => 1, // disabilita il sistema commenti
'remove_comments_menu' => 1, // pulisce il menu admin
'redirect_comments_page' => 1, // redirect per eventuali URL diretti
'disable_xmlrpc' => 1, // chiude xmlrpc.php (sicurezza + performance)
'disable_emojis' => 1, // rimuove lo script emoji di WordPress
'disable_embeds' => 1, // rimuove wp-embed.min.js
'disable_heartbeat' => 1, // ferma le chiamate AJAX periodiche al server
'remove_block_css' => 1, // rimuove i CSS dei blocchi Gutenberg
Ogni voce è configurabile separatamente — posso attivare solo quello che serve per ogni progetto specifico.
Perché questo fa la differenza:
disable_emojis rimuove una chiamata a https://s.w.org/images/core/emoji/ e uno script JS che non ha nessun motivo di esistere su un sito professionale.
disable_embeds rimuove wp-embed.min.js, un file caricato su ogni pagina per gestire gli oEmbed — che su un sito senza contenuto embeddato è puro peso.
disable_heartbeat ferma le chiamate AJAX che WordPress fa ogni 60 secondi per mantenere la sessione dell’editor attiva. Sul frontend non serve a niente.
remove_block_css rimuove wp-block-library.css — i fogli di stile di Gutenberg. Su un sito Elementor questi non vengono mai usati ma vengono caricati comunque, a meno che non li rimuovi esplicitamente.
Il risultato
98 Prestazioni · 91 Accessibilità · 100 Best practice · 100 SEO su dispositivi mobili.
Non è un caso isolato — è il risultato replicabile di una configurazione precisa. Ogni progetto parte da questo setup e viene adattato in base alle esigenze specifiche.
Cosa non ho fatto
Per completezza: non ho usato CDN di terze parti, non ho ottimizzato il server oltre LiteSpeed, non ho implementato service worker o tecniche PWA. Il 98 è ottenuto con strumenti standard e configurazione attenta — niente di esoterico.
Flexbox Container probabilmente darebbe qualche punto in più sul DOM size. È sul backlog.
Conclusione
Elementor non è il problema. È uno strumento — e come tutti gli strumenti, il risultato dipende da chi lo usa e come.
Se un sito Elementor è lento, le cause sono quasi sempre le stesse: widget non necessari caricati su tutto il sito, asset WordPress mai disabilitati, immagini non ottimizzate, nessuna cache configurata correttamente.
Risolti questi punti, 98 su PageSpeed non è un obiettivo irraggiungibile. È il punto di partenza.
Stai lavorando su un sito Elementor con problemi di performance? Scrivimi — analizzo la situazione e ti dico cosa si può fare.
