Molti siti WordPress hanno un sito pubblico veloce, grazie alla cache di pagina, e un’area di amministrazione lenta: la bacheca impiega secondi a comparire, l’elenco degli articoli si carica a fatica, l’editor risponde in ritardo, il salvataggio sembra non finire mai. Per chi lavora ogni giorno sul sito, redattori, responsabili di negozio, gestori di contenuti, è un costo reale in tempo e in pazienza. E un’amministrazione lenta non è un problema isolato: consuma le stesse risorse del server che servono il sito pubblico.
In questo articolo vediamo perché l’amministrazione di WordPress rallenta, quali sono le cause più frequenti, come individuarle e come risolverle.
Perché l’amministrazione è diversa
Il sito pubblico, per la maggior parte dei visitatori, viene servito dalla cache di pagina: la pagina è già pronta e WordPress non viene nemmeno avviato. L’amministrazione non può essere messa in cache in questo modo, perché ogni pagina dipende dall’utente collegato e mostra dati che cambiano. Ogni richiesta avvia WordPress per intero: carica il nucleo, tutti i plugin attivi e il tema, esegue le query al database, costruisce la pagina. Tutto ciò che nel sito pubblico viene nascosto dalla cache, nell’amministrazione emerge senza filtri.
Per questo l’amministrazione è spesso il primo posto in cui si notano i problemi strutturali di un sito: troppi plugin, un database appesantito, un hosting con poche risorse. Non incide sulle Core Web Vitals delle pagine pubbliche, che si misurano sui visitatori, ma le richieste dell’amministrazione occupano gli stessi processi PHP e lo stesso database: un’operazione pesante lanciata da un redattore può rallentare anche i visitatori che in quel momento non trovano la pagina in cache.
Dove va il tempo
Il tempo di generazione di una pagina di amministrazione si divide in poche voci: l’avvio di WordPress, il codice dei plugin, le query al database e, spesso trascurate, le chiamate a servizi esterni.
Le chiamate a servizi esterni. Molti plugin contattano i server dei loro sviluppatori: per verificare la licenza, controllare gli aggiornamenti, scaricare notizie e promozioni da mostrare nella bacheca, inviare statistiche d’uso. Se queste chiamate avvengono durante il caricamento della pagina e il servizio esterno risponde lentamente, o non risponde affatto, la pagina resta in attesa fino alla scadenza del tempo massimo, che può essere di diversi secondi. È una delle cause più frequenti di amministrazioni lente, e spesso intermittente, perché dipende dallo stato di server che non si controllano.
Le query al database. Gli elenchi di articoli, prodotti e ordini possono diventare lenti quando le tabelle crescono, soprattutto se i plugin aggiungono colonne che eseguono una query per ogni riga, o filtri che interrogano i metadati. Le cause sono spesso quelle viste nell’articolo sul database di WordPress: opzioni caricate automaticamente in eccesso, transient accumulati, tabelle dei metadati molto grandi, revisioni senza limite.
Il codice dei plugin. Ogni plugin attivo viene caricato a ogni richiesta, anche nelle schermate in cui non serve. Plugin che eseguono controlli, generano avvisi o preparano dati a ogni caricamento dell’amministrazione aggiungono lavoro a tutte le pagine.
Individuare il colpevole
Lo strumento più utile per diagnosticare un’amministrazione lenta è il plugin Query Monitor. Una volta attivato, mostra per ogni pagina il tempo di generazione, la memoria usata, le query al database con il loro tempo e il componente che le ha eseguite, le chiamate a servizi esterni con la loro durata, gli hook eseguiti e gli errori PHP. Ordinando le query per tempo e raggruppandole per plugin, di solito il colpevole emerge in pochi minuti. Le chiamate esterne lente sono evidenziate, con l’indirizzo contattato e il plugin responsabile.
Un metodo complementare, più rudimentale ma efficace, è disattivare i plugin uno alla volta in un ambiente di prova e misurare il tempo di caricamento di una schermata di riferimento, per esempio la bacheca o l’elenco degli articoli. Alcuni servizi di hosting offrono strumenti di profilazione del codice PHP, che mostrano quali funzioni consumano più tempo.
L’API Heartbeat
WordPress include un meccanismo chiamato Heartbeat, che mantiene un dialogo periodico tra il browser e il server mentre l’amministrazione è aperta. Serve a funzioni utili: il blocco di un articolo quando un altro utente lo sta modificando, le notifiche di sessione scaduta, e alcuni plugin lo usano per aggiornare dati in tempo reale. Ogni battito è una richiesta a admin-ajax.php, che avvia WordPress per intero.
Di norma il battito avviene ogni 15 secondi nell’editor e ogni 60 nelle altre schermate, e rallenta quando la scheda non è in primo piano. Con un solo redattore il carico è modesto. Ma con molti redattori, ciascuno con diverse schede aperte, e con plugin che agganciano operazioni pesanti a ogni battito, le richieste diventano centinaia al minuto, su un server che magari ha pochi processi PHP disponibili. È un caso tipico di siti editoriali e di negozi con più operatori.
L’intervallo si può aumentare con un filtro, o con le opzioni di molti plugin di ottimizzazione. Disattivarlo del tutto è sconsigliabile nell’editor, perché si perdono il blocco degli articoli e altre funzioni di sicurezza; è invece spesso accettabile nella bacheca e sul sito pubblico, dove alcuni temi e plugin lo attivano senza bisogno.
// Heartbeat ogni 60 secondi invece di 15 nell’editor.
add_filter(
'heartbeat_settings',
function ( $settings ) {
$settings['interval'] = 60;
return $settings;
}
);admin-ajax.php e il sito pubblico
Il file admin-ajax.php non è usato solo dall’amministrazione: molti plugin lo usano anche sul sito pubblico, per filtri, contatori, moduli, carrelli, caricamenti successivi di contenuti. Queste richieste non passano dalla cache di pagina e avviano WordPress per intero, esattamente come l’amministrazione. Un plugin che fa una richiesta a admin-ajax.php a ogni visualizzazione di pagina, per esempio per contare le visite, annulla in parte i benefici della cache: il visitatore riceve la pagina in pochi millisecondi, ma il server deve comunque eseguire WordPress. Nei log del server, un volume elevato di richieste a questo file è un segnale da indagare, anche perché è un bersaglio frequente del traffico automatico.
L’editor a blocchi
L’editor a blocchi è un’applicazione JavaScript complessa, e la sua velocità dipende sia dal server sia dal computer del redattore. Le cause più comuni di lentezza sono i plugin che registrano molti blocchi e pannelli aggiuntivi, ciascuno con i propri script caricati all’apertura dell’editor; i vecchi riquadri delle opzioni, che alcuni plugin aggiungono sotto l’editor; e gli articoli molto lunghi, con centinaia di blocchi. Disattivare i blocchi non usati, preferire plugin che caricano i propri script solo quando servono e dividere i contenuti molto lunghi migliora sensibilmente la reattività. Il salvataggio, invece, dipende dal server: se è lento, le cause sono di solito le stesse viste per le altre pagine, con in più le operazioni che alcuni plugin eseguono al salvataggio, come la rigenerazione di mappe del sito o l’invio a servizi esterni.
La libreria media e il caricamento delle immagini
Un’altra fonte frequente di lentezza è il caricamento delle immagini. Per ogni immagine caricata, WordPress genera un file per ciascuna dimensione registrata: quelle del nucleo, quelle del tema e quelle aggiunte dai plugin, come i costruttori di pagine o i plugin dei negozi. Non è raro trovare siti con venti o trenta dimensioni registrate, molte delle quali non più usate: ogni caricamento genera decine di file, occupa spazio e tiene occupato un processo PHP per diversi secondi. Se a questo si aggiunge un plugin di ottimizzazione delle immagini che comprime ogni file subito dopo il caricamento, sullo stesso server, il caricamento di una galleria può diventare lentissimo. Conviene verificare le dimensioni registrate e rimuovere quelle inutili, e preferire servizi di ottimizzazione che lavorano in background o, come visto nell’articolo sulle CDN per immagini, trasformazioni eseguite al momento della richiesta. Anche la libreria media in modalità griglia può diventare lenta con decine di migliaia di file: la vista a elenco e i filtri per data aiutano a mantenerla utilizzabile.
Le operazioni pianificate
WordPress esegue le operazioni pianificate, come la pubblicazione degli articoli programmati, l’invio delle email o le pulizie periodiche dei plugin, tramite wp-cron, che viene avviato dalle visite al sito, comprese quelle all’amministrazione. Se un plugin pianifica operazioni pesanti, come importazioni, sincronizzazioni con un gestionale o la generazione di copie di sicurezza, queste possono partire proprio mentre un redattore sta lavorando e rallentarne le pagine. Sostituire l’attivazione tramite visite con un’operazione pianificata del sistema, a intervalli regolari, e spostare le operazioni pesanti negli orari di minor traffico rende i tempi più prevedibili.
Interventi strutturali
- object cache persistente: con un object cache come Redis, i risultati delle query e le opzioni restano in memoria tra una richiesta e l’altra. L’amministrazione, che non può usare la cache di pagina, è la parte del sito che ne beneficia di più;
- versione di PHP: le versioni recenti di PHP sono sensibilmente più veloci delle precedenti, e l’aggiornamento è spesso il miglioramento più semplice;
- risorse del server: un numero adeguato di processi PHP e memoria sufficiente evitano che le richieste dell’amministrazione si mettano in coda con quelle del sito, come discusso nell’articolo sull’hosting;
- tabelle dedicate per i dati grandi: nei negozi, l’archiviazione degli ordini in tabelle dedicate, introdotta da WooCommerce, rende molto più rapidi gli elenchi degli ordini rispetto al vecchio sistema basato sui metadati degli articoli, come visto nell’articolo su WooCommerce;
- meno plugin: ogni plugin eliminato è codice in meno eseguito a ogni richiesta. Una revisione periodica dei plugin attivi, con la domanda di cosa succederebbe disattivandoli, è l’intervento più economico.
Un esempio concreto
Una redazione di otto persone lamenta un’amministrazione lentissima nelle ore di punta: la bacheca impiega fino a quattro secondi, e il salvataggio degli articoli a volte fallisce. Query Monitor mostra che un plugin commerciale verifica la licenza contattando il proprio server a ogni caricamento, con risposte che superano il secondo, e che un plugin di statistiche esegue a ogni battito di Heartbeat una query pesante sulle visite. Con otto redattori e più schede aperte, le richieste di Heartbeat superano le cento al minuto. L’intervento porta la verifica della licenza in un’operazione pianificata giornaliera, grazie a un’opzione del plugin, sposta il calcolo delle statistiche in un’operazione pianificata, porta l’intervallo di Heartbeat a 60 secondi e attiva un object cache persistente. La bacheca scende sotto il mezzo secondo, i salvataggi tornano regolari e, come effetto collaterale, il tempo di risposta delle pagine pubbliche non in cache migliora nelle ore di lavoro della redazione.
In sintesi
L’amministrazione di WordPress non può contare sulla cache di pagina, e per questo mostra senza filtri i problemi del sito: plugin pesanti, query lente, chiamate a servizi esterni, operazioni pianificate nei momenti sbagliati. Query Monitor permette di individuare rapidamente il colpevole. L’API Heartbeat va regolata, non disattivata nell’editor. Le richieste a admin-ajax.php dal sito pubblico meritano attenzione, perché aggirano la cache. Object cache persistente, versioni recenti di PHP, risorse adeguate e meno plugin sono gli interventi strutturali. Il beneficio va oltre la produttività di chi lavora sul sito: le risorse liberate dall’amministrazione tornano disponibili per i visitatori.
