Las autoload options pueden hacer que WordPress cargue más datos de los necesarios en cada petición. Cuando se acumulan opciones pesadas o demasiadas entradas en wp_options, la web se ralentiza y puede aparecer el aviso de rendimiento en Site Health.
Las autoload options son opciones de WordPress que se cargan en cada visita al sitio; si hay demasiadas o demasiado pesadas, pueden ralentizar la web y activar avisos en Site Health. La clave no es borrar por borrar, sino auditar qué se carga, detectar transients y opciones huérfanas, y limpiar solo lo seguro con criterios claros.
Responde al aviso sin romper nada
Las autoload options forman parte de la tabla wp_options, que es como el cajón donde WordPress guarda ajustes de plugins, tema y del propio sistema. Cuando ese cajón se llena de cosas pesadas, cada visita tarda más en abrirlo.
El aviso de Site Health suele ser una señal de exceso o desorden, pero no dice qué opción concreta hay que borrar. Lo más sensato es medir primero el tamaño, revisar qué opciones se cargan siempre y dejar intacto lo que WordPress necesita para arrancar bien.
Qué significa el aviso de Site Health
El aviso de Site Health sobre opciones cargadas automáticamente suele apuntar a una carga excesiva en la base de datos MySQL. Piensa en ello como llevar siempre la mochila llena, aunque solo vayas a comprar pan.
Ese aviso no identifica culpables por nombre. Solo te dice que WordPress está cargando demasiado al inicio, y eso puede venir de plugins, del tema o de restos de instalaciones antiguas.
Si el sitio responde bien y el aviso aparece con una carga pequeña, quizá no sea prioridad. Pero si ya notas lentitud, el aviso sí merece revisión inmediata.
Cuándo hay impacto real
El impacto real aparece cuando la carga de autoload sube por tamaño, por cantidad o por opciones mal guardadas. Una cifra orientativa útil es revisar con más cuidado cuando el total ronda entre 800 KB y 1 MB, y actuar con urgencia si supera varios MB.
La mayoría de guías dicen que cualquier valor alto es malo. Lo que no mencionan es que una sola opción necesaria y grande puede ser correcta, mientras que veinte opciones pequeñas y duplicadas pueden ser peor.
Un sitio con pocos plugins puede ir bien con un autoload moderado, pero una tienda con constructor visual, analítica y reservas suele cargar más cosas. Por eso el contexto manda más que el número aislado.
Qué no debes borrar aún
No borres todavía opciones con nombre desconocido solo porque ocupan mucho. Primero hay que saber si son datos de sesión, ajustes del tema, caché interna o registros temporales.
Tampoco conviene tocar tablas desde phpMyAdmin sin copia previa. El error más frecuente aquí es borrar algo que parece basura y romper luego el login, el carrito o la personalización del tema.
Si el aviso de rendimiento existe, el orden correcto es medir, listar, clasificar y solo después limpiar. Eso ahorra tiempo y evita sustos.
Por qué cargan WordPress y MySQL
WordPress usa autoload para cargar al arrancar las opciones que necesita en casi cada página. Es como preparar antes la mesa con lo que vas a usar seguro, para no levantarte después a buscarlo.
La base de datos MySQL guarda esas opciones en wp_options. Cuando hay muchas entradas marcadas para carga automática, la consulta inicial crece y el servidor tarda más en responder.
Esto afecta al rendimiento web porque cada visita hace ese trabajo de arranque. Si la web recibe mucho tráfico, el coste se multiplica.
Cómo funciona autoload en wp_options
Cada fila de wp_options puede tener una marca de autoload, que suele ser yes o no. Las que están en yes se cargan casi siempre al inicio.
Eso no es un fallo. Es una función normal de WordPress para evitar consultas extra en cada clic.
El problema aparece cuando plugins o temas guardan demasiado ahí. Entonces lo que debía ser rápido se convierte en una maleta llena de ladrillos.
Qué hace la base de datos MySQL
MySQL lee esas opciones antes de mostrar la página. Si el conjunto pesa poco, el proceso apenas se nota. Si pesa mucho, el arranque se alarga.
Un dato práctico: en revisiones de mantenimiento suele considerarse razonable que el conjunto autoload se mantenga por debajo de 1 MB en webs pequeñas o medianas, aunque hay sitios con más carga que toleran algo más.
Cómo afectan plugins y temas
Cada plugin decide qué guarda y cómo lo guarda. Algunos guardan bien, pero otros acumulan revisiones, caché interna o datos de prueba.
Los temas también pueden inflar la tabla con ajustes del personalizador, tipografías, colores o bloques de configuración. Si cambiaste varias veces de tema, pueden quedar restos.
La clave técnica es esta: autoload no es el problema por sí mismo. El problema es cargar en cada visita datos que no hacen falta para arrancar la web.
Si WordPress tarda más en empezar que en servir la página, el cuello de botella suele estar en wp_options, en consultas lentas o en ambos.
Qué opciones conviene revisar primero
Empieza por las opciones grandes, repetidas o ligadas a plugins ya desinstalados. Ese orden reduce riesgos y da resultados rápidos.
La mayoría de guías se quedan en "borra lo que no uses". Lo que no mencionan es que una opción huérfana puede parecer útil por el nombre, aunque ya no haga nada porque el plugin se fue hace meses.
Umbrales prácticos de tamaño
Si el autoload total está entre 500 KB y 800 KB, conviene vigilarlo. Si ronda entre 800 KB y 1 MB, ya merece revisión. Si supera 1 MB en una web normal, hay motivos para actuar.
Esos rangos no son una ley, pero sí un buen semáforo. Como en una mochila, no pesa igual una libreta que una piedra.
Opciones grandes y repetidas
Busca opciones que ocupan mucho y aparecen varias veces por cambios de plugin, pruebas o migraciones. Suelen ser cadenas serializadas, que son datos guardados en bloque, como una caja cerrada con varios objetos dentro.
El error más común es tocar la primera opción grande que aparece sin mirar si es crítica. Hay opciones de caché, de maquetación o de comercio que sí deben seguir cargando al inicio.
Transients y datos temporales
Los transients son datos temporales, como una nota con fecha de caducidad. Sirven para guardar resultados que no hace falta recalcular cada vez.
Algunos transients expirados se quedan dentro de wp_options si la limpieza automática falla. Eso infla la tabla sin aportar valor real al rendimiento.
Opciones huérfanas de desinstalados
Las opciones huérfanas son datos que dejó un plugin o tema ya desinstalado. Es como encontrar llaves de una casa que ya no existe.
No siempre son peligrosas, pero sí ocupan sitio y pueden confundir la revisión. Si el nombre apunta a un plugin que ya no está, sube mucho la sospecha.
Una opción huérfana no siempre rompe nada, pero una opción crítica borrada sí puede dejar un sitio sin diseño, sin sesión o sin acceso al panel.
Para decidir si una opción debe seguir en autoload, piensa en tres preguntas: ¿se necesita en casi cada carga de la web?, ¿es pequeña o al menos razonable en tamaño?, ¿su ausencia rompería algo visible al instante? Las opciones de identidad del sitio, ajustes básicos del tema o configuraciones que WordPress necesita para arrancar suelen quedarse en autoload = yes. En cambio, datos de logs, métricas, cachés internas, paneles de analítica o preferencias que solo usa el administrador no deberían cargarse en cada consulta inicial.
Un buen criterio práctico es dejar en autoload solo lo que evita consultas repetidas y aporta valor real al frontend; todo lo demás debería revisarse, sobre todo si el rendimiento de WordPress ya muestra lentitud web.
Cómo auditar autoload sin arriesgar el sitio
Haz una copia de seguridad antes de tocar la base de datos. Esa es la red de seguridad, igual que bajar del coche el freno de mano antes de cambiar una rueda.
La revisión correcta combina una consulta SQL de solo lectura, una lista corta de sospechosos y una comprobación posterior en el frontal y en el panel. Este paso suele llevar entre 15 y 30 minutos si la web no tiene demasiados plugins.
Consultas SQL seguras para revisar
Usa primero consultas que solo lean datos. No actualices nada en esta fase.
Ejemplo seguro para listar las opciones autoload más pesadas:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;
Si usas prefijo distinto de wp_, cambia la tabla por el prefijo real. Parece obvio, pero ese fallo frena a mucha gente en el primer intento.
Matriz de decisión: mantener o quitar
La decisión debe basarse en función, tamaño y origen. No en corazonadas.
| Criterio |
Mantener |
Revisar |
Quitar |
| Uso en cada carga |
Sí |
A veces |
No |
| Origen conocido |
WordPress o plugin activo |
Plugin dudoso o antiguo |
Plugin desinstalado confirmado |
| Riesgo al borrar |
Alto |
Medio |
Bajo |
Qué validar antes de cambiar
Antes de tocar una fila, revisa si el plugin está activo, si la opción tiene nombre claro y si el valor parece una configuración normal o un resto temporal.
Después del cambio, comprueba inicio de sesión, formularios, carrito y caché. Son los puntos donde antes se nota un daño real.
Qué medir después de limpiar
Mide el tamaño total de autoload antes y después. Un descenso de entre 20% y 50% ya suele notarse en paneles y páginas con tráfico medio.
También revisa el tiempo de respuesta inicial. No hace falta una suite compleja para ver si la web abre con más soltura.
Cuando auditas wp_options, conviene trabajar con una secuencia segura: localizar las opciones más pesadas, comprobar su origen y después verificar si siguen activas antes de borrar nada. Una consulta útil es filtrar por autoload = 'yes' y ordenar por tamaño para ver primero las candidatas más problemáticas. Después puedes cruzar el nombre de la opción con el plugin o tema responsable y confirmar si aún está instalado.
Si una opción pertenece a un plugin desinstalado, a una prueba antigua o a un tema sustituido, es una buena candidata para limpieza segura; si pertenece a un plugin activo, primero hay que entender si guarda ajustes críticos o solo datos temporales.
Cómo limpiar sin romper plugins ni tema
Primero crea una copia completa de archivos y base de datos. Si puedes, trabaja en staging, que es una copia del sitio para hacer pruebas sin tocar la web real.
Después, elimina solo lo que has confirmado como seguro. Ese orden evita que una limpieza rápida se convierta en una caída de formulario, acceso o checkout.
Copia de seguridad y staging
La copia debe incluir base de datos y archivos. Sin las dos partes, la restauración puede quedarse a medias.
En staging puedes probar consultas y verificaciones sin riesgo. Es la forma correcta cuando el sitio da ingresos o atiende clientes.
Eliminar solo lo confirmado
Borra únicamente transients expirados, restos huérfanos o opciones de plugins ya desinstalados que hayas identificado con claridad.
No hagas una eliminación masiva de todas las filas con autoload='yes'. Eso es como vaciar una caja sin mirar lo que hay dentro.
Revisar login, checkout y formularios
El login comprueba si el sistema sigue leyendo bien sus opciones básicas. El checkout y los formularios dicen si un plugin crítico perdió datos.
Prueba una navegación completa, desde portada hasta una acción real. Eso vale más que mirar solo la home.
Objetos en caché y regeneración
Al limpiar autoload, la caché puede quedarse con datos viejos. Vaciarla ayuda a ver el efecto real y evita diagnósticos falsos.
Algunos plugins regeneran datos al primer acceso después de limpiar. Eso es normal y puede hacer que la primera carga sea un poco más lenta.
Casos de plugins populares
Plugins de formularios, maquetadores visuales, comercio electrónico y caché suelen concentrar opciones importantes. Ahí conviene más revisar que borrar.
Un plugin de caché bien configurado suele guardar poco en autoload, pero un plugin de pruebas o analítica puede dejar residuos si se desactiva mal.
Esto no funciona como prioridad si el sitio es pequeño, el aviso de Site Health no existe y el rendimiento no muestra síntomas. Tampoco si el problema principal está en el hosting, en la caché, en imágenes pesadas o en consultas lentas fuera de wp_options.
En casos reales, muchas opciones huérfanas no aparecen como algo obvio, sino como prefijos de plugins de formularios, maquetadores, comercio electrónico o constructores visuales que ya no se usan. También es frecuente encontrar restos de tema tras cambiar varias veces de diseño: tipografías, colores del personalizador, plantillas o ajustes serializados que quedaron en la tabla wp_options. Si el sitio usa transients, algunos pueden seguir almacenados aunque hayan caducado, inflando la base de datos MySQL sin mejorar nada.
La forma segura de actuar es confirmar si el plugin o tema sigue activo, revisar si la opción se regenera sola y, solo entonces, eliminar lo que sea claramente residual. Así evitas borrar configuraciones vivas que aún afectan al frontend o al panel.
Dudas habituales sobre mantenimiento WordPress
How do I fix autoloaded options could affect performance?
Primero mide el tamaño de autoload, identifica las opciones más grandes y confirma su origen. Luego elimina solo transients caducados, opciones huérfanas y restos seguros con copia previa.
Si la web depende de un plugin crítico, no lo toques sin probar en staging. Un cambio bueno tarda 15 minutos; uno malo puede costar horas.
What are autoloaded options in WordPress?
Son opciones que WordPress carga al arrancar cada página. Sirven para evitar más consultas, como tener a mano lo que usas a diario.
No todas son malas. Muchas son necesarias para que el sitio funcione bien.
How do I clean up autoloaded options in WordPress?
Limpia con una consulta de solo lectura, una copia de seguridad y una revisión de cada opción pesada. Después elimina solo lo confirmado como transients expirados, opciones huérfanas o restos de plugins.
Si no sabes de dónde viene una opción, no la borres. Esa prudencia evita el error más caro.
¿Qué tamaño es preocupante?
Entre 800 KB y 1 MB ya conviene revisar con calma, y por encima de 1 MB en sitios normales merece acción. En tiendas grandes puede haber más margen, pero solo si el contenido es realmente útil.
El número aislado no manda. Manda qué hay dentro y si se usa al arrancar.
¿Conviene usar un plugin de limpieza?
Solo si sabes qué hace y puedes probarlo en staging. Un buen plugin ayuda a ver y limpiar, pero uno agresivo puede borrar más de la cuenta.
La forma correcta sigue siendo la misma: medir, revisar y tocar poco.
¿Puedo borrar transients sin riesgo?
Los transients expirados suelen poder borrarse con bajo riesgo si ya han caducado de verdad. El riesgo sube si el plugin los está usando como caché viva y no como dato vencido.
Si dudas, revisa primero el nombre del plugin que los creó. Eso suele aclarar mucho.
¿Qué hago si el aviso sigue tras limpiar?
Revisa hosting, caché, imágenes y consultas lentas fuera de wp_options. Puede que el aviso sea un síntoma, pero no la causa principal.
Si el sitio sigue lento tras una limpieza prudente, toca mirar el conjunto, no solo la tabla wp_options.
El plan concreto
Revisa primero el tamaño total, luego las opciones más pesadas y después los restos seguros. Ese orden reduce riesgo y suele dar mejoras reales en menos de una hora.
No elimines por nombre desconocido ni por impulso. En WordPress, una limpieza buena es la que deja el sitio igual por fuera, pero más ligero por dentro.
Si el aviso de rendimiento sigue, el siguiente paso no es borrar más. Es ampliar el diagnóstico a servidor, caché, imágenes y consultas lentas, para no atacar el síntoma equivocado.
La regla segura es simple: primero ver, luego decidir y solo después borrar.
