Sito WordPress lento: 12 cause e come velocizzarlo nel 2026

La telefonata che mi ha fatto capire quanto conta la velocità

Era un martedì mattina di febbraio. Un cliente di Bergamo, e-commerce con 40mila prodotti, mi chiama perché le vendite erano crollate del 30% in due settimane. Il sito impiegava 8,4 secondi a caricare su mobile. 8,4 secondi, con un LCP a 6,2. Google aveva già cominciato a declassarlo: Core Web Vitals bocciati su tutte e tre le metriche.

Non era un caso raro. È la ragione numero uno per cui la gente finisce a cercare assistenza WordPress: non perché il sito "non funziona", ma perché è lento e nessuno sa spiegare perché. Te lo dico subito: il 70% delle volte la colpa non è del tema e non è del plugin "sbagliato". È una combinazione di scelte fatte negli anni, una sopra l'altra.

In questo articolo ti elenco le 12 cause che trovo più spesso quando apro un sito lento, in ordine di frequenza, e come ho risolto ognuna. Con numeri veri, non con i soliti listoni da 10 punti copiati da blog americani.

Prima misura, poi tocca: il 90% degli interventi sbagliati nasce qui

La prima cosa che faccio non è disinstallare plugin. È misurare. Senza una baseline non capisci se hai risolto o se hai solo spostato il problema.

Uso tre strumenti, e solo tre:

• PageSpeed Insights di Google per LCP, INP e CLS (le metriche che contano davvero per il ranking)
• GTmetrix per il waterfall delle richieste, così vedo chi carica cosa e quando
• Query Monitor direttamente nel sito, perché un backend lento non si vede da fuori

Query Monitor è quello che ti apre gli occhi. Ricordo un sito che a PageSpeed prendeva 97: velocissimo da fuori. Poi guardo Query Monitor e scopro 148 query per pagina e un plugin che da solo ne faceva 63. Il frontend era ok, il backend era un colabrodo. Se avessi ottimizzato le immagini non avrei risolto nulla. Quando la lentezza è a livello di codice e query, ho scritto anche un workflow di debugging con AI assistita che uso nei casi più ostici.

Dal terminale poi confermo con i tool di WP-CLI:

wp db query "SELECT COUNT(*) FROM wp_options"
wp plugin list --status=inactive
wp eval 'echo wp_count_posts()->publish;'

Le 12 cause che trovo più spesso, in ordine di frequenza

1. Hosting condiviso da 3 euro al mese

È la causa più comune e la più ignorata. Un sito WordPress serio su hosting condiviso economico è come mettere un motore Formula 1 in una Panda. Il problema non è solo la CPU: è che il tuo vicino di server satura il disco o la RAM e tu paghi le conseguenze.

Il caso del cliente di Bergamo era esattamente questo: hosting da 4,90 euro al mese, TTFB medio di 1,8 secondi, picchi di 4 secondi nelle ore di punta. Il TTFB alto si vede subito nel waterfall di GTmetrix: se la prima riga parte lenta, tutto il resto è inutile.

La soluzione è un server dedicato o un buon VPS configurato bene. Se non hai mai fatto un trasferimento, è uno dei casi in cui ha senso delegare: sul mio sito trovi l'assistenza nel trasferimento di WordPress e la guida all'installazione su VPS.

2. Plugin che caricano script ovunque

Un plugin che ti serve solo nella pagina contatti non deve caricare CSS e JavaScript in tutte le 500 pagine del sito. Eppure è quello che fanno quasi tutti i plugin gratis, per pigrizia degli sviluppatori.

Controllo con Query Monitor o con la scheda Network di Chrome: se vedo slick.min.js o jquery-ui.min.js su pagine dove non servono, quello è grasso da tagliare. Nei casi gravi, ho visto siti con 14 plugin che caricavano ognuno la propria copia di jQuery.

La regola che applico: se un plugin carica più di 30KB di script su pagine dove non serve, o lo configuro per caricare solo dove serve, o lo sostituisco. Punto.

3. Immagini da 3 megabyte

Sembra banale, e invece è ancora la causa numero tre. Il fotografo consegna le foto a 6000 pixel, il cliente le carica così come sono, e WordPress le ridimensiona al volo a ogni richiesta. Risultato: 3 MB di peso per un'immagine che a schermo ne occupa 40 KB.

Nel sito del cliente bergamasco c'erano 12mila immagini in originale. Dopo la conversione in WebP e il ridimensionamento a 1920 pixel, il peso medio è passato da 1,1 MB a 84 KB. Solo questo ha portato il LCP da 6,2 a 3,1 secondi.

4. Tema con page builder e 40 stili inutilizzati

I page builder moderni caricano un CSS gigante perché devono coprire qualsiasi cosa tu possa costruire. Se poi il tema ha 30 template che non usi, paghi per tutti quanti.

Non sto dicendo di buttare il page builder: sto dicendo che va misurato. Se il CSS del builder pesa 400 KB e la tua pagina ne usa 80 KB, stai sprecando il 320 KB a ogni visita.

5. Cache disattivata o configurata male

Un sito WordPress senza cache page è come rispondere al telefono dicendo ogni volta "pronto, chi parla?" anche se sei tu. Il 40% dei siti lenti che apro ha la cache disattivata, o attiva ma con esclusioni sbagliate.

La configurazione che uso di default: cache page per gli anonimi, cache oggetti con Redis se il server lo permette, cache del DNS niente (quella la fa il provider). Se vuoi approfondire la parte AI-aware della cache, ho scritto una guida alla cache edge con Redis.

6. Database gonfio di revisioni e transients

Ogni volta che salvi un articolo, WordPress salva una revisione. Dopo tre anni di editing, il database è pieno di roba che non leggerà mai nessuno. Idem i transients: milioni di righe scadute che restano lì.

La pulizia è veloce:

wp post list --post_type=revision --format=ids | xargs -r wp post delete --force
wp transient delete --all
wp db optimize

Su un sito con 240mila righe nella tabella options, questa procedura l'ha portata a 18mila. Il backend è passato da 2,4 a 0,6 secondi a pagina admin.

7. PHP fermo a versioni vecchie

Sembra incredibile, ma nel 2026 trovo ancora siti su PHP 7.4. WordPress 6.7+ su PHP 7.4 è un freno a mano tirato: PHP 8.3 è in media il 25-30% più veloce a parità di codice, e consuma meno memoria.

Il passaggio si fa dal pannello del provider o con un comando:

wp cli update
php -v

Prima di cambiare versione, verifica che tutti i plugin siano compatibili: un plugin vecchio su PHP 8 può rompersi. Se hai un sito con plugin legacy e non sai da dove cominciare, il servizio di aggiornamento WordPress copre esattamente questo tipo di intervento.

8. Font e script esterni

Google Fonts, script di analytics, widget social: ogni dominio esterno aggiunge un handshake TLS e una richiesta. Un sito con 25 domini terzi impiega tranquillamente 1,5 secondi solo di connessioni prima di mostrare qualsiasi cosa.

La soluzione: self-hostare i font, posticipare gli script non essenziali, e usare dns-prefetch solo per i domini che servono davvero.

9. Cron che parte nei momenti peggiori

WP-Cron è un cron "pigro": parte quando arriva un visitatore. Se un plugin programma un backup alle 3 di notte e il cron scatta alle 10 di mattina mentre un utente sta navigando, quel visitatore aspetta il backup.

Io disattivo WP-Cron e uso il cron di sistema:

wp config set DISABLE_WP_CRON true --raw
crontab -e
# */5 * * * * cd /percorso/sito && wp cron event run --due-now

Su un sito di news con 80mila visite al giorno, questa modifica ha tolto 0,7 secondi dal tempo medio di risposta nelle ore di punta.

10. Niente CDN

Se i tuoi utenti sono in Italia e il server è in Germania, ogni immagine fa il viaggio. Un CDN mette le risorse statiche nei nodi vicini all'utente: per i siti con traffico estero è il fix col miglior rapporto risultato/prezzo.

11. jQuery caricato inutilmente

Tanti temi caricano jQuery anche se non lo usano. Con WordPress 6.7+ e i blocchi, jQuery serve solo a una manciata di plugin. Rimuoverlo dove non serve fa risparmiare 90 KB e il tempo di parsing.

12. Redirect a catena

URL vecchi che puntano a URL vecchi che puntano a URL nuovi: tre redirect prima della pagina finale. Ogni redirect è un round trip. Trovo catene di 4-5 redirect soprattutto nei siti rifatti con il cambio di struttura permalink. Si risolvono con un controllo rapido:

# richiesta HTTP
curl -I -L https://www.mrtux.it/ 2>/dev/null | grep -i '^HTTP'

Il caso reale: da 8,4 a 1,9 secondi in un pomeriggio

Torno al cliente di Bergamo, così vedi l'ordine di intervento vero. Alle 14:00 ho fatto la diagnosi completa, alle 18:30 il sito era a 1,9 secondi. Ecco cosa ho toccato, in ordine di impatto:

1. Hosting: migrato su VPS con NVMe e PHP 8.3 → TTFB da 1,8s a 0,3s
2. Cache: attivata cache page + Redis → risposta media da 900ms a 180ms
3. Immagini: WebP e ridimensionamento → LCP da 6,2s a 3,1s
4. Database: pulizia revisioni e transients → admin da 2,4s a 0,6s
5. Plugin: disattivato script inutili → 22 richieste in meno per pagina

Il risultato a 30 giorni: vendite tornate al livello precedente, e la posizione media su Google risalita di 11 posti per le keyword principali. Non è magia: è fisica delle richieste HTTP.

L'errore che ho fatto io (così non lo rifai)

Ho iniziato a occuparmi di performance nel 2017 e per due anni ho sbagliato approccio: ottimizzavo le immagini prima di guardare l'hosting. Risultato: clienti che mi dicevano "sì, ma è ancora lento", e avevano ragione. Il TTFB da 1,8 secondi restava lì, perché il collo di bottiglia era il server, non i JPEG.

Oggi l'ordine è fisso: infrastruttura, cache, poi asset, poi database. In quest'ordine. Chi ti vende un pacchetto "velocizza il sito" senza guardarti il TTFB ti sta vendendo fumo.

Cosa fare se non hai tempo (e quanto costa davvero)

Se il sito è il tuo business, il tempo che perdi a fare il debug manuale vale più dell'intervento. Un intervento di assistenza WordPress professionale parte da una diagnosi con misure reali, non da opinioni: ti dico esattamente quali sono le cause, con i numeri alla mano, e intervengo nell'ordine giusto.

Il costo medio di un intervento di velocizzazione da parte mia è tra i 150 e i 400 euro per siti standard, dipende da quante cause ci sono sotto. Se paragonato alle ore che ci perdi tu, o alle vendite che perdi ogni giorno di lentezza, è l'investimento più redditizio che puoi fare sul sito. Se il tuo sito è nato da poco e vuoi evitare di ritrovarti con un problema di performance tra sei mesi, vale la pena partire da una creazione del sito fatta con criterio: hosting giusto, immagini già ottimizzate e cache attiva dall'inizio. E se il tema è la strategia di crescita complessiva, la strategia web marketing ti aiuta a capire dove investire le risorse dopo che il sito è veloce.

Le 3 metriche da tenere d'occhio dopo l'intervento

Dopo la velocizzazione, non basta dire "è veloce". Controllo sempre tre numeri, e te li lascio come checklist:

• LCP sotto i 2,5 secondi su mobile (connessione 4G simulata)
• INP sotto i 200ms (la metrica delle interazioni, quella che Google ora pesa di più)
• TTFB sotto i 600ms con cache attiva

Se questi tre valori sono a posto, il sito è veloce per Google e per gli utenti. Se uno solo è fuori, c'è ancora un collo di bottiglia da trovare.

La checklist che uso a fine intervento

Prima di dichiarare chiuso un intervento di velocizzazione, eseguo sempre questa sequenza. Se il tuo sito è lento, copiatela e applicala nell'ordine, senza saltare passaggi:

1. Misuro: PageSpeed Insights mobile + GTmetrix, salvo lo screenshot del waterfall
2. Controllo il TTFB: se è sopra i 600ms con cache attiva, il problema è infrastruttura, non immagini
3. Verifico la cache: attiva, con esclusioni corrette per carrello e pagine utente loggato
4. Conto le richieste: meno di 40 per pagina su un sito tipo, zero script inutili
5. Pulisco il database: revisioni, transients scaduti, autoload gonfio
6. Ottimizzo gli asset: WebP, lazy loading, font self-hostati
7. Riverifico: stesse metriche di prima, stesso tool, per confrontare i numeri

Se dopo tutta la checklist il LCP resta sopra i 2,5 secondi, nel 90% dei casi la causa è l'hosting. Non perdere tempo a comprimere ancora le immagini: cambia server, è lì che sta il problema.

Sintesi

Il sito lento non è un mistero: è un problema di diagnosi. Misura, trova le cause nell'ordine giusto (infrastruttura prima di tutto), applica i fix e riverifica. Il 90% dei siti che mi portano a riparare ha 2-3 cause combinabili tra quelle che ho elencato, e si risolve in una giornata di lavoro.

Se invece il tuo sito è lento adesso e preferisci che lo sistemi io direttamente, il servizio di velocizzazione pagine è fatto apposta: diagnosi, intervento e verifica con misure prima/dopo, senza che tu debba sporcarti le mani con il terminale. E se hai un sito con un supporto WordPress continuativo, la velocità viene monitorata insieme a tutto il resto, prima che diventi un problema per i tuoi utenti.