Il sito del mese di marzo 2026 è quello di Stoneprime US, un sito con performance eccezionali unito a un design futuristico. Abbiamo chiesto a Carmine Santoro, dell’agenzia Web Domus, di raccontarci i dettagli tecnici che li hanno portati a ottenere tali risultati.
Come abbiamo portato Stoneprime vicino al 100% su PageSpeed con Elementor
Quando abbiamo iniziato a lavorare al progetto Stoneprime US, l’obiettivo era chiaro fin dal primo confronto con il cliente: costruire un sito capace di trasmettere innovazione, autorevolezza e visione internazionale a un pubblico di investitori istituzionali, professionisti del settore biotech e stakeholder abituati a standard elevati.
In questo contesto, il design da solo non basta. Un sito rivolto a professionisti della finanza deve caricarsi velocemente, funzionare perfettamente su mobile e trasmettere affidabilità al primo colpo d’occhio. Performance e design, in questo progetto, non erano due obiettivi separati: erano la stessa cosa.
Abbiamo scelto Elementor Pro con il tema Hello Elementor — con child theme personalizzato — come base di sviluppo. Una combinazione che ci garantisce il massimo controllo creativo mantenendo il codice il più leggero possibile. Nessun tema preconfigurato, nessun layout predefinito: ogni sezione, ogni widget e ogni dettaglio visivo sono stati costruiti da zero, per un risultato su misura al 100%.
Il punto di partenza: un hosting che frenava tutto
Prima ancora di parlare di ottimizzazione, è necessario essere onesti su una cosa: il problema non era Elementor. Era l’infrastruttura.
Il sito era ospitato su un hosting condiviso che non era in grado di soddisfare le esigenze di un progetto con ambizioni di prestazioni elevate. I numeri parlavano chiaro: punteggio 54% su mobile su Google PageSpeed Insights, con un First Contentful Paint (FCP) intorno ai 10,5 secondi e un Largest Contentful Paint (LCP) che superava i 15 secondi. Tempi inaccettabili per qualsiasi sito professionale.
Il primo intervento è stato sui plugin di cache e ottimizzazione. Una precisazione importante: in tutto il processo abbiamo deliberatamente scelto di lavorare esclusivamente con plugin gratuiti, escludendo le soluzioni commerciali a pagamento. Una scelta che ha reso il percorso più impegnativo, ma che dimostra che risultati eccellenti sono raggiungibili anche senza budget per i tool.
Abbiamo testato diverse soluzioni, ognuna con le sue criticità:
WP Super Cache + Autoptimize — il punto di partenza. Autoptimize è utile per aggregare e minificare CSS e JS, ma con Elementor genera facilmente conflitti. L’aggregazione dei file CSS altera l’ordine di caricamento degli stili dinamici di Elementor, con il risultato che il layout si rompe visivamente sul frontend. Il workaround — escludere manualmente i path di Elementor — funziona parzialmente, ma riduce sensibilmente i benefici dello strumento.
WP Fastest Cache — più semplice da configurare e più compatibile con Elementor, ma con limitazioni importanti nella versione gratuita. Il Defer JavaScript, funzione chiave per risolvere il render-blocking, è disponibile solo nella versione Premium. Le opzioni di Delay JS e l’ottimizzazione mobile causavano inoltre comportamenti anomali su alcuni widget di Elementor.
WP Rocket — considerato ma scartato, poiché la priorità era trovare una soluzione completamente gratuita. Va detto che è il plugin ufficialmente raccomandato da Elementor, ma ha un costo.
FlyingPress — valutato come alternativa gratuita, ma la versione free risultava troppo limitata per le nostre esigenze.
I miglioramenti c’erano — il punteggio era salito da 54 a circa 65 — ma erano parziali e instabili. Stava diventando chiaro che nessun plugin, da solo, avrebbe potuto compensare i limiti dell’hosting sottostante.
La svolta: il cambio di hosting
Dopo settimane di configurazioni, test e workaround, la conclusione era inevitabile: il problema non si risolveva a livello di plugin, ma a quello di infrastruttura.
La decisione è stata di cambiare provider, scegliendo una soluzione basata su server LiteSpeed. Non si tratta di una scelta banale: non tutti i provider offrono questa tecnologia. Chi non ha questa possibilità può valutare un VPS con LiteSpeed installato manualmente, oppure soluzioni di hosting managed compatibili.
La differenza rispetto ad Apache o Nginx è sostanziale. LiteSpeed è nativamente integrato con il plugin LiteSpeed Cache, che non è un semplice plugin di cache come gli altri: è un’estensione diretta del server stesso. Operazioni come il Full Page Cache, la compressione delle risorse, il preload e la gestione del Critical CSS vengono eseguite a livello server, con una velocità ed efficienza che nessun plugin su Apache o Nginx può replicare.
Il risultato è stato immediato: i conflitti CSS con Elementor, il render-blocking e i tempi di risposta del server si sono ridimensionati drasticamente — senza i continui workaround che avevano caratterizzato le settimane precedenti.
I problemi tecnici risolti con Elementor
Il cambio di hosting aveva rimosso il freno principale, ma il lavoro tecnico non era finito. Alcune criticità erano legate direttamente al modo in cui Elementor genera e serve il codice.
Il conflitto CSS
Elementor genera dinamicamente decine di file CSS separati — stili per ogni widget, per ogni addon, per ogni breakpoint — e li carica nell’<head> della pagina. Quando un plugin di cache tenta di aggregarli in un unico file, l’ordine di caricamento viene alterato e il layout si rompe visivamente.
La soluzione non è aggregare i CSS di Elementor, ma agire diversamente: nelle impostazioni native (Settings → Performance → CSS Print Method) abbiamo impostato il metodo su Internal Embedding, che incorpora gli stili direttamente nell’HTML anziché caricarli come file esterni. Questo elimina gran parte delle richieste HTTP bloccanti senza compromettere l’aggregazione. Coerentemente, in LiteSpeed Cache la voce CSS Combine è disattivata.
Il problema dell’immagine LCP: il logo con loading="lazy"
Uno dei problemi più subdoli era il logo del sito, identificato da PageSpeed Insights come elemento LCP. Veniva caricato con loading="lazy" — esattamente l’opposto di ciò che serve per l’elemento principale della pagina.
Il primo tentativo è stato di inserire i percorsi del logo nel campo Lazy Load Image Excludes di LiteSpeed Cache. La configurazione era corretta, ma il problema persisteva. Il motivo: Elementor stesso, attraverso il proprio widget immagine, aggiungeva autonomamente l’attributo loading="lazy" — completamente al di fuori del controllo di LiteSpeed Cache.
La soluzione definitiva è stata un filtro PHP personalizzato nel functions.php del child theme, che intercetta l’HTML generato da Elementor a valle del suo rendering, rimuove il loading="lazy" e aggiunge fetchpriority="high" — segnalando al browser che quell’immagine è prioritaria. Solo questo approccio, operando direttamente sull’output finale della pagina, ha risolto il problema in modo stabile.
Nota per gli sviluppatori: questo è un caso in cui il problema non si risolve né lato plugin di cache, né lato impostazioni di Elementor. Serve un intervento diretto sul codice. È un pattern che vale la pena conoscere per qualsiasi immagine LCP gestita tramite il widget di Elementor.
Le impostazioni native di Elementor Performance
Spesso sottovalutata, la scheda Elementor → Settings → Performance offre opzioni che da sole producono miglioramenti significativi. Ecco quelle che abbiamo attivato e perché:
- CSS Print Method → Internal Embedding: incorpora gli stili nell’HTML, eliminando richieste HTTP esterne
- Optimized Image Loading → Enable: applica automaticamente
fetchpriority="high"sull’immagine LCP eloading="lazy"sulle immagini below the fold - Load Google Fonts Locally: elimina la dipendenza da server Google esterni, riducendo la catena di richieste critiche e risolvendo il FOIT (Flash of Invisible Text)
- Optimized Gutenberg Loading → Enable: disabilita il caricamento dei CSS e JS di Gutenberg sul frontend, dove non servono su siti costruiti interamente con Elementor
- Lazy Load Background Images → Enable: per le immagini di sfondo non critiche
- Element Cache → Disable: disattivato per evitare conflitti con LiteSpeed Cache, che gestisce la cache a livello server in modo più efficiente
La configurazione di LiteSpeed Cache
Installare LiteSpeed Cache non è sufficiente: il valore reale emerge dalla configurazione corretta. Una singola opzione attivata nel posto sbagliato può rompere il layout, generare conflitti con Elementor o peggiorare le performance, anziché migliorarle.
Full Page Cache — la prima cosa da attivare. Salva le pagine già renderizzate e le serve direttamente, senza eseguire PHP né query al database a ogni richiesta. Su server LiteSpeed questa operazione avviene a livello server, con un guadagno netto e immediato sul Time to First Byte (TTFB). Abbiamo attivato anche la cache per utenti mobile, utenti loggati e chiamate REST API.
Defer JS — l’area più delicata. Abbiamo scelto il Defer (non il Delay, più aggressivo) per eliminare il render-blocking. Nel campo JS Deferred / Delayed Excludes sono stati inseriti jquery.js, jquery.min.js, gtm.js e analytics.js. jQuery deve caricarsi in modo sincrono perché molti script Elementor dipendono da esso; gli script di tracciamento vanno esclusi per non alterare i dati analitici. JS Combine è disattivato, coerentemente con la scelta di non aggregare per evitare conflitti.
Preload e DNS Prefetch — configurati per font e risorse critiche, in modo che il browser risolva in anticipo gli indirizzi DNS e carichi le risorse principali prima che vengano richieste.
Integrazione con Cloudflare — il sito utilizza Cloudflare come CDN con proxy attivo. LiteSpeed Cache si integra nativamente tramite API, permettendo di purgare la cache di Cloudflare direttamente dal pannello WordPress ogni volta che si aggiorna una pagina.
Critical CSS — LiteSpeed Cache può generare automaticamente il Critical CSS — gli stili necessari per il rendering della parte visibile al primo caricamento — e incorporarli inline nell’<head>. Con Elementor è importante verificare visivamente il risultato dopo ogni rigenerazione, poiché a volte alcuni stili vengono estratti in modo non preciso.
Ottimizzazione immagini: doppio livello — per Stoneprime abbiamo adottato un approccio in due fasi:
- Squoosh (strumento gratuito di Google): le immagini principali sono state compresse e convertite in formato AVIF prima ancora di essere caricate su WordPress, con controllo manuale preciso su qualità e peso finale
- Image Optimization di LiteSpeed Cache: per tutte le immagini restanti, il servizio cloud QUIC.cloud converte e comprime automaticamente dalla Media Library di WordPress
Il risultato: 100% delle immagini ottimizzate, senza alcun plugin aggiuntivo.
I risultati
Dopo il cambio di hosting, la configurazione di LiteSpeed Cache e gli interventi tecnici su Elementor, i numeri delle performance hanno raccontato una storia molto diversa da quella da cui eravamo partiti.
| Metrica | Prima | Dopo |
|---|---|---|
| Punteggio PageSpeed Mobile | 54% | ~98% |
| First Contentful Paint (FCP) | 10,5s | ~2s |
| Largest Contentful Paint (LCP) | 15s+ | ottimizzato |
| Time to First Byte (TTFB) | elevato | ridotto significativamente |
Il percorso è stato iterativo: ogni fix risolveva un problema e ne metteva in evidenza un altro. Il punteggio è salito gradualmente — da 54 a circa 65 con i primi interventi sui plugin, poi con il cambio di hosting e la configurazione di LiteSpeed Cache, fino ad avvicinarsi al 100%.
La lezione più importante è che, con Elementor, ogni ottimizzazione va sempre verificata visivamente prima di andare in produzione. Un’opzione attivata nel plugin di cache può migliorare il punteggio PageSpeed di 10 punti e al tempo stesso rompere un widget, uno slider o un’animazione. Performance e integrità visiva devono procedere insieme.
Il riconoscimento finale è arrivato con la nomina a Sito del Mese di Marzo 2026 su Elementor Italia — una conferma non solo della qualità del design, ma anche delle performance tecniche raggiunte.
Conclusioni
Ottimizzare un sito Elementor non è un’operazione lineare. È un processo fatto di test, verifiche visive, piccoli aggiustamenti e — a volte — decisioni strutturali come il cambio di hosting. I risultati eccellenti non arrivano da un singolo plugin o da una configurazione magica, ma da un approccio sistematico che affronta ogni livello dello stack, dall’infrastruttura server fino al singolo attributo HTML di un’immagine.
Nel caso di Stoneprime, tutto questo è stato ottenuto esclusivamente con strumenti gratuiti. Ma è importante sapere che esistono anche percorsi diversi, ugualmente validi a seconda del contesto e del budget disponibile.Tra questi vale la pena citare Redis, una tecnologia di caching in-memory particolarmente efficace per siti ad alto traffico o con contenuti dinamici.
Non è la strada che abbiamo seguito in questo progetto, ma è significativo che Elementor stessa la includa tra le soluzioni supportate nei propri piani di hosting — a conferma del fatto che il tema delle performance server-side è centrale nell’ecosistema di Elementor, e non una questione secondaria da affrontare solo a fine sviluppo.
La lezione più importante che portiamo da questo progetto è una sola: le performance non si aggiungono alla fine, si costruiscono fin dall’inizio. Design, struttura, scelte tecniche e infrastruttura devono procedere insieme. Quando questo accade, il risultato non è solo un sito più veloce — è un sito più credibile, più efficace e più vicino agli obiettivi di chi lo commissiona.
