Autoload en wp_options: el freno oculto de tu WordPress

Cuando un WordPress va lento, casi todos miramos las imágenes o los plugins. Pero hay un culpable silencioso que casi nadie revisa: la tabla wp_options y sus opciones con autoload. Si tu sitio dedica tiempo de más a cada petición antes de responder, aquí puede estar el problema, incluso antes de que la caché entre en juego.

Qué es el autoload y por qué importa

WordPress guarda ajustes del sitio, de plugins y de temas en la tabla wp_options. Cada fila tiene una columna autoload. Las filas marcadas como yes se cargan en cada petición de PHP, se vayan a usar o no, en una sola consulta al inicio.

Esto es cómodo para ajustes pequeños (nombre del sitio, URL, permalinks). El problema aparece cuando plugins que ya desinstalaste, o que guardan grandes cantidades de datos (logs, resultados de escaneos, transients mal gestionados, configuraciones serializadas enormes), dejan megabytes marcados como autoload.

Cómo se manifiesta

• Un TTFB alto en páginas que no están en caché: el panel de administración, el carrito, el checkout, páginas con usuarios logueados.
• Consumo de memoria PHP elevado en peticiones simples.
• Regeneraciones de caché más lentas de lo normal, porque cada una arranca WordPress completo.

Cómo medir tu caso

No hace falta adivinar. Con acceso a la base de datos (phpMyAdmin, Adminer o WP-CLI) puedes ver cuánto pesa el autoload:

• Suma el tamaño de las filas con autoload = 'yes' usando SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; (ajusta el prefijo de tablas si no es wp_).
• Lista las diez opciones más grandes con SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY bytes DESC LIMIT 10;
• En el sitio, el plugin Site Health de WordPress también puede avisar cuando las opciones autoload son excesivas en versiones recientes del core.

Como regla práctica, si el total se cuenta en varios megabytes, vale la pena investigar. Si son unos cientos de kilobytes, probablemente tu cuello de botella esté en otro lado.

Cómo limpiarlo sin romper nada

1. Haz una copia de seguridad de la base de datos antes de tocar nada.
2. Identifica el dueño de cada opción grande: el prefijo del nombre suele delatar el plugin.
3. Si el plugin ya no existe, borra sus opciones huérfanas.
4. Si el plugin sigue activo y la opción rara vez se lee, cámbiala a autoload = 'no' en lugar de borrarla; WordPress la leerá bajo demanda.
5. Elimina transients caducados que se hayan quedado acumulados.
6. Vuelve a medir el tiempo de respuesta y compáralo con el punto de partida.

Qué no hacer

• No borres opciones cuyo origen desconoces solo porque son grandes.
• No cambies a no opciones del core (siteurl, active_plugins, etc.).
• No lo hagas en producción sin probar antes en un staging si el sitio es una tienda.

Y la caché, ¿no lo soluciona?

En parte. Una caché de página que sirve HTML estático evita ejecutar PHP y consultar la base de datos para los visitantes anónimos, así que ese problema desaparece para la mayoría del tráfico. Puedes ver el mecanismo en cómo funciona cache.lat: la página se genera una vez y después se entrega como archivo.

Pero hay dos momentos en los que la base de datos sigue importando: cuando se regenera una página (tras publicar o purgar) y en todo lo dinámico que no puede cachearse (administración, carrito, cuentas de usuario). Una base de datos limpia hace que ambos sean más ágiles. Si quieres entender qué se sirve estático y qué no, revisa los datos técnicos y la documentación.

Checklist rápido

• Mide el peso total del autoload.
• Revisa las diez opciones más grandes.
• Elimina restos de plugins desinstalados.
• Pasa a no lo que no se necesita en cada petición.
• Limpia transients caducados.
• Compara TTFB antes y después, tanto con caché como sin ella.

Hacer este mantenimiento una vez cada pocos meses cuesta poco y evita que la base de datos se convierta en un lastre invisible. Si tienes dudas sobre cómo encaja con tu configuración, puedes contactar al equipo de TuNegocioEnLinea.net.