Il tuo sito WordPress è lento. Hai installato WP Rocket, ottimizzato le immagini, cambiato hosting. Continua ad essere lento.
Non è colpa tua. È colpa dell'architettura. WordPress ha un problema strutturale con le performance che i plugin di caching risolvono parzialmente — ma non alla radice. Questa guida spiega le cause reali della lentezza di WordPress, cosa funziona e cosa no, e quando ha senso smettere di ottimizzare e cambiare approccio.
Come misurare la lentezza in modo corretto
Prima di ottimizzare qualsiasi cosa, devi sapere cosa stai misurando. La velocità percepita dall'utente e il punteggio PageSpeed sono due cose diverse — e spesso vengono confuse.
La metrica che conta per il business è il Time to First Byte (TTFB) — il tempo che il server impiega a rispondere alla prima richiesta. Se il TTFB supera i 600ms il problema è strutturale: è nel server o nel codice PHP, non nelle immagini o nel CSS. Nessun plugin di caching risolve un TTFB alto in modo permanente.
Le metriche che contano per Google sono i Core Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Total Blocking Time (TBT). Google usa queste metriche come fattore di ranking — un sito lento viene penalizzato nelle ricerche organiche rispetto a competitor più veloci, anche se i contenuti sono equivalenti.
Per misurare correttamente usa PageSpeed Insights su una connessione normale — non in locale, non con VPN. Il punteggio mobile è quello che conta: Google valuta la versione mobile per determinare il ranking. Un punteggio sotto 50 su mobile indica problemi strutturali. Tra 50 e 70 indica ottimizzazioni possibili ma non urgenti. Sopra 80 sei in una posizione competitiva.
Le cause reali della lentezza di WordPress
WordPress è lento per ragioni precise, non casuali. Conoscerle è il primo passo per capire cosa si può risolvere e cosa no.
PHP che compila tutto a ogni richiesta
WordPress è un'applicazione PHP dinamica. Per ogni pagina visitata, il server esegue centinaia di righe di PHP — include file, inizializza classi, carica plugin, interroga il database — e poi genera l'HTML da mandare al browser. Questo processo avviene da zero per ogni richiesta, anche se la pagina non è cambiata da settimane.
OPcache riduce questo costo mettendo in cache il bytecode PHP compilato — ma ogni plugin aggiuntivo aggiunge codice da eseguire, e OPcache non elimina le query al database.
Le query al database che si moltiplicano
Una pagina WordPress standard genera 30-80 query al database MySQL. Con plugin aggiuntivi questo numero sale rapidamente — WooCommerce aggiunge decine di query per ogni pagina prodotto, plugin SEO aggiungono query per metadati, plugin di sicurezza aggiungono query per log e verifiche.
Su un server ben configurato ogni query richiede 1-5ms. Con 80 query sono già 400ms di TTFB solo per le query — prima ancora di calcolare il tempo PHP e di rete. Con database non ottimizzati o query mal scritte, alcune query singole possono richiedere 100-500ms.
Il loop di WordPress
WordPress carica l'intero sistema — tutti i plugin attivi, tutte le loro dipendenze, tutti i loro hook — anche per servire una singola pagina statica. Non esiste selettività nativa: se hai 30 plugin attivi, tutti vengono inizializzati per ogni richiesta, anche quelli non necessari per quella specifica pagina.
Perché il caching non risolve tutto
Il caching è la soluzione più comune alla lentezza di WordPress — e la più fraintesa. Plugin come WP Rocket, W3 Total Cache e LiteSpeed Cache sono strumenti utili, ma risolvono solo una parte del problema e introducono complessità aggiuntiva.
Cosa risolve il caching
Il caching di pagina salva l'HTML generato da WordPress e lo serve direttamente senza eseguire PHP o query al database. Per le pagine statiche — homepage, pagine di testo, articoli del blog — questo riduce drasticamente il TTFB per le visite successive alla prima.
Il caching di oggetti (Redis, Memcached) salva i risultati delle query MySQL in memoria. Riduce il numero di query effettive al database per le richieste ripetute.
Cosa non risolve il caching
Il caching non funziona per le pagine dinamiche — carrelli e-commerce, pagine account, risultati di ricerca, pagine con contenuto personalizzato per utente loggato. Queste pagine devono essere generate da zero per ogni richiesta.
Il caching non risolve il TTFB della prima richiesta dopo una modifica al contenuto — ogni volta che pubblichi un articolo o aggiorni una pagina, la cache viene invalidata e la prossima visita paga il costo completo di generazione.
Il caching non risolve i problemi di hosting sottodimensionato. Se il server non ha abbastanza RAM o CPU per gestire i picchi di traffico, il caching mitiga ma non elimina i rallentamenti.
Il caching non risolve il problema strutturale delle query lente. Una query che richiede 300ms viene saltata dalla cache — ma quando la cache scade, quella query da 300ms rallenta di nuovo il sito.
Il paradosso del caching
Più plugin di caching aggiungi, più complessità introduci. Ogni plugin di caching ha le sue regole di invalidazione, i suoi conflitti con altri plugin, i suoi aggiornamenti che a volte rompono la configurazione. Molti siti WordPress lenti hanno 3-4 plugin di ottimizzazione installati che si contraddicono tra loro — il risultato è spesso peggiore della configurazione senza caching.
Il problema dei plugin e il peso nascosto
Ogni plugin installato su WordPress ha un costo — in memoria, in tempo di esecuzione PHP, in query al database, in file CSS e JavaScript caricati. Questo costo non è sempre visibile, ma si accumula.
Un plugin di form come Gravity Forms aggiunge 200-400KB di JavaScript su ogni pagina, anche quelle senza form. Un plugin SEO come Yoast aggiunge 30-50 query per pagina per leggere i metadati. Un plugin di sicurezza come Wordfence aggiunge un layer di controllo su ogni richiesta HTTP che può aggiungere 50-150ms al TTFB.
La maggior parte dei siti WordPress aziendali ha 20-40 plugin attivi. Il costo aggregato di questi plugin — anche quelli ben scritti — è reale e difficile da eliminare senza rimuovere le funzionalità che forniscono.
Il modo corretto per verificare l'impatto dei plugin è disattivarli uno per uno e misurare il TTFB prima e dopo con PageSpeed Insights. Spesso si scopre che 2-3 plugin specifici causano il 70% della lentezza — e che esistono alternative più leggere o soluzioni native che non richiedono plugin.
Il database WordPress che rallenta nel tempo
Il database di WordPress cresce nel tempo in modo non sempre visibile. Le tabelle che crescono di più e rallentano le query sono quelle meno ovvie.
La tabella wp_options è la più problematica. Ogni plugin può scrivere dati nella tabella options — configurazioni, cache temporanea, log. Con il tempo questa tabella può crescere fino a contenere migliaia di righe, molte delle quali sono dati obsoleti di plugin disinstallati. WordPress carica interamente la parte "autoload" di questa tabella a ogni richiesta — se contiene troppi dati, aggiunge centinaia di ms al TTFB.
Le tabelle wp_postmeta e wp_usermeta crescono con revisioni dei post, metadati di plugin e dati di sessione. Un sito con anni di storia può avere centinaia di migliaia di righe in queste tabelle — query non indicizzate su queste tabelle sono tra le cause più comuni di TTFB alto.
La pulizia periodica del database — rimozione revisioni eccessive, pulizia wp_options, ottimizzazione delle tabelle — è necessaria ma temporanea. Il problema strutturale è che WordPress non gestisce la crescita del database in modo nativo.
Hosting: quando è il problema e quando non lo è
L'hosting è spesso indicato come causa principale della lentezza di WordPress — e a volte è vero, ma spesso viene usato come capro espiatorio per problemi che esistono indipendentemente dal server.
Quando l'hosting è il problema
Un hosting condiviso economico ha risorse limitate e condivise con centinaia di altri siti. Se il TTFB dal server stesso (misurato con curl direttamente sul server) supera i 300ms, l'hosting è probabilmente sottodimensionato. La soluzione è passare a un VPS con PHP-FPM configurato correttamente e risorse dedicate.
Quando l'hosting non è il problema
Se il TTFB dal server è sotto 200ms ma il sito è comunque lento, il problema è nel codice — plugin pesanti, query lente, JavaScript che blocca il rendering. Cambiare hosting non risolverà nulla in questo caso.
Un test semplice: misura il TTFB con curl direttamente dal server:
```bash curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://www.tuosito.it/ ```
Se il risultato è sotto 200ms il server è adeguato. Se supera 500ms il problema è nell'hardware o nella configurazione PHP.
Cosa fare concretamente
Prima di qualsiasi ottimizzazione, misura il TTFB dal server con curl. Questo ti dice immediatamente se il problema è nel codice/database o nell'hardware.
Se il TTFB dal server è alto (oltre 300ms)
Attiva il slow query log di MySQL e identifica le query che impiegano più di 500ms. Quasi sempre sono query su tabelle non indicizzate o query di plugin mal ottimizzati. La soluzione è aggiungere indici alle colonne usate nei WHERE più frequenti o sostituire i plugin responsabili.
Verifica la configurazione PHP-FPM. Con pm = ondemand ogni richiesta crea un nuovo processo PHP da zero — passa a pm = dynamic con start_servers adeguati alla RAM disponibile. Questo da solo può ridurre il TTFB del 30-50% su siti con traffico discontinuo.
Controlla la tabella wp_options per righe in autoload. Una query che mostra più di 1MB di dati in autoload è un problema:
```sql SELECT SUM(LENGTH(option_value)) as total_bytes FROM wp_options WHERE autoload = 'yes'; ```
Se il TTFB dal server è basso ma il sito è lento
Il problema è nel frontend — JavaScript che blocca il rendering, CSS non ottimizzato, immagini non compresse, font caricati in modo bloccante. In questo caso i plugin di ottimizzazione frontend (WP Rocket, impostazioni corrette) sono la strada giusta.
Verifica quali plugin contribuiscono più alla lentezza disattivandoli temporaneamente e misurando il TTFB prima e dopo. Spesso 2-3 plugin specifici causano il 70% del problema.
Quando smettere di ottimizzare e cambiare piattaforma
Ottimizzare WordPress ha senso fino a un certo punto. Oltre quel punto, ogni ottimizzazione aggiuntiva diventa più costosa e meno efficace — e il problema strutturale rimane.
I segnali che indicano che è il momento di considerare un cambio di piattaforma sono precisi:
Hai già ottimizzato hosting, PHP-FPM, database e plugin e il TTFB rimane sopra 400ms. Hai più di 3 plugin di caching o ottimizzazione installati che si contraddicono. Ogni aggiornamento di WordPress rompe qualcosa e richiede un intervento tecnico. I costi di manutenzione annuali superano il costo di realizzazione iniziale del sito. Il team marketing non riesce ad aggiornare i contenuti autonomamente senza rischiare di rompere qualcosa.
In questi casi, il tempo e il denaro spesi in ottimizzazioni successive danno rendimenti decrescenti. La stessa cifra investita in una migrazione a un CMS con architettura più solida produce risultati strutturali — non temporanei.
Un CMS proprietario gestito elimina alla radice i problemi strutturali di WordPress: nessun plugin di terze parti da aggiornare, architettura PHP ottimizzata per la velocità, database progettato per le query del sito specifico. Il TTFB tipico di un sito su KeideaCMS è sotto 100ms dal server — senza plugin di caching, senza ottimizzazioni post-lancio. Il confronto tecnico dettagliato tra WordPress e KeideaCMS è disponibile qui.
Se il tuo sito WordPress è lento e vuoi capire se il problema è ottimizzabile o strutturale, puoi richiedere un audit gratuito. Analizziamo TTFB, query lente, configurazione PHP e peso dei plugin — e ti diciamo onestamente se conviene ottimizzare o migrare.
