Entras en Herramientas > Salud del sitio y WordPress te muestra un aviso bastante inquietante:
“Autoloaded options could affect performance”
Debajo aparece algo parecido a esto:
Tu sitio tiene cientos de opciones cargadas automáticamente y ocupan varios cientos de KB o incluso varios MB.
A partir de ahí es fácil acabar buscando en Google cómo limpiar wp_options, instalar un optimizador de base de datos o entrar en phpMyAdmin para cambiar valores de autoload.
No empieces por ahí.
La alerta señala un posible problema de rendimiento, pero no identifica por sí sola qué opción sobra, qué plugin es responsable ni cuánto está afectando realmente a la velocidad de tu web.
Y cambiar indiscriminadamente opciones de autoload puede empeorar el rendimiento o provocar que alguna funcionalidad deje de comportarse como esperaba su desarrollador.
Lo correcto es diagnosticar primero.
WordPress almacena muchos ajustes en la tabla wp_options de su base de datos.
Ahí pueden encontrarse configuraciones de:
Algunas de esas opciones son necesarias constantemente.
En lugar de realizar una consulta independiente a la base de datos cada vez que necesita una, WordPress puede cargar determinadas opciones conjuntamente al comenzar una petición.
Ese mecanismo es el autoload.
Tiene sentido para valores que se necesitan prácticamente siempre. El problema aparece cuando se cargan automáticamente grandes cantidades de información que rara vez se utilizan.
La documentación de desarrollo de WordPress explica precisamente que cargar automáticamente información innecesaria puede perjudicar el rendimiento.
Por tanto, el autoload no es algo malo que debamos eliminar.
Es una optimización que deja de ser eficiente cuando contiene demasiados datos innecesarios.
Desde WordPress 6.6, Salud del sitio incluye una comprobación específica de las opciones cargadas automáticamente.
WordPress calcula el tamaño total y, si alcanza el límite establecido, muestra el aviso:
“Autoloaded options could affect performance”.
El umbral predeterminado es actualmente:
800.000 bytes, aproximadamente 800 KB.
Ese valor está definido en el propio núcleo y puede modificarse mediante un filtro, aunque cambiar el límite para que desaparezca el aviso no corrige ninguna causa subyacente.
Hay aquí una distinción importante.
WordPress no está diciendo:
«Tu web es lenta porque tienes más de 800 KB de autoload».
Está diciendo, en esencia:
«La cantidad de información cargada automáticamente ha alcanzado un nivel que merece ser revisado».
Son afirmaciones diferentes.
No necesariamente.
El límite de Salud del sitio funciona como señal de advertencia, no como diagnóstico individual del rendimiento de cada instalación.
Dos webs con un volumen similar de opciones autoload pueden comportarse de forma distinta dependiendo de:
Además, importa mucho qué contienen esos datos.
Una instalación podría superar el límite porque conserva configuraciones antiguas de plugins eliminados.
Otra podría hacerlo porque un plugin activo necesita legítimamente una opción relativamente grande en casi todas las peticiones.
Tratar ambas situaciones igual sería un error.
En los propios foros de soporte aparecen casos con 800 KB, 1 MB, 3 MB o más, acompañados siempre de la misma duda: qué se puede borrar o desactivar sin romper nada.
La cifra te indica dónde mirar.
No te dice todavía qué debes eliminar.
Puedes encontrar una instalación con 1.000 opciones pequeñas y otra con muchas menos pero con varios registros enormes.
La segunda puede cargar bastante más información.
Por tanto, saber que WordPress tiene:
1.200 opciones autoload
es menos útil que averiguar:
Esto último es la clave.
No necesitas revisar una por una todas las filas de wp_options.
Empieza por las opciones autoload que más espacio ocupan.
Si tienes acceso a la base de datos y sabes trabajar con SQL, puedes obtener una primera fotografía del problema.
Pero hay una precaución importante desde WordPress 6.6: ya no debes asumir que autoload contiene únicamente yes o no.
El núcleo reconoce actualmente varios valores relacionados con autoload, entre ellos:
yes;on;auto-on;auto;como valores que implican carga automática.
Esto importa porque muchas consultas SQL antiguas que circulan por Internet siguen buscando exclusivamente:
autoload = 'yes'
y pueden proporcionar una imagen incompleta en instalaciones modernas.
Este detalle explica parte de la confusión actual.
Tradicionalmente, las opciones almacenaban principalmente valores yes o no.
Desde WordPress 6.6 existen valores más granulares:
on;off;auto;auto-on;auto-off;mientras que yes y no siguen siendo compatibles por razones históricas.
Además, WordPress puede decidir automáticamente no cargar ciertas opciones grandes cuando el desarrollador no ha especificado explícitamente que deban cargarse.
El límite utilizado para esa decisión automática es diferente del aviso de Salud del sitio.
Por defecto, una opción individual superior a 150.000 bytes puede dejar de configurarse para autoload automáticamente si quien la guarda no ha solicitado explícitamente lo contrario.
Por tanto, existen dos cifras diferentes que no debemos confundir:
Aquí suele empezar el trabajo realmente útil.
Imagina que descubres que una opción ocupa 300 KB.
La pregunta no debería ser:
«¿La pongo en autoload = off?»
Debería ser:
«¿Qué componente ha creado esto y para qué lo necesita?»
El nombre de la opción puede dar pistas.
A menudo contiene:
Busca primero dentro de la propia instalación.
Comprueba:
Los foros de WordPress muestran precisamente casos en los que una única opción de un plugin suponía una parte significativa del volumen autoload y el propio desarrollador tenía que aclarar si era necesaria.
Este es uno de los casos más interesantes.
Desinstalar un plugin no siempre implica eliminar toda la información que almacenó.
Algunos conservan datos intencionadamente por si vuelves a instalarlos.
Otros dejan residuos porque su proceso de desinstalación no elimina todas sus opciones.
Por eso puedes encontrarte con una instalación que carga automáticamente información perteneciente a plugins que dejaron de utilizarse hace meses o años.
En ese escenario tiene bastante sentido investigar si esos registros pueden eliminarse.
Pero primero debes confirmar su procedencia.
No borres una opción solo porque no reconoces su nombre.
Si una opción pertenece a un plugin activo, hay que ser bastante más prudente.
Que sea grande no significa necesariamente que esté mal diseñada.
Puede contener datos que el plugin necesita constantemente.
Cambiar su comportamiento de autoload podría hacer que WordPress tuviese que consultar la base de datos individualmente cada vez que esa opción sea solicitada.
Es decir:
desactivar autoload también tiene un coste.
El objetivo no es conseguir el menor número posible en Salud del sitio.
El objetivo es evitar cargar continuamente información que no hace falta.
La distinción es importante porque existen usuarios que han cambiado multitud de registros a autoload = no buscando mejorar WordPress sin comprobar después si realmente habían ganado rendimiento. En los foros oficiales también se advierte que dejar de cargar automáticamente opciones utilizadas con frecuencia puede incluso perjudicarlo.
autoload=yes a noEs probablemente la peor interpretación posible de esta alerta.
Encontrar una columna llamada autoload y cambiar:
yes → no
parece una optimización sencilla.
Pero no sabes qué espera hacer después cada plugin.
Entre las opciones de WordPress pueden encontrarse datos fundamentales para su funcionamiento.
Modificar indiscriminadamente la tabla puede provocar comportamientos inesperados o simplemente sustituir una carga eficiente en bloque por múltiples consultas individuales.
Además, como hemos visto, en WordPress moderno el esquema ya no se limita a yes y no.
La propia documentación del núcleo distingue entre opciones que deben cargarse siempre, opciones que no deben hacerlo y otras cuyo comportamiento puede determinar WordPress automáticamente.
La pregunta correcta es siempre:
¿esta opción necesita estar disponible en prácticamente todas las peticiones?
Si no puedes responderla, todavía no tienes suficiente información para modificarla.
Nombres extraños, hashes, prefijos desconocidos o valores serializados no significan que un registro sea basura.
Puede pertenecer a:
Y un dato serializado puede contener una estructura completa de configuración.
Por eso las limpiezas automáticas agresivas de wp_options merecen especial precaución.
En cómo limpiar la base de datos de WordPress sin tocar código explicamos una idea que aquí resulta especialmente importante: base de datos grande y base de datos problemática no son sinónimos.
Puede contribuir.
Pero no deberías atribuirle automáticamente cualquier problema de velocidad.
Las opciones autoload intervienen en las peticiones de WordPress y un volumen excesivo de información innecesaria puede aumentar el trabajo que debe realizar la aplicación.
WordPress introdujo precisamente estos cambios para reducir situaciones en las que grandes cantidades de información autoload se convertían en un cuello de botella.
Ahora bien, una web lenta también puede deberse a:
Por eso conviene medir antes y después.
Si tu problema está especialmente concentrado en el área de administración, consulta también qué comprobar cuando wp-admin es muy lento aunque la web pública funcione bien.
No te quedes con la alerta.
Busca varias señales que apunten en la misma dirección.
Por ejemplo:
wp_options costosas;Lo último es especialmente importante.
Si reduces considerablemente el autoload pero los tiempos permanecen prácticamente iguales, quizá acabas de descubrir que el principal cuello de botella estaba en otro sitio.
Eso también es un resultado útil.
Sí, pero no convierte el autoload en irrelevante.
Una caché persistente de objetos como Redis puede reducir muchas consultas repetidas a la base de datos.
Sin embargo, eso no significa que tenga sentido cargar indiscriminadamente información que una petición no necesita.
El problema conceptual sigue siendo el mismo:
datos cargados en todas las peticiones que apenas se utilizan.
Además, el comportamiento y beneficio real dependen de la arquitectura completa de la instalación.
No utilizaría Redis como excusa para ignorar una acumulación claramente anormal de opciones.
Ni instalaría Redis únicamente para hacer desaparecer las consecuencias de una tabla wp_options mal mantenida.
Puede ayudar a identificar o retirar residuos concretos.
Pero hay que distinguir dos funciones:
detectar y decidir.
Una herramienta puede mostrarte que determinada opción ocupa 400 KB.
Eso es un dato.
No significa automáticamente que la herramienta pueda determinar si tu web necesita esa opción.
El conocimiento importante sigue siendo:
Por eso tampoco resolvería este problema instalando sucesivamente varios plugins de optimización.
De hecho, cada plugin adicional puede incorporar sus propias opciones y aumentar la complejidad que estás intentando reducir.
Si tu instalación ya acumula muchas extensiones, puede ser buen momento para revisar cuántos plugins conviene realmente tener en WordPress y cuándo empiezan a convertirse en un problema.
Seguiría este orden.
No cambies nada todavía.
Guarda:
Necesitarás esos datos para comprobar posteriormente si realmente has mejorado algo.
No revises cientos de registros al azar.
Empieza por los que concentran mayor tamaño.
Relaciona cada uno con:
Una opción perteneciente a un plugin eliminado merece una investigación distinta de otra perteneciente al sistema de pagos activo de WooCommerce.
Especialmente cuando el plugin sigue funcionando.
Antes de modificar directamente wp_options, debes poder recuperar el estado anterior.
Y no basta con asumir que «hay copias».
Conviene saber que realmente pueden restaurarse. Lo explicamos en copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan.
Si modificas veinte opciones simultáneamente y aparece un problema, habrás dificultado innecesariamente encontrar su causa.
Comprueba:
El objetivo no es simplemente conseguir que desaparezca la alerta.
Es mejorar la instalación sin introducir nuevos problemas.
Supongamos que una sola opción representa 300 KB o 400 KB.
Antes de tocarla:
Puede que la solución correcta sea modificar autoload.
Pero también podría ser:
En un caso recogido en el soporte oficial, por ejemplo, una opción de depuración de un plugin ocupaba unos 125 KB; posteriormente el desarrollador eliminó ese código en una actualización.
La solución importante no fue «poner todo a no».
Fue localizar qué estaba generando el dato.
Este escenario puede ofrecer una limpieza bastante más clara.
Aun así:
En instalaciones antiguas, esta revisión puede descubrir años de restos acumulados.
Es una de las razones por las que un mantenimiento WordPress útil va más allá de instalar actualizaciones: también debe detectar dependencias, residuos y procesos que se han ido acumulando con el tiempo.
Salud del sitio es una herramienta de diagnóstico.
No es una puntuación.
Puede avisarte de un problema importante, pero el objetivo no debería ser conseguir que todas sus comprobaciones aparezcan en verde a cualquier precio.
Cambiar el límite de 800.000 bytes para que desaparezca la advertencia es técnicamente posible porque WordPress proporciona un filtro específico para modificarlo.
Pero eso solo cambia cuándo aparece el mensaje.
No reduce el tamaño de los datos ni mejora automáticamente el rendimiento.
Es el equivalente técnico a bajar el volumen de una alarma sin comprobar qué la ha activado.
Cuando WordPress muestra “Autoloaded options could affect performance”, hay tres preguntas mejores:
¿Qué información se está cargando automáticamente?
¿Quién la necesita?
¿Tiene sentido cargarla en prácticamente todas las peticiones?
Solo después deberías decidir entre:
El tamaño de wp_options es una pista.
El número de opciones es otra.
La alerta de Salud del sitio también.
Pero ninguna sustituye al diagnóstico.
Y precisamente ahí está la diferencia entre limpiar una base de datos y optimizar realmente una instalación WordPress.
