Come velocizzare WordPress nel 2027: tema nativo, Claude e niente page builder

Per velocizzare WordPress nel 2027 non serve cercare il plugin giusto. Serve capire cosa rallenta il sito, sistemare le poche cose che pesano davvero e, quando si parte da zero, costruirlo leggero fin dall’inizio. Un sito lento perde contatti su telefono, fatica a farsi leggere da Google e può essere saltato dai crawler degli assistenti AI.

In questa guida trovi i dati di oggi sulla velocità dei siti WordPress, le tre misure di Google, il rapporto tra velocità e AI, le best practice in ordine di importanza e il metodo con cui facciamo noi un sito WordPress veloce: tema nativo a blocchi, scritto con Claude, senza page builder. I dati sono aggiornati a novembre 2026.

In breve: come velocizzare WordPress

• Il problema di solito non è WordPress in sé, ma quello che gli si aggiunge sopra: hosting lento, immagini pesanti, troppi plugin e page builder.
• Nell’agosto 2026 il 48,7% dei siti WordPress superava su mobile le tre misure di Google (Core Web Vitals). Lo stesso giorno Shopify arrivava al 76,5% e Wix all’81,2%.
• L’ordine giusto: prima server e cache, poi immagini, font, script e plugin.
• La velocità conta anche per le AI: secondo Backlinko un crawler può rinunciare a un sito lento o che mostra il testo solo dopo JavaScript.
• Il modo più sicuro per avere un sito veloce oggi è costruirlo con un tema nativo leggero, scritto da Claude dal design approvato e controllato da una persona.
• Non promettiamo un punteggio: si misura prima e dopo e si racconta la differenza.

La velocità dei siti WordPress oggi: i dati

I Core Web Vitals sono le tre misure con cui Google valuta l’esperienza di chi visita un sito, e le spieghiamo nel prossimo capitolo. I dati reali di agosto 2026 mostrano dove sta WordPress.

Va letto con cautela: nel campione Duda conta 45.113 siti contro 2.752.367 di WordPress, e sono siti di tipo diverso (jkdevstudio). Il dato però è chiaro: WordPress, che lascia più libertà e quindi più modi di appesantirsi, resta sotto le piattaforme in cui l’infrastruttura è gestita per te.

Dentro WordPress la distanza passa dal modo in cui è costruito il sito. Sempre su mobile, ad agosto 2026 superavano le tre soglie il 53,1% dei siti con l’editor a blocchi e il 36,8% di quelli con Elementor, il 38,6% con WPBakery e il 41,7% con Divi. Ne parliamo in un altro articolo, su come togliere Elementor, Divi o WPBakery senza rompere il sito.

Dove perde WordPress. Secondo il consulente Arjen Karel, che analizza i dati di HTTP Archive, il problema non è la risposta ai tocchi ma il caricamento, e in particolare il tempo di risposta del server: solo il 32% dei siti WordPress aveva un buon TTFB nei dati di fine 2025 (il tempo che passa prima che il server cominci a rispondere). È un problema di hosting, non di piattaforma (Core Web Vitals for WordPress).

Per darti un ordine di grandezza, e non una media: sui siti WordPress che monitora, la mediana del caricamento del contenuto principale su mobile prima delle ottimizzazioni sta tra 3,5 e 4,5 secondi e dopo scende a 1,6-2,1 secondi. La modifica con più effetto è quasi sempre passare da un hosting condiviso senza cache a un hosting gestito con cache sul server (Core Web Vitals for WordPress). Sono dati di un consulente sui propri clienti: li citiamo per il confronto, non come promessa.

Core Web Vitals: le tre misure di velocità di Google

Google guarda tre cose, misurate sulle visite reali e non su una prova di laboratorio.

Soglie e cause: Core Web Vitals for WordPress.

Tre cose da tenere a mente:

• Un sito “supera” le misure quando per tre quarti delle visite sono buone tutte e tre insieme. Si misura sull’intero sito, non su una pagina (jkdevstudio).
• Il punteggio di Lighthouse non è il risultato. Lighthouse simula una visita su una connessione lenta. Search Console usa i dati reali di Chrome su circa 28 giorni, ed è possibile avere 95 in laboratorio e non superare le misure sul campo, o il contrario (Core Web Vitals for WordPress).
• L’LCP, sulla maggior parte delle pagine, è l’immagine in alto. Una foto della fotocamera caricata senza ridimensionarla è la causa più frequente di LCP fuori soglia.

Velocità e AI: perché un sito WordPress veloce conta anche per i crawler

Quando una persona chiede un consiglio a un assistente AI, l’assistente fa tre cose: interpreta la domanda, cerca pagine sul web in quel momento e poi sintetizza una risposta con le fonti che ritiene migliori (Backlinko). Il passaggio di mezzo, la ricerca, avviene attraverso crawler che leggono il tuo sito come un visitatore molto frettoloso.

Secondo Backlinko, questo ha quattro conseguenze pratiche per un sito WordPress:

• Un server lento può far perdere la pagina. Se la risposta tarda, il crawler può passare oltre prima di vedere il contenuto.
• Il contenuto deve stare nell’HTML. Secondo la stessa fonte i crawler delle AI non eseguono JavaScript: se il testo compare solo dopo uno script, per loro non c’è.
• Popup e contenuti nascosti dietro un clic possono far leggere al crawler il testo del popup invece di quello dell’articolo.
• Il file robots.txt e il firewall non devono bloccare i crawler AI. Alcuni servizi di sicurezza li bloccano per impostazione predefinita.

Questi punti vengono da un solo articolo: sono ragionevoli e li applichiamo, ma non abbiamo trovato una fonte primaria che li misuri. Da nessuna fonte che abbiamo letto risulta poi che la velocità da sola faccia citare un sito: è una condizione, non una garanzia. La stessa Google, ricorda Backlinko, dice che una buona SEO è anche una buona ottimizzazione per l’AI.

In pratica, per ogni sito che costruiamo il piano per le AI, cioè la GEO, comprende:

• i crawler delle AI ammessi in robots.txt e nel firewall;
• dati strutturati e domande frequenti nelle pagine;
• entità e recensioni;
• un file llms.txt;
• contenuto principale nell’HTML, senza popup a pagina intera, e un server che risponde in fretta.

L’ultima riga è anche una regola della velocità: per questo le due cose vanno insieme.

Perché un sito WordPress è lento: le cause più comuni

Il nucleo di WordPress è leggero. Il peso arriva da quello che ci si costruisce sopra (Core Web Vitals for WordPress). Queste sono le cause principali.

Il primo passo è sempre scoprire quale causa riguarda il tuo sito: apri PageSpeed Insights, guarda nella parte diagnostica quale è l’elemento che determina l’LCP e cosa blocca la comparsa della pagina. Intervenire su tutto insieme, senza sapere dov’è il problema, è il modo più comune di perdere tempo.

Come velocizzare WordPress: le best practice in ordine

L’ordine conta: i primi passi valgono più degli ultimi. Se parti dagli ultimi, ottimizzi attorno a un server che resta lento.

1. Misura prima di toccare

PageSpeed Insights su tre pagine tipiche (home, un servizio, un articolo), mobile e desktop. Salva LCP, INP, CLS e peso della pagina. Poi guarda i dati reali in Search Console.

2. Server e cache

• Hosting gestito per WordPress con cache sul server e una versione recente di PHP. Un TTFB sopra i 400 millisecondi non si recupera con ottimizzazioni del sito.
• Cache di pagina, sul server o con un plugin. Uno solo: più plugin di cache insieme creano conflitti e possono peggiorare le cose.
• CDN per servire le pagine da un punto vicino a chi visita.
• Caricamento anticipato delle pagine (speculative loading). Dalla 6.8 WordPress lo attiva da solo con una impostazione prudente, tranne per chi è collegato o se i link permanenti non sono “belli” (WordPress). Le prove sulla funzione parlano di un miglioramento mediano di circa l’1,9% nella quota di siti che superano l’LCP (Themeisle): non è un miracolo, ma costa zero.

3. Immagini

• Formato WebP o AVIF e dimensioni giuste: non una foto da 3000 pixel dove ne servono 800.
• L’immagine in alto non va caricata in differita, e deve avere priorità alta. WordPress aggiunge il caricamento differito a tutte le immagini: se la tua immagine principale è l’elemento dell’LCP, escludila e controlla che il tema non la sposti.
• Larghezza e altezza scritte su ogni immagine, per non far spostare il layout.
• Immagini responsive con le varie dimensioni.

4. Font

Font sul tuo server e non da Google, con font-display: swap o optional e al massimo due famiglie. Meno richieste esterne e meno spostamenti del testo.

5. JavaScript, CSS e plugin

• Togli i plugin che non usi e carica gli altri solo nelle pagine dove servono. Su alcuni siti togliere gli script inutili ha ridotto il JavaScript di oltre il 40% (Core Web Vitals for WordPress).
• Rimanda gli script non essenziali e ritarda quelli di terze parti (analytics, pixel, chat) fino al primo tocco o scorrimento.
• Se hai un negozio, i file di WooCommerce non devono caricarsi sulle pagine senza prodotti.

6. Il tema e il modo in cui costruisci le pagine

Secondo Karel è la decisione di architettura che pesa di più, e non si cambia a posteriori senza rifare le pagine: un tema leggero a blocchi, senza page builder. Lo trovi nel prossimo capitolo.

7. Controlla dopo ogni modifica

Un aggiornamento di tema o plugin può far tornare indietro i risultati senza che nessuno se ne accorga. Rimisura dopo ogni cambiamento importante.

Come fare un sito WordPress veloce oggi: tema nativo e Claude, senza builder

Il modo più sicuro per avere un sito veloce è non appesantirlo all’inizio. Per questo da noi un sito nuovo parte da un tema nativo a blocchi, leggero, e non da un page builder.

Perché un tema nativo

Un sito costruito con l’editor a blocchi e un tema leggero produce pochissimo codice: secondo Karel, tra 200 e 500 elementi per pagina contro gli 800-2.000 e oltre di Elementor. Sui siti WordPress che monitora, quelli con l’editor a blocchi e un tema leggero hanno una mediana di LCP su mobile sotto i 2 secondi, mentre quelli con Elementor prima di ottimizzare stanno tra 3,8 e 5,2 secondi (Core Web Vitals for WordPress). Sono dati di un consulente sui propri clienti, ma vanno nella stessa direzione dei dati di HTTP Archive che abbiamo visto prima.

Il nostro metodo

1. Prima l’albero del sito e il layout, con una bozza HTML approvata per ogni tipo di pagina.
2. Un tema leggero scritto da Claude dalle bozze approvate: la grafica nel tema, i testi in blocchi con campi personalizzati, i box che si ripetono riusati identici. Il codice sta in Git.
3. Prova su una copia del sito, chiusa a Google, con la velocità misurata prima e dopo.
4. Cache sul server, immagini in WebP e font locali, poi title, meta description, sitemap e dati strutturati.
5. Prova sul telefono, su più browser, e solo poi la messa online.

Il percorso completo è nell’articolo sul nostro metodo per fare un sito WordPress con Claude.

Le regole da dare a Claude perché il sito resti veloce

Scrivi il tema WordPress a blocchi seguendo queste regole:
- La grafica e i colori stanno in theme.json e nel CSS del tema, senza duplicare quello che theme.json gestisce già.
- Nessun blocco HTML grezzo nei template, nelle parti e nei pattern: solo blocchi veri.
- Font locali, al massimo due famiglie, con font-display swap.
- Nessuna libreria JavaScript se non serve. Script e stili caricati solo nelle pagine che li usano.
- Ogni immagine con larghezza e altezza. L'immagine in alto con priorità alta e senza caricamento differito.
- Alla fine cerca "wp:html" nei file del tema, i font caricati da fuori e gli script caricati su tutte le pagine, e dimmi dove sono.

Il controllo su “wp:html” viene dal racconto di Bossenger: in prima battuta Claude può avvolgere intere sezioni in blocchi HTML grezzi, e il sito sembra a posto ma non si modifica più dall’editor. Nello stesso racconto, togliere dal CSS ciò che theme.json gestiva già ha ridotto il CSS di circa un terzo.

Cosa fa Claude e cosa no

Un esempio dal racconto di Bossenger: la barra dell’amministrazione copriva l’intestazione fissa, e Claude quella barra non la vede mai. Per lo stesso motivo la prova finale tocca a una persona.

Cinque errori da evitare quando velocizzi WordPress

1. Ottimizzare un sito su un hosting lento. Con il server che risponde in più di 400 millisecondi, nessun lavoro sul sito porta l’LCP nella soglia buona. Si comincia dall’hosting.
2. Impilare plugin di cache e ottimizzazione. Più plugin che fanno la stessa cosa creano conflitti e possono peggiorare le prestazioni. Ne basta uno, configurato bene (Core Web Vitals for WordPress).
3. Caricare in differita l’immagine in alto. WordPress lo fa di norma per le immagini: se quella immagine è l’elemento dell’LCP, il caricamento in differita la ritarda. Va esclusa e va resa prioritaria.
4. Fidarsi del punteggio di laboratorio. Un 95 su Lighthouse non significa superare i Core Web Vitals: Google usa i dati di chi visita davvero il sito.
5. Fidarsi del codice scritto da Claude senza provarlo, e non rimisurare dopo gli aggiornamenti. Il tema va aperto collegati all’amministrazione, su telefono e a larghezze diverse. E dopo ogni aggiornamento di tema o plugin si rimisura, perché un aggiornamento può far tornare indietro i risultati.

Come misurare la velocità di WordPress e mantenerla nel tempo

WordPress non ha un rapporto sui Core Web Vitals integrato: servono strumenti esterni (Core Web Vitals for WordPress).

Se vuoi un confronto semplice, tieni una scheda come questa e riempila prima e dopo ogni intervento:

Per mantenerla veloce

• Rimisura dopo ogni aggiornamento importante del tema o dei plugin.
• Controlla le immagini nuove: ridimensionate e compresse prima di caricarle.
• Ogni nuovo script di terze parti (chat, pixel, widget) si aggiunge solo dopo aver visto cosa costa in velocità.
• Una volta ogni tre mesi, guarda il rapporto di Search Console e le tre pagine della scheda.

I dati reali si aggiornano su una finestra di circa 28 giorni: dopo un intervento, per vedere l’effetto sul sito vero ci vuole circa un mese. Per questo si promette un miglioramento misurato, con i numeri prima e dopo, e non un punteggio.

Domande frequenti su come velocizzare WordPress

Come si velocizza WordPress? Si parte dalla misura, poi si sistema il server con una cache, quindi immagini, font, script e plugin. Se il sito è nuovo, si costruisce con un tema leggero a blocchi e senza page builder.

Qual è il miglior plugin per velocizzare WordPress? Non esiste il plugin che sistema tutto. Se ne usa uno solo di cache e ottimizzazione: Core Web Vitals for WordPress cita WP Rocket, LiteSpeed Cache (gratuito, se il server è LiteSpeed) e FlyingPress. Impilarne più di uno crea conflitti.

Quanto deve essere veloce un sito per Google? Le soglie “buone” dei Core Web Vitals sono: LCP sotto 2,5 secondi, INP sotto 200 millisecondi, CLS sotto 0,1. Si valutano su dati reali, su circa 28 giorni.

Meglio l’editor a blocchi o un page builder per la velocità? I dati reali di agosto 2026 danno l’editor a blocchi al 53,1% dei siti che superano i Core Web Vitals su mobile, contro il 36,8% di Elementor, il 38,6% di WPBakery e il 41,7% di Divi. Dipende dal sito, ma la direzione è chiara.

Claude può velocizzare il mio sito WordPress? Può leggere il codice e il report di PageSpeed, indicare le cause probabili, scrivere correzioni e un tema leggero. Non vede il sito come lo vedi tu da amministratore e non misura i dati reali: la prova la fa una persona, su una copia del sito.

Quanti plugin sono troppi? Non c’è un numero. Cinquanta plugin leggeri possono andare meglio di cinque pesanti: conta quanto JavaScript e CSS aggiungono e se si caricano su ogni pagina o solo dove servono.

Il tuo prossimo passo

Non provare a ottimizzare tutto in un giorno. Parti da tre azioni.

1. Oggi: misura tre pagine tipiche con PageSpeed Insights, mobile e desktop, e salva LCP, INP, CLS e peso della pagina.
2. Questa settimana: guarda quanto tarda il server a rispondere (TTFB) e quale elemento determina l’LCP. Se il server tarda più di 400 millisecondi, parti dall’hosting.
3. Entro il mese: decidi se il tuo sito conviene ottimizzarlo così com’è o rifarlo con un tema nativo, senza page builder.

Se vuoi capire cosa conviene nel tuo caso, ne parliamo in una consulenza: partiamo dai numeri di velocità e dalle pagine che portano contatti. Qui trovi come lavoriamo ai siti web e alle landing page, alla SEO e GEO e all’AI per aziende.