WordPress
y el autoload inflado

Audita tus datos en autoload: dos consultas

Pégalas en phpMyAdmin, Adminer o wp db query: la primera te da el tamaño total de autoload en KB, la segunda lista las 25 opciones que realmente lo provocan. Ajusta el prefijo wp_ si el tuyo es distinto.

-- Total autoloaded data (KB) + row count
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb,
       COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

-- Top 25 offenders, biggest first
SELECT option_name,
       ROUND(LENGTH(option_value) / 1024, 1) AS size_kb,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 25;

El autoloader de WordPress frente a los datos en autoload

"Autoloader" significa dos cosas sin relación en WordPress, y buscarlo devuelve las dos. Merece treinta segundos comprobar cuál tienes.

Si has llegado aquí porque tu hosting marcó "autoloaded data", o tras ver alloptions en un profiler, quieres la segunda. Si estás depurando un fatal de Class not found, quieres la primera, y esta página no te va a ayudar: eso es un problema de Composer o PSR-4.

La expresión "plugin autoloader" es ambigua de la misma forma. Un plugin trae un autoloader de Composer para sus propias clases, y además escribe opciones en autoload. Solo lo segundo aparece en la consulta de abajo.

¿Qué son los datos en autoload?

WordPress tiene una única consulta que se ejecuta en cada carga de página, antes de que se ejecute el código de ningún tema o plugin:

SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes'

Esto carga de golpe en memoria todas las opciones marcadas como "autoload". El núcleo de WordPress necesita unos 100 KB de estos datos. El problema es que los plugins abusan.

A diferencia de las consultas lentas, que disparan tu TTFB de forma intermitente, el autoload inflado es un impuesto constante. Añade latencia a absolutamente cada petición—cacheada o no, frontend o admin, AJAX o carga de página.

Aviso de "Autoloaded Data" de WP Engine: qué hacer

WP Engine marca los datos en autoload en cuanto pasan de 800 KB y considera normal cualquier cifra por debajo. Es uno de los pocos hostings que lo muestra como aviso en el panel, y por eso la mayoría de la gente conoce el problema a través de ellos. La física es la misma con cualquier proveedor: cada petición mete el conjunto entero en PHP, estés donde estés.

El aviso te da un número y nada más. Esto es lo que hacer con él.

1. Mídelo tú primero. Ejecuta la consulta de auditoría del principio de esta página. Los paneles de hosting muestrean cada cierto tiempo, así que el número que ves puede tener horas, y algunos paneles siguen comprobando autoload = 'yes', lo que subestima en WordPress 6.6+ porque el núcleo ahora también escribe 'on', 'auto' y 'auto-on'. Que un panel diga "dentro de lo normal" no es una prueba.
2. Busca a los culpables, no el total. El total es un síntoma. Lista las 25 filas más grandes por LENGTH(option_value) y normalmente encontrarás tres o cuatro filas que cargan con casi todo el peso.
3. Comprueba cada una contra la lista de "no tocar" que hay más abajo en esta página antes de cambiar nada. Algunas opciones grandes en autoload tienen que ser grandes.
4. Quita el autoload, no borres. wp option set-autoload OPTION_NAME off deja los datos intactos y es reversible. Borrar filas es la forma de cargarte los ajustes de un plugin.
5. Vuelve a medir y dale tiempo al panel. El aviso desaparece en la siguiente comprobación de WP Engine, no al instante.

Una advertencia específica de los hostings gestionados con memcached: por encima de aproximadamente 1 MB el blob de autoload puede superar el límite por clave, así que falla al cachearse en silencio y cada petición vuelve a la base de datos. Eso es peor de lo que sugiere el aviso, y aparece como 502 aleatorios en wp-admin en lugar de como una página lenta.

Bajar de 800 KB a mano son un par de horas de trabajo cuidadoso. el Autoloader Optimizer de WP Multitool hace la misma auditoría, clasifica cada fila y desactiva las seguras con una restauración de un clic por detrás.

Qué provoca el autoload inflado en WordPress

1. Restos de plugins desactivados

La mayoría de plugins no recogen lo suyo. Añaden opciones al activarse y las dejan para siempre—incluso tras desactivarlos y borrarlos. Encuéntralas:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Busca nombres de opciones de plugins que ya no uses. Es seguro ponerlas en autoload='no' o borrarlas del todo.

2. Arrays serializados que crecen

Algunos plugins guardan datos que crecen en una sola opción: registros, instantáneas de analítica, programaciones de cron. Un único option_value puede ser 500 KB o más de PHP serializado.

3. Transients caducados

Los transients son valores temporales en caché guardados en wp_options. Sin una caché de objetos externa, los transients caducados se acumulan. WordPress solo los limpia de forma perezosa—cuando se accede a ellos la próxima vez. Estos transients rancios también pueden aparecer como consultas lentas cuando la tabla crece lo suficiente.

SELECT COUNT(*) FROM wp_options
WHERE option_name LIKE '_transient_%'
AND autoload = 'yes';

4. Plugins mal configurados

Plugins que guardan ajustes por usuario, configuraciones JSON grandes o respuestas de API cacheadas en opciones con autoload. Puede que esos datos hagan falta, pero no hace falta cargarlos en cada petición.

Lo que NO hay que desactivar

Cambiar el autoload es reversible. Borrar filas no. Pero algunas opciones tienen que seguir en autoload mientras su dueño esté activo, o WordPress y tus plugins se rompen al principio del arranque, y no dará un error: simplemente se degradará en silencio. Usa esto como comprobación antes de cualquier cambio masivo.

La regla: si el plugin está activo y la opción es configuración que lee en cada petición, deja el autoload puesto. Si el plugin ya no está, o el valor es una caché, un registro o un blob de cola, quita primero el autoload, y bórralo solo cuando hayas confirmado que nadie sigue leyendo esa fila.

Culpables habituales del autoload: ¿es seguro desactivarlo?

Veinte prefijos que veo una y otra vez, y qué hago con cada uno. "Cuidado" significa que la respuesta depende de si el plugin sigue activo: comprueba eso primero.

Cómo arreglar el autoload inflado en WordPress

Desactivar el autoload en opciones concretas

UPDATE wp_options SET autoload = 'no'
WHERE option_name = 'old_plugin_settings';

Limpiar los transients caducados

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Borrar datos huérfanos de plugins

-- Only after confirming the plugin is gone:
DELETE FROM wp_options
WHERE option_name LIKE 'removed_plugin_%';

El problema de los arreglos manuales: no se quedan arreglados. Los plugins siguen añadiendo datos. Los transients se vuelven a acumular. Los plugins nuevos traen opciones nuevas en autoload. Tendrías que auditar cada mes para tenerlo bajo control.