Quando si pensa alla velocità di un sito WordPress, il database resta spesso sullo sfondo. Eppure ogni pagina che non viene servita dalla cache di pagina passa da lì: WordPress legge le impostazioni, i contenuti, i metadati, i menu, i dati dei plugin, e ogni lettura ha un costo. Su un sito appena installato questo costo è trascurabile. Dopo qualche anno di attività, con decine di plugin installati e rimossi, migliaia di revisioni, sessioni, log e dati temporanei mai eliminati, il database può diventare la ragione principale per cui carrello, area riservata, ricerca e bacheca rispondono lentamente.
In questo articolo vediamo le cause più comuni di un database lento in WordPress, come individuarle con strumenti alla portata di tutti e come intervenire in sicurezza, senza affidarsi a pulizie aggressive che rischiano di cancellare dati importanti.
Quando il database conta
Il database incide sul TTFB di tutte le richieste che WordPress deve elaborare: pagine per utenti collegati, carrello e checkout dei negozi, ricerche interne, chiamate AJAX e della REST API, bacheca di amministrazione, operazioni pianificate. Le pagine servite dalla cache di pagina non lo toccano, per cui un sito vetrina interamente in cache può avere un database trascurato senza conseguenze visibili per i visitatori. Un negozio online, un sito con utenti registrati o con molte funzioni dinamiche, invece, ne dipende a ogni passo, come abbiamo visto parlando delle Core Web Vitals per WooCommerce.
Le opzioni caricate automaticamente
La tabella wp_options contiene le impostazioni del sito, del tema e dei plugin. Alcune opzioni sono contrassegnate per il caricamento automatico: WordPress le legge tutte insieme, con una sola query, all’inizio di ogni richiesta. È un meccanismo efficiente finché le opzioni sono poche e piccole. Il problema nasce quando la loro dimensione complessiva cresce fino a diversi megabyte: ogni richiesta non in cache deve leggerle, trasferirle da MySQL a PHP e decodificarle, anche se ne userà una minima parte.
Le cause tipiche sono tre. Plugin disinstallati che hanno lasciato le proprie impostazioni, a volte molto voluminose. Plugin attivi che usano le opzioni come cache o come registro, salvandovi dati che crescono nel tempo. Transient, cioè dati temporanei con una scadenza, che senza una cache degli oggetti vengono salvati nella stessa tabella. Lo strumento Salute del sito, nelle versioni recenti di WordPress, segnala quando la dimensione complessiva delle opzioni caricate automaticamente supera una soglia consigliata; per un’analisi più precisa, una query elenca le opzioni più grandi:
-- Le 20 opzioni caricate automaticamente più grandi
SELECT option_name, ROUND( LENGTH( option_value ) / 1024 ) AS kb
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto-on', 'auto' )
ORDER BY LENGTH( option_value ) DESC
LIMIT 20;Dal nome dell’opzione si risale quasi sempre al plugin che l’ha creata. Le opzioni di plugin non più installati possono essere eliminate, dopo un backup; quelle di plugin attivi ma usate raramente possono essere escluse dal caricamento automatico, e WordPress offre funzioni dedicate per cambiarne l’impostazione senza toccare il valore.
// Esclude dal caricamento automatico un’opzione grande e usata di rado
wp_set_option_autoload( 'plugin_statistiche_cache', false );I metadati e le query lente
WordPress conserva molte informazioni aggiuntive di articoli, prodotti, utenti e ordini in tabelle di metadati, come wp_postmeta, dove ogni informazione è una riga con una chiave e un valore. È un modello flessibile, che permette a qualsiasi plugin di aggiungere campi senza modificare le tabelle, ma che si presta male alle ricerche: la colonna dei valori non è indicizzata, e una ricerca che filtra per valore, come «tutti i prodotti con un certo attributo» o «tutti gli eventi dopo una certa data», costringe il database a scorrere un numero enorme di righe. Su un catalogo con decine di migliaia di prodotti, la tabella dei metadati può contare milioni di righe, e una singola query di questo tipo può richiedere centinaia di millisecondi.
Le soluzioni dipendono dal caso. Alcuni plugin dedicati aggiungono indici più efficaci alle tabelle dei metadati di WordPress, con benefici rilevanti sui siti grandi. WooCommerce ha spostato gli ordini in tabelle proprie, ottimizzate per le ricerche, con l’archiviazione degli ordini ad alte prestazioni. Per le funzioni personalizzate, conviene evitare le ricerche per valore dei metadati quando esiste un’alternativa, come una tassonomia per gli attributi su cui si filtra spesso.
Revisioni, transient, sessioni e log
Altre tabelle crescono silenziosamente. Le revisioni: WordPress conserva una copia di ogni salvataggio di articoli e pagine, e su un sito editoriale attivo da anni possono diventare decine di migliaia, con i relativi metadati. Limitarne il numero è semplice, e le revisioni più vecchie possono essere rimosse:
// wp-config.php: conserva al massimo 10 revisioni per contenuto
define( 'WP_POST_REVISIONS', 10 );I transient scaduti, senza una cache degli oggetti, restano nella tabella delle opzioni finché qualcuno non li legge: su siti con molti plugin possono accumularsene migliaia. Le sessioni dei negozi online, i log di plugin di sicurezza, di posta e di statistiche, e le tabelle delle operazioni pianificate, come quelle dell’Action Scheduler usato da WooCommerce e da molti altri plugin, possono raggiungere milioni di righe se nessuno imposta una durata di conservazione. Ognuna di queste tabelle rallenta le query che la toccano e appesantisce backup e ripristini.
Con WP-CLI, lo strumento a riga di comando di WordPress, alcune pulizie si eseguono con un comando:
# Elimina i transient scaduti
wp transient delete --expired
# Dimensione delle tabelle, per trovare quelle cresciute troppo
wp db size --tables --size_format=mbCome diagnosticare
Lo strumento più utile per capire cosa succede nel database è Query Monitor, un plugin gratuito che mostra, per ogni pagina visitata da un amministratore, tutte le query eseguite, il loro tempo, il componente che le ha generate, cioè core, tema o plugin, e le query duplicate. Ordinando per tempo si trovano in pochi secondi le query più lente; raggruppando per componente si scopre quale plugin genera più lavoro. Conviene usarlo sulle pagine dinamiche che contano, come il carrello o una ricerca, non sulla home in cache.
Sul server, il registro delle query lente di MySQL o MariaDB, se l’hosting permette di attivarlo, raccoglie tutte le query che superano una certa durata, comprese quelle eseguite da operazioni pianificate e chiamate in background che Query Monitor non vede. Infine, la dimensione delle tabelle e il numero di righe, visibili con WP-CLI o dal pannello di gestione del database, indicano dove si è accumulato il peso.
Pulire in sicurezza
Esistono plugin che promettono di ottimizzare il database con un clic. Alcuni fanno un buon lavoro sulle voci più sicure, come revisioni, transient scaduti e commenti di spam; altri propongono di eliminare tabelle e opzioni «orfane» con criteri approssimativi, con il rischio di cancellare dati di plugin ancora in uso. Alcune regole evitano brutte sorprese.
- Backup prima di tutto. Una copia completa del database, verificata, prima di qualsiasi eliminazione.
- Prima misurare. Individuare con Query Monitor e con la dimensione delle tabelle dove sta davvero il problema, invece di pulire tutto a caso.
- Una cosa alla volta. Intervenire su una tabella o un gruppo di opzioni, verificare che il sito funzioni, misurare l’effetto, poi passare al successivo.
- Preferire le impostazioni ai cancellamenti. Durate di conservazione per log e operazioni pianificate, limite alle revisioni, pulizia automatica delle sessioni: prevenire la crescita è meglio che pulire periodicamente.
- Provare prima su una copia. Per le operazioni più invasive, come l’aggiunta di indici o la conversione delle tabelle, un ambiente di prova evita di scoprire i problemi in produzione.
Il ruolo del server e della cache degli oggetti
Non tutto dipende dal contenuto del database. La versione di MySQL o MariaDB, la memoria assegnata alla cache interna del database e il motore delle tabelle incidono sulle prestazioni: le tabelle con il vecchio motore MyISAM, ancora presenti in alcuni siti datati, gestiscono peggio gli accessi concorrenti e andrebbero convertite nel motore InnoDB, oggi standard. Su hosting gestiti questi aspetti sono di solito curati dal fornitore; su server propri vanno verificati.
Una cache degli oggetti come Redis riduce il numero di query ripetute e sposta i transient fuori dalla tabella delle opzioni, ma non risolve le query lente per natura, come le ricerche sui metadati, né rende leggere le opzioni caricate automaticamente: le memorizza, ma le deve comunque trasferire e decodificare a ogni richiesta. Pulizia del database e cache degli oggetti sono complementari, non alternative.
Un esempio
Un negozio online attivo da sei anni ha un carrello che risponde in 1,4 secondi e una bacheca di amministrazione lenta al punto da scoraggiare chi gestisce gli ordini. Lo strumento Salute del sito segnala opzioni caricate automaticamente per oltre 5 megabyte; Query Monitor mostra, sulla pagina del carrello, una query di un plugin di filtri che cerca nei metadati dei prodotti per oltre mezzo secondo, e la dimensione delle tabelle rivela un registro dell’Action Scheduler con quattro milioni di righe e una tabella delle sessioni con centinaia di migliaia di sessioni scadute. L’intervento, eseguito prima su una copia del sito, rimuove le opzioni di undici plugin disinstallati, esclude dal caricamento automatico due opzioni usate solo nella bacheca, imposta una durata di conservazione di un mese per il registro delle operazioni pianificate, elimina le sessioni scadute e aggiunge indici alle tabelle dei metadati. Il carrello scende sotto i 500 millisecondi, la bacheca torna scorrevole e i backup notturni richiedono un terzo del tempo.
La manutenzione periodica
Il database non si sistema una volta per tutte. Ogni nuovo plugin porta con sé le proprie opzioni e tabelle, ogni campagna genera sessioni e ordini, ogni aggiornamento può cambiare il modo in cui i dati vengono salvati. Una verifica ogni pochi mesi, con lo strumento Salute del sito, la dimensione delle tabelle e un giro di Query Monitor sulle pagine dinamiche principali, permette di accorgersi della crescita prima che diventi un problema. Quando si disinstalla un plugin, conviene verificare se offre un’opzione per rimuovere i propri dati, spesso disattivata per impostazione predefinita, e usarla se non si prevede di reinstallarlo. È un lavoro di pochi minuti che evita, a distanza di anni, interventi molto più impegnativi.
In sintesi
Il database di WordPress incide su tutte le richieste che non passano dalla cache di pagina: carrelli, aree riservate, ricerche, API e amministrazione. Con il tempo si appesantisce in modi prevedibili: opzioni caricate automaticamente che crescono fino a megabyte, ricerche sui metadati senza indici adeguati, revisioni, transient, sessioni, log e operazioni pianificate che nessuno elimina.
La diagnosi è alla portata di tutti, con lo strumento Salute del sito, Query Monitor e una misura della dimensione delle tabelle. Gli interventi vanno fatti con metodo, dopo un backup e una cosa alla volta, preferendo impostazioni che prevengano la crescita a pulizie aggressive. Insieme a una cache degli oggetti e a un server configurato bene, un database curato riporta le pagine dinamiche a tempi di risposta che gli utenti non notano più.
