Dati di Autoload di WordPress: Cos'è e Come Pulirlo

Lo stato di salute del sito segnalava da mesi un problema critico su uno dei miei siti: Le opzioni caricate automaticamente potrebbero influire sulle prestazioni.

L'ho ignorato. Il sito sembrava funzionare bene.

Poi qualcuno mi ha chiesto perché la bacheca impiegasse quasi dieci secondi per caricarsi, mentre la homepage appariva istantaneamente. Così, ho finalmente controllato la dimensione dell'autoload e ho trovato megabyte di opzioni nel database, la maggior parte delle quali scritte da plugin che avevo disinstallato anni prima.

La parte frustrante è che la maggior parte dei consigli su questo argomento è obsoleta. WordPress 6.6 ha cambiato il modo in cui funziona l'autoload e la query che quasi tutte le guide pubblicano ancora ora restituisce il numero sbagliato.

Molti dei consigli standard di pulizia non riducono nemmeno la dimensione dell'autoload, per ragioni sepolte nel core di WordPress.

In questo post, ti mostrerò cosa sono i dati di autoload di WordPress, come misurarli correttamente su un'installazione moderna, cosa è sicuro rimuovere e come pulirli senza compromettere il tuo sito.

Ecco i punti chiave:

• I dati di autoload vengono caricati su ogni richiesta che raggiunge WordPress, comprese le pagine di amministrazione, le chiamate REST e i processi cron, quindi la cache della pagina non li nasconde mai.
• WordPress segnala un problema critico di stato del sito sopra gli 800 KB di opzioni caricate automaticamente, che è la cosa più vicina a un limite ufficiale che troverai.
• La query SQL nella maggior parte delle guide ora sottostima. WordPress 6.6 ha sostituito i vecchi valori sì/no per l'autoload con cinque possibili valori, quindi filtrare su autoload='yes' perde le righe più recenti.
• La cancellazione dei transienti scaduti cambia a malapena la dimensione dell'autoload. I transienti creati con una data di scadenza non vengono caricati automaticamente in primo luogo, motivo per cui i plugin di pulizia del database sembrano non fare nulla qui.
• Il vero gonfiore sono solitamente le opzioni orfane dei plugin, lasciate indietro da plugin che hai rimosso anni fa, poiché nulla le pulisce automaticamente.
• Il DB Optimizer di Duplicator misura la dimensione dell'autoload come parte del suo punteggio di salute del database, il che lo rende il modo più semplice per monitorare il numero nel tempo. La cancellazione delle opzioni caricate automaticamente è ancora un lavoro manuale.
• Disattivare l'autoload è più sicuro che eliminarlo. I dati rimangono nel database nel caso in cui un plugin ne abbia bisogno e la modifica è reversibile.
• Non modificare mai wp_options senza un backup corrente. Stai lavorando nella tabella che può mettere offline l'intero tuo sito.
• Se la dimensione dell'autoload torna entro pochi giorni da una pulizia, un plugin la sta riscrivendo ad ogni esecuzione e nessuna quantità di pulizia sarà sufficiente.

Indice

Cosa sono i dati autoload in WordPress?

Ogni sito WordPress memorizza le sue impostazioni in una tabella di database chiamata wp_options. L'URL del tuo sito si trova lì. Così come il tuo elenco di plugin attivi, le impostazioni del tema e la configurazione di quasi tutti i plugin che hai installato.

Ogni riga in quella tabella ha una colonna autoload. Quella colonna risponde a una domanda: WordPress dovrebbe caricare questa riga ad ogni singola pagina o solo quando qualcosa la richiede?

Quando la risposta è sì, l'opzione viene caricata automaticamente. Questo è tutto ciò che significa il termine. Viene caricata automaticamente, indipendentemente dal fatto che la pagina corrente ne abbia bisogno o meno.

WordPress fa questo per una buona ragione. Invece di eseguire una query di database separata ogni volta che un plugin richiede un'impostazione, recupera tutte le opzioni autoloaded con un'unica query all'inizio della richiesta e le mantiene in memoria. Una query è meglio di qualche centinaio di piccole query.

Ecco cosa finisce tipicamente memorizzato come opzioni autoloaded:

• Impostazioni principali senza le quali il tuo sito non può funzionare, come siteurl, home, active_plugins, template e stylesheet
• Configurazione del plugin, spesso memorizzata come un unico grande array serializzato per plugin
• Chiavi di licenza e dati di attivazione da plugin e temi premium
• Risposte API in cache che un plugin ha salvato come opzione normale invece di un transient appropriato
• Rimasugli di plugin che hai rimosso, che nulla pulisce da solo
• Transients creati senza un tempo di scadenza, che vengono caricati automaticamente per impostazione predefinita

Il design va bene. È l'accumulo che causa problemi.

Perché i dati autoload rallentano il tuo sito?

Ogni richiesta che raggiunge WordPress paga per la dimensione del tuo autoload. Questo influisce non solo sulle visualizzazioni di pagina dei visitatori, ma anche sulle schermate di amministrazione, sulle chiamate API REST, sui processi WP-Cron, sulle richieste AJAX e su ogni attività in background che i tuoi plugin attivano.

Il costo non è solo la query. I valori delle opzioni sono memorizzati serializzati, quindi PHP deve deserializzarli tutti in memoria ad ogni caricamento. Una tabella autoload di 3 MB significa che il tuo sito ricostruisce 3 MB di array PHP prima di visualizzare una singola parola di contenuto.

Questa è memoria e CPU, ad ogni richiesta, per sempre.

La cache delle pagine non aiuta in questo caso. Una cache serve ai visitatori una pagina HTML finita, quindi quelle richieste saltano completamente WordPress. Le tue richieste personali no.

Ecco dove una tabella autoload gonfia si manifesta per prima:

• wp-admin risulta lento mentre il frontend rimane veloce, poiché le pagine di amministrazione non vengono mai memorizzate nella cache
• L'editor a blocchi è lento durante il salvataggio o il caricamento perché ogni richiesta dell'editor passa attraverso un caricamento completo di WordPress
• Carrelli e checkout di WooCommerce sono lenti, poiché tali pagine sono escluse dalla cache per progettazione
• Gli utenti con accesso effettuato ottengono un sito più lento rispetto a tutti gli altri, il che rende il problema difficile da riprodurre
• I processi Cron si accumulano, perché ognuno comporta lo stesso overhead

Se il tuo host ti ha mai detto che il database va bene mentre la tua dashboard rallenta, questo è solitamente il motivo. La dimensione dell'autoload non compare nelle metriche che la maggior parte degli host controlla.

Voglio essere onesto riguardo all'ambito, però. Il bloat dell'autoload è raramente l'unica cosa che rallenta un sito, e liberarsene non salverà un sito con un host lento e immagini non ottimizzate.

È solo la parte che quasi nessuno controlla, e cresce silenziosamente ogni mese che continui a gestire il tuo sito.

Quanti dati autoload di WordPress sono troppi?

Cerca questa domanda e otterrai cinque risposte diverse. Alcune guide dicono 300KB, altre 1MB.

WordPress 6.6 ha stabilito la linea per tutti. Site Health ora mostra un problema critico quando le tue opzioni totali caricate automaticamente superano gli 800KB.

Ecco come interpreto gli intervalli in pratica:

• Sotto gli 800KB: sano. Site Health rimane silenzioso e non hai nulla da inseguire.
• Da 800KB a 1MB: vale la pena dare un'occhiata. Hai superato la soglia principale, e di solito sono uno o due plugin a farlo.
• Da 1MB a 3MB: un vero problema. Aspettati schermate di amministrazione notevolmente più lente, specialmente su hosting condiviso.
• Oltre 3MB: qualcosa sta attivamente scrivendo spazzatura secondo una pianificazione, e la pulizia non servirà finché non lo troverai.

Puoi aumentare la soglia con il filtro site_status_autoloaded_options_size_limit, ma questo nasconde solo l'avviso. Le query vengono ancora eseguite con la stessa dimensione.

Anche la dimensione da sola non ti dice tutto. Cento piccole righe orfane valgono meno della tua attenzione di un singolo array serializzato da 2MB di un plugin slider che hai smesso di usare nel 2022.

Insegui i maggiori responsabili, non il conteggio.

Un altro buon comportamento da conoscere: da WordPress 6.6, qualsiasi nuova opzione più grande di 150KB viene impostata per non essere caricata automaticamente per impostazione predefinita.

Il core ha preso quella decisione perché le opzioni caricate automaticamente sovradimensionate erano un problema di performance così comune. È filtrabile tramite wp_max_autoloaded_option_size, anche se aumentarlo è una cattiva idea.

Quella protezione si applica solo in avanti. Tutto ciò che è già presente nel tuo database da prima viene ancora caricato automaticamente esattamente come ha sempre fatto.

Perché la maggior parte delle guide sull'autoload ora ti dà il numero sbagliato

Per la maggior parte della storia di WordPress, la colonna autoload conteneva uno di due valori: yes o no. Semplice. Ogni tutorial mai scritto sui dati autoload si basava su questa supposizione.

WordPress 6.6 lo ha sostituito con cinque valori possibili:

• on: impostato esplicitamente per il caricamento automatico, e lo sarà sempre
• off: impostato esplicitamente per non caricare automaticamente, e non lo farà mai
• auto: nessuna preferenza esplicita è stata data, quindi WordPress decide (e attualmente lo carica automaticamente)
• auto-on: WordPress ha deciso dinamicamente che dovrebbe essere caricato automaticamente
• auto-off: WordPress ha deciso dinamicamente che non dovrebbe esserlo, di solito perché il valore è superiore a 150KB

Le righe esistenti non sono state migrate. Le opzioni create prima della modifica mantengono i loro valori originali yes e no, che il core tratta come equivalenti a on e off.

Quindi qualsiasi sito che è stato eseguito durante l'aggiornamento 6.6 ora contiene un mix di valori vecchi e nuovi nella stessa colonna.

Molte persone ti diranno di eseguire una query filtrata su autoload='yes'. Su un sito moderno, quella query salta silenziosamente ogni opzione scritta da 6.6, insieme a qualsiasi cosa del core contrassegnata come auto o auto-on.

Ottieni un numero. Semplicemente non è il tuo numero, ed è sempre troppo basso.

La soluzione è controllare ogni valore che WordPress considera autoloading. Il core espone esattamente quell'elenco tramite wp_autoload_values_to_autoload(), che restituisce yes, on, auto-on e auto per impostazione predefinita.

Quale query SQL dovresti eseguire invece?

Se hai accesso a phpMyAdmin o allo strumento database del tuo host, queste due query ti diranno quasi tutto ciò di cui hai bisogno. Eseguile sul database del tuo sito nella scheda SQL.

Prima di eseguire qualsiasi cosa su wp_options, crea un backup. Queste due query leggono solo i dati e non cambiano nulla, ma la sezione successiva ti porta a modificare le righe, ed è meglio essere al sicuro che dispiaciuti.

Inizia con la dimensione totale dell'autoload:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Ciò restituisce il tuo totale in kilobyte insieme al conteggio di quante opzioni sono coinvolte. Confrontalo con la soglia di 800 KB della sezione precedente.

Quindi scopri cosa è responsabile:

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

Questo ti fornisce le venti opzioni autoloaded più grandi per nome, con le loro dimensioni individuali e il loro valore autoload corrente. Sulla maggior parte dei siti, le prime tre o quattro righe rappresentano la maggior parte del problema.

Due cose da osservare prima di copiarle:

• Il prefisso della tua tabella potrebbe non essere wp_. Molte installazioni usano qualcosa di personalizzato per motivi di sicurezza. Controlla wp-config.php per il valore $table_prefix e sostituiscilo nella query.
• Multisite funziona in modo diverso. Ogni sottosito ha la propria tabella delle opzioni (wp_2_options, wp_3_options, e così via), più una tabella wp_sitemeta a livello di rete. Dovrai controllarle separatamente.

Se preferisci usare la riga di comando, WP-CLI gestisce entrambi i lavori in una sola riga ciascuno. Questo restituisce il tuo totale in byte:

wp option list --autoload=on --format=total_bytes

E questo elenca le opzioni autoloaded con le loro dimensioni memorizzate:

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

Non tutti vogliono toccare una console di database, e non devi farlo. La sezione successiva copre due percorsi che rimangono all'interno della dashboard di WordPress.

Come controllare la dimensione dei dati autoload di WordPress?

Non puoi risolvere ciò che non hai misurato, e vorrai misurare di nuovo dopo ogni modifica che apporti.

Ci sono tre modi per ottenere il numero, a seconda di quanto vuoi avvicinarti al database.

Opzione 1: Salute del sito (Il percorso più veloce)

WordPress controlla già questo per te. Vai su Strumenti » Stato del sito e apri la scheda Stato, quindi cerca Le opzioni autoloaded potrebbero influire sulle prestazioni nell'elenco.

Espandila e otterrai la tua dimensione totale.

Il problema è che questo controllo appare solo una volta che sei sopra gli 800 KB. Il silenzio non significa che sei a zero; significa che sei sotto la soglia. Ti fornisce anche un singolo snapshot senza cronologia e senza modo di agire su ciò che mostra.

Opzione 2: Punteggio di salute di DB Optimizer (il più facile da monitorare)

Se vuoi monitorare le dimensioni di autoload nel tempo anziché controllarle una sola volta, DB Optimizer le inserisce in una dashboard.

Apri DB Optimizer e otterrai un punteggio di salute del database da 0 a 100. Cinque barre colorate suddividono il punteggio: overhead delle tabelle, transienti, revisioni, dimensioni di autoload e elementi cestinati.

Lascia che sia chiaro su cosa fa e cosa non fa. DB Optimizer misura le dimensioni di autoload e le segnala. Non cancella le opzioni caricate automaticamente.

La rimozione dei dati caricati automaticamente è ancora un lavoro manuale e lo illustrerò di seguito.

Ciò che pulisce sono le revisioni dei post, le bozze automatiche, i contenuti cestinati, i commenti spam, i transienti scaduti, i pingback, i trackback e la cache oEmbed. Quelli valgono davvero la pena di essere puliti. Sono solo un problema diverso dall'autoload.

Prima di iniziare una pulizia manuale, non guasta fare una rapida pulizia del database. Apri la scheda Cleanup ed esegui tutte le ottimizzazioni disponibili.

Quindi, vai alla scheda Tables. Ottimizza tutte le tabelle con overhead.

Premi Refresh Score nella dashboard e osserva cosa succede alle dimensioni di autoload:

• Il punteggio aumenta notevolmente: i transienti non scaduti facevano parte del tuo problema e ne hai risolto una parte.
• Il punteggio si muove a malapena: il tuo bloat sono opzioni di plugin orfane e nessuno strumento di pulizia le toccherà. Vai direttamente ai metodi manuali.
• Il punteggio aumenta e torna indietro entro pochi giorni: un plugin attivo sta riscrivendo le opzioni caricate automaticamente ad ogni esecuzione.

Quest'ultimo caso vale la pena di essere individuato presto. Ti evita di pulire le stesse righe ogni mese e di chiederti perché nulla rimane.

DB Optimizer ti avvisa anche quando non hai un backup recente e ti collega direttamente alla creazione di uno. È incluso gratuitamente con i piani Duplicator Pro ed Elite, così puoi mantenere il tuo sito sicuro e funzionante senza intoppi.

Opzione 3: Esegui tu stesso la query (La più precisa)

I comandi SQL e WP-CLI nella sezione precedente ti forniscono il numero esatto e l'elenco completo classificato, senza alcuna soglia che nasconda nulla.

Questo è il percorso che uso quando sto per cambiare qualcosa, perché è l'unico che ti mostra il valore di autoload corrente di ogni riga. Ne hai bisogno prima di iniziare a modificare.

Perché una pulizia del database non ha risolto le dimensioni del tuo autoload?

Ecco il consiglio che troverai su quasi ogni articolo su questo argomento: pulisci i tuoi transienti e le dimensioni del tuo autoload diminuiranno.

È per lo più sbagliato, e il core di WordPress è dove puoi dimostrarlo.

Guarda cosa fa set_transient() quando crea un transiente. Se passi un tempo di scadenza, WordPress memorizza quel transiente con autoload impostato su false. Solo i transienti creati senza una data di scadenza vengono caricati automaticamente, e quelli sono la minoranza.

I transienti scaduti sono, per definizione, transienti che avevano una scadenza. Ciò significa che non sono mai stati caricati automaticamente. Puoi eliminarne cinquantamila, ridurre la tua tabella wp_options di cento megabyte e spostare il tuo numero di autoload quasi nulla.

Entrambe le pulizie valgono la pena. Una tabella wp_options enorme rallenta le query, gonfia i backup e fa fallire le migrazioni. È solo un problema diverso con una soluzione diversa, e confondere le due cose è il motivo per cui così tante persone pensano che il loro plugin di pulizia sia rotto.

Quindi cosa rimane una volta che i transienti sono spariti? Per esperienza, è quasi sempre uno di questi:

• Array di impostazioni serializzate da plugin che hai disinstallato. La maggior parte dei plugin non pulisce mai dopo se stessa alla cancellazione, e quelle impostazioni continuano a caricarsi per sempre.
• Dati di licenza e attivazione da plugin premium, inclusi quelli le cui licenze sono scadute anni fa.
• Risposte API memorizzate nella cache come semplici opzioni anziché come transienti appropriati, solitamente da plugin di feed social, analytics o SEO.
• Opzioni in stile log che crescono senza limiti, dove un plugin aggiunge a una singola riga di opzione ad ogni evento invece di usare la propria tabella.
• Transienti non scadenti, che sono la vera eccezione qui e l'unico tipo con cui una pulizia dei transienti aiuterà.

Nessuno di questi esce con uno strumento a clic singolo. Questa è la risposta onesta, ed è per questo che la sezione successiva è pratica.

Come si puliscono i dati di autoload di WordPress?

Non esiste un plugin che risolva questo problema con un clic. Cancellare le opzioni autoloaded significa identificare righe specifiche e decidere cosa fare con ciascuna.

Sembra peggio di quanto non sia. Sulla maggior parte dei siti, tre o quattro righe rappresentano la maggior parte del problema, quindi prendi tre o quattro decisioni invece di centinaia.

Ecco i tre metodi, ordinati dal più sicuro al più complesso:

• Disattiva autoload per opzioni pesanti: cambia un singolo valore di colonna senza cancellare nulla, ed è completamente reversibile.
• Cancella opzioni orfane da plugin rimossi: cancella permanentemente le righe lasciate da plugin che non ci sono più.
• Sostituisci il plugin che continua a scriverci: l'unica soluzione che regge quando qualcosa rigenera il bloat ad ogni esecuzione.

Fai un backup completo prima di iniziare uno qualsiasi di questi. Duplicator Pro crea una copia completa del tuo database e dei file in pochi minuti, e il suo ripristino con un clic significa che una cattiva istruzione UPDATE ti costa dieci minuti invece del tuo fine settimana.

Metodo 1: Disattiva l'autoload per le opzioni pesanti

Inizia da qui, perché non viene cancellato nulla. Stai cambiando un valore di colonna e puoi cambiarlo di nuovo.

Prendi la lista dei maggiori responsabili dalla tua query e lavoraci sopra. Per ogni opzione grande, la domanda è se il sito ha bisogno di quei dati ad ogni caricamento della pagina.

Prima di disabilitare l'autoload, verifica come e dove il plugin legge l'opzione. Alcuni array di configurazione sono legittimamente necessari nelle richieste front-end; altri sono solo per l'amministrazione o raramente acceduti e sono meglio caricati su richiesta.

Per interrompere l'autoload di un'opzione, aggiorna il suo valore autoload:

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

Su WordPress 6.6+, usa off. WordPress riconosce anche il valore legacy no come non-autoloaded, quindi rimane compatibile con le installazioni più vecchie.

WP-CLI lo gestisce in un comando e accetta on, off, yes o no:

wp option set-autoload your_option_name_here off

I dati rimangono esattamente dove sono. WordPress smette solo di caricarli a ogni richiesta e li recupera su richiesta quando qualcosa chiama get_option() invece.

Dopo ogni modifica, fai due cose: riesegui la query di dimensione per confermare che il numero sia diminuito e carica sia il tuo front end che wp-admin per confermare che nulla si sia rotto.

Non raggruppare venti modifiche e poi testare. Se qualcosa va storto, vuoi sapere quale riga l'ha causato.

Una cosa da tenere d'occhio: se un'opzione torna all'autoloading dopo un aggiornamento del plugin, quel plugin sta riscrivendo il valore all'attivazione o all'aggiornamento. La tua modifica non è fallita; è stata sovrascritta.

Ciò vale un ticket di supporto con gli sviluppatori del plugin, ed è un forte segnale che ti stai dirigendo verso il Metodo 3.

Metodo 2: Elimina le opzioni orfane dai plugin rimossi

L'eliminazione è permanente, quindi questo metodo richiede più attenzione dell'ultimo.

Lavora sulla tua lista dei principali responsabili e abbina ogni nome di opzione al plugin che l'ha creata. La maggior parte usa un prefisso riconoscibile, anche se non tutti sono ovvi.

Cerca il nome dell'opzione prima di toccarla, poiché un nome che sembra abbandonato a volte appartiene a qualcosa ancora in esecuzione.

Quindi conferma che il plugin sia effettivamente sparito.

Disattivato non significa sparito. Un plugin disattivato ha ancora i suoi file sul disco e riprenderà le sue impostazioni quando lo riattiverai, quindi eliminare le sue opzioni a metà disattivazione significa solo perdere la tua configurazione.

Prima di eliminare un'opzione, verifica di aver individuato la riga esatta che intendi rimuovere. Questa query di sola lettura mostra l'ID dell'opzione, il nome, lo stato attuale di autoload e la dimensione memorizzata senza modificare nulla:

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Una volta che sei sicuro, rimuovi la riga:

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Non eseguire mai un DELETE con un carattere jolly LIKE su questa tabella a meno che tu non abbia letto prima ogni riga che corrisponde. Un modello che sembra specifico può corrispondere a molto più di quanto ti aspetti, e wp_options è l'unica tabella in cui un errore blocca l'intero sito invece di rompere una singola funzionalità.

Quando non riesci a identificare affatto una riga, non eliminarla. Imposta il suo autoload su disattivato usando il Metodo 1 e lasciala lì.

Ottieni il pieno beneficio in termini di prestazioni, i dati sopravvivono e puoi annullarlo in pochi secondi se qualcosa dovesse richiederlo.

Questo è il punto in cui il backup smette di essere una formalità. Stai eliminando righe dalla tabella più importante del tuo database WordPress, e l'URL di ripristino di emergenza di Duplicator Pro ripristinerà il sito anche se una query errata ti blocca l'accesso a wp-admin.

Metodo 3: Sostituisci il plugin che continua a scriverci

Se la dimensione del tuo autoload risale sopra 1MB entro pochi giorni da una pulizia, smetti di pulire. Qualcosa sta scrivendo attivamente a ogni esecuzione e lo farai per sempre.

I soliti sospetti, basati su ciò che continuo a trovare:

• Plugin per slider e page builder che memorizzano enormi array di configurazione serializzati
• Plugin di analisi e statistiche che registrano su una riga di opzione invece che sulla propria tabella
• Plugin di sicurezza che conservano i log degli eventi come opzioni
• Gestori di reindirizzamento abbandonati, dove ogni regola di reindirizzamento vive in un'unica opzione in crescita
• Plugin per feed social che memorizzano nella cache le risposte delle API come semplici opzioni autoloaded

Trovare il colpevole è più facile di quanto sembri. Annota i tuoi principali responsabili, attendi qualche giorno, quindi riesegui la query. Qualunque cosa sia cresciuta è la tua risposta.

Sostituire un plugin su un sito live è dove questo diventa rischioso, ed è l'unica parte di questo processo che non farei mai prima in produzione.

Duplicator Pro ti consente di trasformare qualsiasi backup completo del sito in un sito di staging in pochi clic, senza un account di hosting separato o trasferimenti manuali di file.

Testa la sostituzione lì, conferma che il sito funzioni ancora e che la dimensione dell'autoload rimanga piatta, quindi apporta la modifica in produzione.

Come si impedisce il ritorno dei dati di autoload di WordPress?

La pulizia non è un lavoro una tantum, perché i dati di autoload di WordPress crescono come effetto collaterale della normale manutenzione del sito. Ogni plugin che provi lascia qualcosa indietro.

Alcune abitudini ti impediscono di perderne di nuovo il controllo:

• Controlla il tuo punteggio mensilmente, o dopo qualsiasi lotto di modifiche ai plugin. La dashboard di DB Optimizer rende questo un lavoro di dieci secondi, ma Site Health funziona bene se preferisci non aggiungere un plugin.
• Elimina i plugin correttamente invece di disattivarli. La disattivazione lascia ogni opzione al suo posto. L'eliminazione almeno dà a un plugin ben costruito la possibilità di pulire, anche se molti ancora non lo fanno.
• Controlla l'opzione prima di disinstallare. Se sai che un plugin lascia dati indietro, annota i nomi delle sue opzioni mentre è ancora installato e facile da identificare.
• Installa meno plugin. È il consiglio meno soddisfacente in questo elenco e il più efficace. Ogni plugin che non provi è un dato di autoload che non dovrai mai pulire.
• Mantieni un backup corrente in esecuzione su una pianificazione, in modo che la pulizia del database sia una decisione a basso rischio invece di una nervosa.
• Monitora Site Health piuttosto che aspettare che il sito diventi lento. Dal momento in cui noti il ritardo, di solito sei ben oltre i 2 MB.

Domande frequenti (FAQ)

I dati di autoload di WordPress sono un'abitudine di manutenzione, non una soluzione una tantum

Il bloat di autoload è il costo accumulato di ogni plugin che il tuo sito ha mai avuto. Vale la pena rifletterci, perché riformula il problema.

Non è un bug o un segno che hai fatto qualcosa di sbagliato. È il residuo ordinario della gestione di un sito WordPress per alcuni anni, e niente in WordPress lo pulisce per te.

Preferirei essere diretto riguardo al lavoro coinvolto. Modificare manualmente wp_options comporta rischi reali, gli strumenti disponibili misureranno il problema più prontamente di quanto lo risolveranno, e sarai di nuovo qui tra sei mesi se continuerai a installare plugin (cosa che farai).

Imposta un promemoria, controlla il numero trimestralmente e trattalo come qualsiasi altra attività di manutenzione.

Ecco un'altra cosa che vale la pena fare e che non ho ancora menzionato: controlla la dimensione del tuo autoload subito prima di una migrazione. È il modo più economico possibile per ridurre un archivio di backup e tagliare i tempi di importazione dall'altra parte.

Una tabella wp_options gonfia è una delle ragioni più comuni per cui un'importazione di database si blocca o va in timeout su un nuovo host, ed è veramente frustrante eseguire il debug di una migrazione fallita. Dieci minuti di pulizia prima di esportare salvano completamente questo problema.

Prima di toccare wp_options, assicurati che il tuo sito sia protetto

La pulizia dei dati di autoload significa eseguire istruzioni UPDATE e DELETE sulla tabella che può mettere offline l'intero sito. Un carattere jolly fuori posto in una query, e ti ritroverai con una schermata bianca senza modo di accedere a wp-admin per correggerla.

Duplicator Pro rende questo un errore recuperabile invece di un disastro. Fai un backup completo prima di iniziare e ripristina in pochi minuti con un clic se qualcosa va storto.

Il suo URL di disaster recovery riporta un sito online anche quando WordPress è completamente bloccato, che è esattamente lo scenario che una query di database errata crea. Provalo oggi stesso!

Se questo post ti ha fatto pensare a cos'altro si trova nel tuo database, queste guide valgono la pena di essere lette successivamente.

• Come eliminare tutte le transizioni in WordPress (4 metodi)
• Come ottimizzare il tuo database WordPress: Ottieni un sito veloce in 10 passaggi
• Pulizia del database di WordPress: una guida per principianti alla rimozione della spazzatura
• 7 segnali di avvertimento del database di WordPress che la maggior parte dei proprietari di siti perde
• Come riparare un database WordPress lento: una checklist in 4 passaggi
• Manutenzione del database di WordPress: Cosa fare settimanalmente, mensilmente e trimestralmente