Sito WordPress lento: un'analisi tecnica oltre i soliti consigli

Su «sito WordPress lento» circolano da anni gli stessi consigli: comprimi le immagini, installa una cache, togli qualche plugin. Sono consigli corretti, ma restano in superficie. Quando un sito WordPress è lento in modo strutturale, il motivo sta quasi sempre in come genera le pagine e in quanto lavoro scarica sul browser. Questa è la diagnosi che faccio io, nell'ordine in cui la faccio.

Due problemi diversi: server e browser

La lentezza ha due origini che vanno separate subito.

• Lato server: il tempo che PHP e database impiegano a produrre l'HTML. Si legge nel TTFB delle pagine non in cache e incide sull'LCP.
• Lato browser: quanto JavaScript e CSS la pagina deve scaricare, analizzare ed eseguire. Incide su LCP e soprattutto su INP.

Confonderli porta a soluzioni sbagliate: un hosting più potente non sistema un INP rovinato da un builder, e un ottimizzatore di asset non sistema 800 millisecondi di query.

Lato server: cosa fa WordPress a ogni richiesta

A ogni richiesta non servita dalla cache, WordPress carica il core, il tema e tutti i plugin attivi, anche quelli che su quella pagina non fanno nulla. Poi esegue la catena di hook, legge le opzioni e lancia le query del template. I punti in cui il tempo si accumula sono quasi sempre gli stessi.

Le opzioni in autoload

Ogni opzione salvata con autoload = yes in wp_options viene letta a ogni richiesta. Plugin disinstallati male, transient mai scaduti e configurazioni serializzate da centinaia di kilobyte finiscono lì. Ho visto siti con diversi megabyte di autoload: è memoria e tempo pagati su ogni singola pagina. Si misura con una query sulla somma di LENGTH(option_value) e si ripulisce con criterio, non con un plugin «pulisci database» lanciato alla cieca.

Query e meta

WP_Query con meta_query su più chiavi, ordinamenti per campi personalizzati, ricerche con LIKE su post_content: su tabelle wp_postmeta con milioni di righe diventano lente perché quei campi non sono indicizzati in modo utile. Le soluzioni vere sono un modello dati migliore (tassonomie dove servono, tabelle dedicate per dati strutturati) e una object cache persistente come Redis per non ripetere le stesse query.

Hook pesanti e chiamate esterne

Un plugin che su init chiama un'API remota, verifica una licenza o rigenera qualcosa blocca la generazione della pagina finché la risposta non arriva. Query Monitor mostra le richieste HTTP fatte durante la pagina: dovrebbero essere zero.

WP-Cron

Per impostazione predefinita WP-Cron gira durante le visite. Su siti con molti eventi programmati, il visitatore sfortunato paga il costo dei job. Va disattivato e sostituito con un cron di sistema.

Lato browser: dove si perde l'INP

Qui il colpevole principale è quasi sempre il page builder. Genera DOM profondi e ridondanti, carica librerie per animazioni, slider e widget su ogni pagina, e aggiunge JavaScript che si esegue all'avvio. Il risultato sono long task sul thread principale e interazioni che rispondono in ritardo.

Gli altri responsabili ricorrenti:

• script di terze parti: tag manager con dieci tag, chat, mappe, pixel, banner cookie pesanti. Ognuno compete per il thread principale;
• CSS globale non usato: centinaia di kilobyte di regole per componenti che non esistono nella pagina;
• font: troppe varianti, caricate senza font-display adeguato o da server esterni.

«Ottimizzare» qui spesso significa aggiungere un altro plugin che rimanda, unisce o ritarda gli script. Funziona fino a un certo punto, e intanto aggiunge un livello in più che può rompersi a ogni aggiornamento.

Il metodo di diagnosi

1. Dati reali prima di tutto: i Core Web Vitals di Search Console (dati CrUX) dicono quali gruppi di pagine hanno problemi e quale metrica. Un singolo test di laboratorio non basta.
2. TTFB senza cache, misurato su home, archivio e pagina singola.
3. Query Monitor su quelle pagine: numero e durata delle query, componenti più lenti, richieste HTTP, peso dell'autoload.
4. Pannello Performance del browser con CPU rallentata: long task, script più costosi, elemento LCP e sua sorgente.
5. Inventario dei componenti: per ogni plugin, cosa carica e dove. Spesso metà dei plugin si può togliere o sostituire con poche righe di codice.

Solo dopo questa fase ha senso intervenire. Il dettaglio sulle metriche è in Core Web Vitals spiegati da uno sviluppatore.

Quando la cache diventa una toppa

La cache di pagina è indispensabile su WordPress, ma va vista per quello che è: un modo per non eseguire WordPress. Se il sito è veloce solo quando la cache è calda, il problema è ancora lì: lo pagano gli utenti loggati, il carrello, la ricerca, i bot che chiedono pagine non in cache e ogni svuotamento dopo un aggiornamento.

Quando mi accorgo che l'ottimizzazione consiste nell'impilare livelli (cache di pagina, cache degli oggetti, ottimizzatore di asset, CDN, plugin che ritarda gli script) per compensare un tema e un set di plugin che non si possono toccare, è il segnale che il problema è architetturale.

Come la vedo io

Amo WordPress e so renderlo veloce: su progetti scritti a mano, con tema su misura e pochi plugin, i risultati sono ottimi. Ma la maggior parte dei siti lenti che mi arrivano non è lenta per un errore isolato: è lenta perché è cresciuta per accumulo, con componenti legati tra loro al punto che toglierne uno è un rischio. In quei casi preferisco essere onesto: si può ottimizzare, ma spesso si spende meno a ripensare il sito.

Se il sito non ha bisogno di contenuti generati a ogni richiesta, generarlo una volta sola e servirlo da una CDN elimina alla radice metà dei problemi di questo articolo. È il motivo per cui sto spostando molti progetti su Nuxt e Netlify.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Faccio la diagnosi con gli strumenti di uno sviluppatore, non con un punteggio, e ti dico se conviene ottimizzare o cambiare strada.

Se il tuo sito WordPress è lento, scrivimi: in una chiacchierata di circa 20 minuti guardiamo i dati reali e capiamo dove si perde il tempo. Il servizio è in Velocità e SEO.