Il sito ci mette quattro o cinque secondi ad aprirsi, qualcuno ti ha detto che sono le immagini, e la prima cosa che hai fatto è installare un plugin di cache. Se dopo l’installazione è cambiato poco, o peggio si è rotto qualcosa nel layout, non è sfortuna. È che manca il passaggio precedente: capire quale delle possibili cause sta rallentando quel sito specifico.
Un sito WordPress lento raramente ha una sola spiegazione. Ha quasi sempre una causa dominante, che nella maggior parte dei casi pesa più di tutte le altre messe insieme. Trovare quella causa richiede mezz’ora di misurazioni ordinate e fa risparmiare settimane di tentativi.
In breve
Le cause più frequenti di un sito WordPress lento sono, in quest’ordine: hosting condiviso sotto sforzo, plugin che caricano script su tutte le pagine, immagini non ridimensionate, page builder appesantito, PHP superato, script di terze parti e database gonfio. Prima di intervenire va misurato il tempo di risposta del server: se è alto, tutto il resto passa in secondo piano.
“Lento” secondo chi?
Prima di toccare qualsiasi impostazione serve chiarire un punto che manda fuori strada quasi tutti: esistono due tipi di misurazione della velocità, e non dicono la stessa cosa.
I dati di laboratorio sono le simulazioni. Il punteggio colorato di PageSpeed Insights, i test di GTmetrix, Lighthouse dentro Chrome. Servono per fare diagnosi perché isolano le variabili, ma restano simulazioni: stesso dispositivo virtuale, stessa connessione, condizioni ripetibili. Per questo il punteggio cambia se lanci il test tre volte di fila.
I dati di campo sono le prestazioni misurate sui visitatori veri, raccolte dal Chrome User Experience Report su una finestra mobile di ventotto giorni. Sono i dati su cui si basa la valutazione dell’esperienza sulla pagina, e li trovi nel rapporto Segnali web essenziali di Search Console.
La differenza è concreta. Un sito può avere 95 su 100 nel test di laboratorio e comportarsi male con gli utenti reali, perché il pubblico vero naviga da smartphone di fascia media su rete mobile, non dalla fibra dello sviluppatore. Vale anche il contrario: un punteggio arancione non significa automaticamente che i tuoi visitatori stiano soffrendo.
Se il tuo obiettivo è il posizionamento, il numero che conta è quello dei dati di campo. Il punteggio di laboratorio è uno strumento di lavoro, non il voto finale.
Come fare un test di velocità che serva a qualcosa
Un test della velocità del sito web è utile solo se ripetuto nelle stesse condizioni. Tre accortezze cambiano completamente l’affidabilità del risultato.
- Testa sempre la stessa pagina. Home e pagina di servizio hanno pesi diversi: confrontarle non dice nulla.
- Guarda la vista mobile, non desktop. È quella su cui Google valuta la maggior parte dei siti e quella dove i problemi emergono.
- Lancia il test tre volte e prendi il valore intermedio. Il primo caricamento dopo una modifica trova sempre la cache vuota.
Il risultato ti restituisce tre metriche, i Core Web Vitals. Ognuna misura una cosa diversa e si rompe per motivi diversi: sapere quale delle tre è in rosso restringe da subito il campo delle cause possibili.
| Metrica | Cosa misura | Soglia “buona” | Se è in rosso guarda |
|---|---|---|---|
| LCP Largest Contentful Paint | Quanto ci mette a comparire l’elemento principale della pagina | sotto 2,5 secondi | Hosting, immagini, tempo di risposta del server |
| INP Interaction to Next Paint | Quanto tempo passa tra un clic dell’utente e la risposta visibile | sotto 200 millisecondi | JavaScript, plugin, script di terze parti |
| CLS Cumulative Layout Shift | Quanto il contenuto si sposta mentre la pagina carica | sotto 0,1 | Immagini senza dimensioni, banner, font, pubblicità |
Una precisazione che cambia le priorità: la soglia va superata dal 75% delle visite reali, non dalla media. Se un quarto dei tuoi utenti ha un’esperienza pessima, la pagina non passa, anche se la media sembra accettabile.
INP ha sostituito la vecchia metrica FID nel marzo 2024. Se stai leggendo una guida che parla ancora di First Input Delay, è datata: diffida anche del resto dei consigli.
Le sette cause, in ordine di frequenza reale
Questo è l’ordine in cui conviene sospettarle sui siti WordPress di piccole e medie attività italiane. È una probabilità di partenza, non una classifica valida per ogni sito: serve a decidere da dove iniziare a guardare, prima di passare alla verifica vera e propria.
1. L’hosting condiviso sotto sforzo
È tra le cause più frequenti ed è quasi sempre la meno considerata, perché è invisibile dal pannello di WordPress. Su un piano condiviso economico il tuo sito divide CPU e memoria con centinaia di altri: quando i vicini consumano, tu rallenti, e non c’è plugin che compensi.
Il sintomo tipico è un LCP alto su un sito che di suo è leggero. Il segnale da guardare è il TTFB, il tempo che passa prima che il server risponda al primo byte: se supera stabilmente i 600-800 millisecondi anche su una pagina semplice, è un indizio forte che il collo di bottiglia sia a monte di qualsiasi ottimizzazione tu possa fare su WordPress.
Va letto con una cautela, però. Il TTFB non dipende solo dalla potenza del server: query pesanti, plugin che girano a ogni richiesta e assenza di cache lato server producono un numero alto anche su un’infrastruttura adeguata. Va incrociato con il resto prima di trarne conclusioni.
In Italia lo scenario del piano sottodimensionato si presenta spesso sui condivisi entry level, Aruba compresa, che è l’hosting più diffuso tra le piccole attività. È una questione di dimensionamento: quei piani nascono per siti vetrina con poche pagine, e un WooCommerce con quaranta plugin sopra ci sta stretto per costruzione. Se il tuo sito WordPress è lento su Aruba e il TTFB resta alto anche a parità di tutto il resto, la strada non è aggiungere un plugin: è valutare un piano superiore, un hosting gestito o un’infrastruttura diversa.
2. Plugin che caricano su tutte le pagine
Il numero di plugin conta meno di quanto si dica. Contano molto di più quelli scritti male, che iniettano CSS e JavaScript su ogni pagina anche dove non servono: il plugin dei moduli di contatto che carica i suoi script anche in home, lo slider presente solo nella pagina iniziale che appesantisce tutto il sito, il plugin di recensioni attivo su ogni articolo del blog.
Non conta quanti plugin hai. Conta cosa caricano, e dove.
Il sintomo è INP alto, oppure un sito che sembra caricare in fretta ma non risponde subito ai clic.
3. Immagini caricate a dimensione originale
La causa più conosciuta, e per questo spesso già risolta a metà. Il problema tipico non è la mancanza di compressione: è il file da 4000 pixel di larghezza caricato dentro uno spazio che ne mostra 800.
L’altro punto è il formato. Il WebP pesa mediamente molto meno di un JPEG o di un PNG di pari qualità visiva ed è supportato da tutti i browser attuali: convertire la libreria media è uno degli interventi con il rapporto sforzo-risultato più favorevole.
Il sintomo è LCP alto quando l’elemento più grande della pagina è un’immagine. PageSpeed Insights te lo dice esplicitamente, indicandoti anche quale file.
4. Il page builder e il peso della struttura
Elementor, Divi e simili aggiungono livelli di codice per ogni sezione, colonna e contenitore. Una pagina costruita a strati, con dieci contenitori annidati dove ne bastavano tre, genera una struttura che il browser deve interpretare tutta prima di mostrare qualcosa.
Il builder non va abbandonato per questo. Va usato in modo più asciutto: disattiva i widget che non usi e togli di mezzo le librerie caricate per un effetto presente su una sola pagina.
5. Una versione di PHP superata
PHP è il motore che esegue WordPress e ogni versione recente è più veloce della precedente. Molti siti girano ancora su versioni vecchie di anni, semplicemente perché nessuno ha mai aperto quella voce nel pannello dell’hosting.
La documentazione ufficiale raccomanda PHP 8.3 o superiore. Il passaggio è gratuito e richiede un minuto, ma va fatto prima in staging: un plugin datato può smettere di funzionare e portarsi dietro il sito. Trovi la versione in uso nella schermata Salute del sito, dentro Strumenti.
6. Script di terze parti fuori controllo
Google Tag Manager, pixel pubblicitari, widget di chat, mappe incorporate, font caricati da server esterni, banner dei cookie. Preso uno alla volta pesa poco. Messi insieme sono spesso il primo responsabile di un INP disastroso, perché ognuno esegue codice che tiene occupato il browser mentre l’utente sta già cercando di cliccare.
È anche la causa più antipatica da affrontare, perché ogni script è stato aggiunto per un motivo legittimo. La domanda giusta non è “posso toglierlo”, ma “deve caricarsi su tutte le pagine, e proprio adesso”.
7. Database appesantito
Revisioni degli articoli accumulate per anni, tabelle lasciate da plugin disinstallati, transient scaduti mai puliti, log di sistema. Sui siti giovani incide poco. Su un sito che pubblica da cinque anni, o su un negozio con molti ordini, diventa una zavorra reale.
WooCommerce è un caso a parte
Se il sito lento è un e-commerce, buona parte di quanto letto finora vale ancora, ma con un’aggravante: carrello, checkout e area account non possono essere messi in cache come una pagina statica, perché il loro contenuto cambia da utente a utente.
Significa che quando installi un plugin di cache e vedi la home volare, le pagine che generano fatturato restano lente come prima. Su un WooCommerce lento gli interventi che spostano davvero l’ago sono altri: risorse del server adeguate, pulizia delle sessioni e dei transient, riduzione delle query sulle pagine di catalogo, e attenzione a quanti plugin girano nel processo di acquisto.
Plugin per velocizzare WordPress: quali servono e quando installarli
Arriviamo alla domanda che quasi tutti fanno per prima, e che invece è quella da farsi per ultima.
Un plugin di cache genera versioni statiche delle pagine ed evita a WordPress di ricostruirle a ogni visita. Fa una differenza enorme e sulla maggior parte dei siti ha senso averlo. Le opzioni più solide sono note: WP Rocket nel commerciale, LiteSpeed Cache se il tuo server lo supporta, Autoptimize e WP Super Cache tra le gratuite. Non serve provarli tutti: ne basta uno, configurato bene.
Il punto è quando. Se la cache è la prima mossa succede questo: il sito migliora quel tanto che basta a farti smettere di indagare, mentre la causa vera resta lì sotto. Le pagine non memorizzabili restano lente. E siccome la cache modifica il modo in cui i file vengono serviti, se qualcosa si rompe non riesci più a distinguere se sia colpa sua o del problema originario.
Vale anche per le funzioni aggressive che questi plugin offrono: minificazione, combinazione dei file, caricamento differito del JavaScript. Sono efficaci e sono anche il motivo per cui un sito ottimizzato male si presenta con il layout rotto o i moduli che non inviano. Vanno attivate una alla volta, verificando il sito dopo ognuna.
Diagnosi Causa dominante Ottimizzazione Cache
Il metodo di diagnosi in quattro passaggi
Sapere le cause serve poco senza un ordine di verifica. Questo è il percorso che evita di intervenire a caso.
- Parti dai dati di campo. Apri Search Console, sezione Segnali web essenziali, e guarda quale delle tre metriche è fuori soglia e su quali URL. Se il rapporto è vuoto perché il sito ha poco traffico, usa PageSpeed Insights sapendo che stai leggendo una simulazione.
- Misura il TTFB su una pagina semplice. Non la home piena di sezioni: una pagina di servizio essenziale. Se il server è lento anche lì, hai un forte indizio su dove sia il collo di bottiglia.
- Isola confrontando. Testa la stessa pagina prima e dopo aver disattivato temporaneamente i plugin sospetti, uno alla volta, possibilmente in staging. È lento come metodo, ma è l’unico che produce una risposta certa invece di un’ipotesi.
- Cambia una cosa alla volta e rimisura. Se applichi cinque ottimizzazioni insieme e il sito migliora, non saprai quale ha funzionato, e quando tra sei mesi rallenterà di nuovo ricomincerai da zero.
Un’avvertenza sui tempi: i dati di campo si aggiornano su una finestra di ventotto giorni. Dopo un intervento risolutivo, Search Console impiega settimane a mostrare il miglioramento. Non è il tuo lavoro che non funziona, è la metrica che ha bisogno di tempo.
Quando ha senso fermarsi
Buona parte di questo percorso è alla portata di chi gestisce il proprio sito con un po’ di metodo: cambiare versione di PHP, ridimensionare le immagini, disattivare i plugin che non si usano più.
Ci sono però tre situazioni in cui insistere da soli costa più di quanto faccia risparmiare. La prima è quando il TTFB resta alto anche su pagine minime, perché lì la scelta è di infrastruttura e va valutata con criterio, non cambiando hosting a intuito. La seconda è quando il sito genera fatturato: su un e-commerce ogni tentativo fatto in produzione è un rischio commerciale. La terza è quando il problema è INP causato da JavaScript, perché richiede leggere il profilo delle prestazioni nel browser e capire quale script sta bloccando il thread principale.
Vuoi sapere cosa sta rallentando davvero il tuo sito?
Una diagnosi delle prestazioni parte dalla misurazione, non dalle ipotesi: si individua la causa dominante, si quantifica quanto pesa e si stabilisce se conviene intervenire o ripensare qualcosa a monte. Prima di installare qualsiasi cosa.
Richiedi una diagnosi delle prestazioni del tuo sito WordPress
Domande frequenti
Quanti plugin sono troppi per WordPress?
Non esiste un numero limite. Venti plugin leggeri e ben scritti pesano meno di cinque plugin che caricano script su tutte le pagine. Invece di contarli, verifica quali file ciascuno aggiunge alle pagine dove non serve.
Un plugin di cache può rallentare il sito?
Indirettamente sì. Le funzioni di minificazione e combinazione dei file possono entrare in conflitto con il tema o con altri plugin, generando errori che il browser deve gestire. Conviene attivarle una alla volta verificando ogni volta il risultato.
Cambiare hosting risolve sempre?
No. Un hosting migliore risolve il problema quando il collo di bottiglia è il tempo di risposta del server. Se il sito è lento perché carica tre megabyte di immagini e dodici script di terze parti, dopo la migrazione sarà lento allo stesso modo su un server più costoso.
Quanto tempo serve per vedere i risultati su Google?
I dati che Google usa si basano su una finestra di ventotto giorni di visite reali. Anche dopo un intervento efficace, il rapporto in Search Console impiega diverse settimane ad aggiornarsi. La velocità percepita dagli utenti migliora invece da subito.
Se il quadro è più confuso di così, il passo successivo è un errore che rallenta il sito fino a bloccarlo del tutto: come capire cosa sta causando un errore 500 su WordPress.
