Come velocizzare WordPress: la guida pratica

Un sito lento costa più di quanto sembri: le persone abbandonano la pagina prima di vedere l’offerta, i moduli di contatto restano vuoti e Google registra un’esperienza scadente. Per velocizzare WordPress quasi mai serve rifare tutto: serve capire dove si perde tempo e intervenire lì, invece di installare l’ennesimo plugin “miracoloso”. Il metodo che segue è quello che usiamo nella pratica, dalla misurazione alla CDN, e per ogni passo indica cosa puoi fare da solo e quando conviene farsi aiutare.

Perché un sito WordPress diventa lento?

Un sito WordPress è lento quasi sempre per una combinazione di tre fattori: il server impiega troppo a generare la pagina, la pagina pesa troppo da scaricare, oppure il browser deve eseguire troppo codice prima di mostrarla e renderla usabile. Capire quale dei tre prevale è il primo passo.

Per ogni visita non in cache WordPress esegue PHP, interroga il database e compone l’HTML: se l’hosting è debole o un plugin fa query pesanti, il ritardo nasce sul server. Poi il browser scarica stili, script, font e immagini: un banner da 3 MB rallenta il trasferimento. Infine deve eseguire JavaScript: chat, pixel, slider e page builder possono renderlo lento a rispondere ai clic. Con gli anni, senza manutenzione periodica, plugin dimenticati e dati orfani peggiorano la situazione.

Come si misura davvero la velocità?

Si misura con PageSpeed Insights di Google, guardando prima i dati di campo (le visite reali degli utenti Chrome) e solo dopo il punteggio di laboratorio, che serve a trovare le cause. I due numeri rispondono a domande diverse e spesso non coincidono.

Come spiega la documentazione ufficiale di PageSpeed Insights, i dati di campo provengono dal Chrome User Experience Report (CrUX) e riassumono le visite reali degli ultimi 28 giorni. I dati di laboratorio, invece, sono una simulazione di Lighthouse su un singolo dispositivo con una connessione prefissata. Il laboratorio è ottimo per il debug, perché è ripetibile; il campo dice come va davvero per le persone che visitano il sito.

I dati di campo sono organizzati attorno ai Core Web Vitals: LCP (quanto ci mette a comparire il contenuto principale), INP (quanto è reattiva la pagina ai clic) e CLS (quanto “salta” il layout). La valutazione è superata se il 75° percentile delle visite rientra nella fascia buona per tutte e tre le metriche. Le soglie e il modo di correggerle su WordPress sono spiegati nella guida ai Core Web Vitals su WordPress: LCP, INP e CLS.

Testa sempre la versione mobile, analizza più tipi di pagina (non solo la home), ripeti il test di laboratorio un paio di volte e annota i valori prima di ogni modifica.

Quanto conta l’hosting?

Conta moltissimo, perché nessuna ottimizzazione compensa un server lento: se il tempo di risposta del server (TTFB) è alto, tutto il resto parte in ritardo. Un hosting adeguato, con una versione di PHP aggiornata e risorse sufficienti, è la base su cui funzionano tutti gli altri interventi.

WordPress.org, nella pagina dei requisiti consigliati, raccomanda PHP 8.3 o superiore, MySQL 8.0 o MariaDB 10.11 o superiori e il supporto HTTPS. Versioni di PHP più recenti sono in genere anche più veloci, oltre che supportate con aggiornamenti di sicurezza. Se il tuo sito gira ancora su PHP 7.x, leggi prima come aggiornare PHP su WordPress in sicurezza.

Segnali che l’hosting è il collo di bottiglia: TTFB stabilmente sopra il secondo anche con la cache, pannello di amministrazione lento, errori nei momenti di traffico alto, nessuna scelta sulla versione di PHP. In questi casi valuta un piano superiore o un fornitore diverso. Le differenze tra le due grandi famiglie di offerte sono spiegate in hosting condiviso o gestito per WordPress, mentre per il trasloco vero e proprio trovi la procedura in cambiare hosting WordPress senza perdere email e posizionamento.

Cos’è la cache di pagina e perché è il primo intervento?

La cache di pagina salva l’HTML già generato e lo serve direttamente ai visitatori successivi, evitando che WordPress rielabori PHP e database a ogni visita. È di solito l’intervento con il miglior rapporto tra sforzo e risultato.

Esistono diversi livelli di cache, e conviene conoscerli per non sovrapporli:

• Cache di pagina: salva la pagina completa. Può essere fatta dal server (molti hosting la offrono già) o da un plugin.
• Object cache: conserva in memoria (per esempio con Redis o Memcached) i risultati delle query più frequenti. È utile soprattutto per siti dinamici, aree riservate ed e-commerce.
• Cache del browser: indica al browser di conservare file statici come CSS, JavaScript e immagini, così le visite successive sono più rapide.

Due regole pratiche: usa un solo sistema di cache di pagina, perché un plugin sopra una cache server già attiva crea conflitti; e in un negozio escludi dalla cache carrello, checkout e “il mio account”.

Opzioni come minificazione e rinvio degli script sono utili ma delicate: attivale una alla volta e controlla menu, moduli e slider.

Come ottimizzare le immagini?

Le immagini vanno caricate già alle dimensioni in cui vengono mostrate, in un formato moderno come WebP o AVIF e con il caricamento differito (lazy load) solo per quelle fuori dalla prima schermata. Nella maggior parte dei siti aziendali sono la parte più pesante della pagina.

Dimensioni e peso

Una foto dello smartphone può superare i 4000 pixel e diversi megabyte: se viene mostrata a 1200 pixel, il resto è peso inutile. Ridimensiona prima di caricare o usa un plugin di ottimizzazione. WordPress genera più dimensioni di ogni immagine e le offre al browser con l’attributo srcset, se il tema usa le funzioni standard.

Formati WebP e AVIF

WebP e AVIF comprimono molto meglio del JPEG a parità di qualità visiva. WordPress supporta il caricamento di WebP da tempo e, dalla versione 6.5, anche di AVIF, se la libreria di immagini del server lo consente, come annunciato su make.wordpress.org. In alternativa, molti plugin convertono automaticamente le immagini esistenti.

Lazy load, ma non ovunque

Il lazy load rimanda il download delle immagini finché non stanno per entrare nello schermo. WordPress lo applica già in automatico con l’attributo loading="lazy". Attenzione però all’immagine principale in alto (la foto di copertina o il banner): se viene caricata in modo differito, il contenuto principale compare più tardi e peggiora l’LCP. Quell’immagine va caricata subito, idealmente con priorità alta (fetchpriority="high"). Evita di aggiungere un plugin di lazy load se WordPress, il tema o il page builder lo fanno già: due sistemi sovrapposti creano solo problemi.

Dimensioni dichiarate

Ogni immagine dovrebbe avere width e height nel codice, così il browser riserva lo spazio prima che arrivi e il layout non salta. È una delle cause più comuni di CLS alto.

I plugin rallentano WordPress?

Non conta tanto il numero dei plugin quanto cosa fanno: un solo plugin scritto male o che carica i suoi file su tutte le pagine può rallentare più di venti plugin leggeri. L’obiettivo è tenere solo ciò che serve e sapere quanto pesa ciascuno.

I sospetti abituali sono slider, gallerie, plugin social, statistiche interne che scrivono nel database a ogni visita e page builder. Per trovarli, disattiva un plugin alla volta su una copia di staging misurando la differenza, oppure usa un plugin diagnostico come Query Monitor per vedere query lente e file caricati. Anche il tema conta: temi “tutto in uno” e layout con molti livelli annidati generano HTML e CSS voluminosi. Se il tuo sito è costruito con Elementor, trovi le impostazioni di performance e le tecniche per alleggerirlo in sito fatto con Elementor lento? Come alleggerirlo senza rifarlo.

Rimuovere plugin su un sito in produzione senza backup è una delle cause più frequenti di guasti, quindi fai sempre un backup completo prima di intervenire.

I font possono rallentare il sito?

Sì: ogni famiglia e ogni peso di carattere è un file da scaricare, e se i font arrivano da un server esterno aggiungono connessioni e ritardi. Conviene usare pochi pesi, il formato WOFF2 e caricare i file dal proprio dominio.

• Riduci le varianti. Spesso bastano regular e bold di una o due famiglie. Ogni corsivo o peso in più è un altro file.
• Ospita i font sul tuo server: caricarli localmente evita la connessione a un dominio esterno e semplifica anche la gestione della privacy, perché non trasmetti l’indirizzo IP dei visitatori a terzi.
• Usa font-display: swap, così il testo compare subito con un font di sistema e viene sostituito quando il font personalizzato è pronto, invece di restare invisibile.
• Precarica solo il font usato nel titolo principale. Precaricare tutto annulla il vantaggio.

Quanto pesano gli script di terze parti?

Spesso più di tutto il resto: chat, pixel pubblicitari, mappe, video incorporati, widget di recensioni e banner cookie caricano codice da altri domini che non controlli e che può bloccare la pagina. Ogni script esterno va giustificato da un beneficio concreto.

Questi script incidono soprattutto sulla reattività (INP), perché eseguono JavaScript sul thread principale del browser proprio mentre l’utente prova a interagire. Cosa puoi fare:

• Fai un inventario dei domini esterni (li vedi nel report di PageSpeed Insights): pixel di campagne finite da anni sono frequentissimi.
• Carica gli script solo quando servono: mappe e video possono mostrare un’anteprima e caricarsi al clic; la chat può attivarsi dopo qualche secondo.
• Controlla Google Tag Manager, che tende a riempirsi di tag dimenticati.
• Rispetta il consenso cookie: gli script di profilazione non devono partire prima, e la prima visita ne guadagna anche in velocità.

Serve pulire il database?

Sì, periodicamente: revisioni accumulate, transient scaduti, dati lasciati da plugin disinstallati e opzioni caricate automaticamente a ogni richiesta rallentano soprattutto il pannello di amministrazione e le pagine non in cache. È un intervento utile ma da fare con un backup del database appena eseguito.

Se hai accesso a WP-CLI (lo strumento a riga di comando di WordPress), questi comandi ti danno un’idea della situazione e fanno una prima pulizia sicura:

# 1. Backup del database prima di tutto
wp db export backup-prima-pulizia.sql

# 2. Quante revisioni ci sono?
wp post list --post_type=revision --format=count

# 3. Peso totale (in byte) delle opzioni caricate automaticamente
wp option list --autoload=on --format=total_bytes

# 4. Elimina i transient scaduti
wp transient delete --expired

Per limitare le revisioni future puoi aggiungere nel file wp-config.php, prima della riga che dice di interrompere le modifiche, questa costante:

define( 'WP_POST_REVISIONS', 10 );

Se le opzioni caricate automaticamente pesano diversi megabyte, di solito c’è un plugin (attivo o rimosso) che le riempie: va individuato con cura, non cancellando righe a caso. Per i negozi online vedi WooCommerce lento: come ottimizzare il database.

Serve una CDN?

Una CDN (Content Delivery Network, rete di server distribuiti) serve soprattutto se hai visitatori lontani dal tuo server o molto traffico, perché consegna file statici e, in alcune configurazioni, pagine intere da un nodo vicino all’utente. Per un sito con pubblico italiano e hosting in Italia o in Europa il beneficio è spesso minore di quanto si pensi.

Ha senso se vendi all’estero, se hai picchi di traffico che mettono in difficoltà il server o se vuoi anche il firewall e la mitigazione degli attacchi che molte CDN offrono. Non corregge però immagini pesanti o script lenti: attivala dopo aver sistemato il resto, verificando che non entri in conflitto con la cache già presente.

In che ordine conviene intervenire?

Conviene partire da misurazione e backup, poi affrontare prima gli interventi a basso rischio e alto impatto (cache e immagini) e solo dopo quelli più invasivi (plugin, tema, hosting). Fai un intervento alla volta e misura dopo ognuno.

1. Misura le pagine principali su mobile e annota i valori.
2. Fai un backup completo e, se possibile, lavora in staging.
3. Controlla hosting e PHP.
4. Attiva una cache di pagina ed escludi le pagine dinamiche.
5. Ottimizza le immagini.
6. Rivedi plugin e tema.
7. Sistema font e script esterni.
8. Pulisci il database.
9. Valuta una CDN.
10. Rimisura subito in laboratorio e, dopo alcune settimane, sui dati di campo.

Quando i dati indicano problemi nel tema, nel page builder o nel server, o quando le modifiche iniziano a rompere funzioni, è il momento di coinvolgere un tecnico. Il nostro servizio di ottimizzazione della velocità WordPress segue esattamente questo metodo, con misure prima e dopo. E la velocità, una volta ottenuta, va mantenuta: è parte della normale manutenzione di un sito WordPress.

Domande frequenti

Quanto tempo serve per velocizzare un sito WordPress?

Dipende da dove sta il problema. Cache e immagini si sistemano spesso in poche ore, mentre un cambio di hosting o la revisione di un tema pesante richiedono giorni. I dati di campo di Google, poi, si aggiornano su una finestra di 28 giorni, quindi i miglioramenti si vedono nei report con un po’ di ritardo.

Basta un plugin di cache per rendere veloce WordPress?

Aiuta molto, ma non basta se il server è lento, le immagini pesano diversi megabyte o la pagina carica decine di script esterni. La cache riduce il lavoro del server, non il peso di quello che il browser deve scaricare ed eseguire.

Devo raggiungere 100 su PageSpeed Insights?

No. Il punteggio è un indicatore di laboratorio utile per trovare i problemi, ma conta di più superare le soglie dei Core Web Vitals sui dati reali degli utenti. Un sito a 85 che supera i Core Web Vitals è in una situazione migliore di uno a 98 in laboratorio che li fallisce sul campo.

Velocizzare il sito migliora il posizionamento su Google?

La velocità e i Core Web Vitals fanno parte dei segnali di esperienza della pagina, ma pesano meno della pertinenza dei contenuti. L’effetto più concreto di un sito veloce è su chi lo visita: meno abbandoni, più pagine viste e più contatti o vendite.