Ir al contenido 
Opciones de carga automática de WordPress decidir qué opciones de la tabla wp_options se transfieren a la memoria cada vez que se carga una página, lo que influye directamente en el tiempo de carga, el TTFB y los requisitos de memoria. Te mostraré cómo identificar datos de autocarga demasiado grandes, reducirlos de forma selectiva y mantenerlos pequeños de forma permanente, para que las solicitudes se inicien más rápido y el backend responda de forma notablemente más fluida.
Puntos centrales
Muchas instalaciones descargan paquetes de datos que crecen silenciosamente. Carga automática, aunque estas entradas no son necesarias para todas las páginas. Primero priorizo el análisis del tamaño total, luego las opciones más grandes y, a continuación, establezco las entradas no críticas en autoload=no o las elimino de forma controlada. De este modo, reduzco el TTFB y el consumo de RAM, estabilizo las consultas y alivio la carga de PHP. Además, mantengo los transitorios limpios y compruebo la tabla regularmente para evitar que se acumule nuevo lastre. El alojamiento, la caché de objetos y una tabla wp_options optimizada interactúan entre sí y proporcionan mejoras notables en el rendimiento sin ningún riesgo.
- Análisis El tamaño de la carga automática y las opciones principales
- Limpieza Entradas de complementos huérfanas
- Interruptor Opciones amplias y poco utilizadas en no
- Transitorios y eliminar datos temporales
- Monitoreo y tener en cuenta la configuración del alojamiento
Incorporo estos pasos en mi Mantenimiento para que la base de datos se mantenga ágil y el sitio web responda con rapidez y fiabilidad incluso en momentos de mayor tráfico.
¿Qué son las opciones de carga automática en WordPress?
WordPress almacena las configuraciones en wp_opciones, incluyendo URL, plugins activos, información sobre temas, widgets, transitorios y mucho más. Cada registro tiene el nombre, el valor y el campo. carga automática, que determina con «yes» o «no» si WordPress carga la entrada cada vez que se inicia la página. La función wp_load_alloptions lee todas las entradas autoload=yes de una sola vez para proporcionar ajustes frecuentes sin muchas consultas SQL individuales. Este mecanismo ahorra tiempo con pocos valores pequeños, pero ralentiza el proceso de inicio con muchas entradas grandes. Aquí es precisamente donde se produce un freno oculto que apenas se nota en el día a día. A lo largo de los años, se acumula una carga que puede prolongar cada solicitud entre milisegundos y segundos.
No todas las opciones pertenecen a Carga automática: Datos básicos como siteurl o active_plugins sí, datos de caché o de registro más bien no. Si quedan restos de plugins antiguos en la tabla y están marcados como «yes», WordPress seguirá cargándolos aunque ya nadie los solicite en el código. Los campos grandes de los creadores de páginas, los plugins de formularios o las suites de SEO pueden hacer que el paquete de carga automática supere rápidamente 1 MB. A partir de ese momento, el TTFB y los requisitos de memoria aumentan, especialmente en hosts compartidos y con una carga elevada. Por lo tanto, compruebo regularmente qué es lo que realmente debe cargarse automáticamente.
Por qué la carga automática frena el rendimiento
Cada visita a la página suma el total de todas las autoload=sí Valores en la memoria, independientemente de si los datos son relevantes para la página actual. Esto consume RAM, aumenta la estructura PHP y ralentiza la ejecución inicial antes del renderizado. Cuantos más plugins se instalen, más crecerá el paquete sin que nos demos cuenta. Las configuraciones de WooCommerce, los plugins de seguimiento o los creadores de páginas también aumentan la probabilidad de entradas grandes. Si dejas que esto siga así, el primer byte, que a menudo determina la impresión general, sufrirá especialmente bajo la carga.
Varias guías técnicas recomiendan que el tamaño total no supere aproximadamente 1 MB porque aumenta notablemente la latencia. Cuando se encuentran grandes cantidades de datos de autoload con un I/O débil o mucho tráfico paralelo, los tiempos de respuesta aumentan considerablemente. El backend se vuelve lento, las páginas de administración se abren más lentamente y las tareas cron tardan más en ejecutarse. El efecto no afecta directamente al almacenamiento en caché, pero retrasa la generación de respuestas y el llenado de la caché. Por lo tanto, mantengo el autoload lo más pequeño posible y solo cargo lo que realmente necesito en todas partes.
Así compruebo el tamaño de los datos de carga automática
Empiezo con un completo Copia de seguridad de la base de datos y, a continuación, leo el tamaño de la carga automática. En el panel de control, el estado del sitio web ya proporciona una indicación si el número y el tamaño son notablemente altos. Para obtener una medición exacta, utilizo SQL y sumo la longitud de todos los valores autoload=yes. Este número me indica la urgencia con la que debo intervenir. Si supera 1 MB, planifico inmediatamente una limpieza específica. Una práctica WP-Options Mantenimiento de datos me ayuda a actuar de forma coherente.
Utilizo las dos consultas siguientes para analizar la Talla y los más grandes. Primero calculo la suma de todos los valores cargados automáticamente. A continuación, enumero los 10 principales por tamaño de campo para obtener resultados rápidos. Así puedo detectar en cuestión de minutos dónde se pierde memoria y latencia. Después, priorizo la eliminación o el cambio a autoload=no.
SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';
SELECT nombre_opción, LENGTH(valor_opción) AS longitud_valor_opción FROM wp_options WHERE autoload = 'yes' ORDER BY longitud_valor_opción DESC LIMIT 10;
Qué entradas suelen ser grandes
Frecuentes flatulencias Transitorios, objetos de caché y datos de registro se cargan automáticamente sin necesidad. Los diseños de generador y las configuraciones de formularios también escriben matrices extensas que no son necesarias para cada página del frontend. Incluso los plugins desactivados suelen dejar restos que siguen estando en «yes». En la práctica, se repiten patrones en los que baso mi limpieza. La siguiente tabla resume los candidatos típicos y las recomendaciones. Esta visión general acelera la decisión de si es conveniente eliminar o cambiar a «no».
| Categoría | Ejemplos option_name | Tamaño típico | Recomendación |
|---|---|---|---|
| Núcleo Base | siteurl, home, blogname | pequeño | mantener autoload=yes |
| Tema & Widgets | plantilla, hoja de estilos, widget_* | pequeño-mediano | Comprobar, normalmente sí, vale. |
| Constructor / Formularios | builder_*, form_*, theme_mods_* | mediano-grande | Establecer autoload=no |
| Transitorios | _transient_*, _site_transient_* | mediano-grande | Eliminar los que caducan, si no... |
| Cache & Registros | cache_*, log_*, debug_* | Grande | No cargar automáticamente, eliminar si es necesario. |
| Huérfano | Restos antiguos de plugin_* | pequeño-grande | Eliminar después de la copia de seguridad |
En todos los dispositivos, una rígida Separación de configuraciones permanentes y datos temporales los mejores efectos. Solo cargo lo que cada página realmente necesita. Todo lo demás permanece disponible, pero no se carga automáticamente. De esta manera, aligeré la fase de inicio y la gestión de objetos del proceso PHP. Resultado: tiempos de respuesta notablemente más rápidos.
Estrategias para la optimización
Empiezo quitando contaminación histórica Plugins abandonados, porque estos pasos ahorran mucho espacio y tiempo rápidamente. A continuación, configuro las opciones grandes y poco utilizadas en autoload=no, para que solo se lean cuando sea necesario. Las entradas temporales o relacionadas con la caché nunca deben incluirse en Autoload y se eliminan o se almacenan en memorias dedicadas. Sigo limpiando sistemáticamente los transitorios, especialmente los registros caducados. Por último, vuelvo a comprobar el tamaño total y documento el nuevo estado. De este modo, consigo transparencia y establezco un sistema de supervisión.
Trabajo de forma incremental para Riesgos Minimizar: primero medir, luego cambiar de forma específica y, a continuación, volver a comprobar. Tengo una copia de seguridad preparada para cada eliminación. Para las páginas productivas, planifico franjas horarias fuera de las horas punta. Pruebo los cambios en campos sensibles en una instancia de ensayo. De este modo, la página permanece en línea y el resultado es fiable.
Establecer Autoload en „no“: implementación segura
No todas las opciones grandes tienen que desaparecer, muchas se pueden combinar con autoload=no Desactivar. De este modo, se mantiene la configuración, solo se omite la carga automática. Realizo el cambio de forma controlada mediante SQL y, a continuación, compruebo el comportamiento en el frontend y en el backend. Pruebo específicamente las páginas críticas, como los formularios o las funciones de la tienda. Si se producen errores, revoco el cambio inmediatamente. El procedimiento es rápido y, por lo general, no tiene efectos secundarios.
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'TU_NOMBRE_DE_OPCIÓN';
Para varios candidatos, escribo una pequeña Lista de los nombres de la consulta de los 10 primeros y los procesa uno tras otro. Después de cada actualización, vuelvo a medir el tamaño. Si la suma se reduce significativamente, el TTFB y el consumo de RAM disminuyen inmediatamente. Si algo sale mal, utilizo la copia de seguridad o vuelvo a establecer autoload en yes. Así me mantengo en el lado seguro.
Eliminar transitorios y datos temporales
Los transitorios son limitados en el tiempo. memoria intermedia y a menudo se mantienen innecesariamente durante mucho tiempo en wp_options. Las entradas caducadas suelen permanecer ahí si la limpieza falla. Yo elimino regularmente las entradas caducadas _transient_* y _site_transient_*. Además, me aseguro de que esos datos no se almacenen con autoload=yes. De este modo, el paquete de autoload se reduce notablemente y se mantiene pequeño. Este cuidado debe formar parte de cualquier plan de mantenimiento.
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%';
Quienes utilizan herramientas prestan atención a Seguridad y registros claros, para que los cambios sean comprensibles. Primero pruebo manualmente los trabajos de limpieza automática. Después programo comprobaciones periódicas, por ejemplo, trimestrales. Así no hay sorpresas. Y la tabla no vuelve a crecer sin que nos demos cuenta.
Índice en la columna Autoload
Si hay muchas opciones, se puede crear un índice en la columna. carga automática Acelerar aún más los accesos. La consulta autoload=yes se beneficia entonces de una búsqueda más rápida. Esto resulta especialmente útil en tiendas grandes y activas o en configuraciones multisitio. La intervención debe realizarse por manos expertas, ya que los índices incorrectos pueden crear sus propios problemas. Con un plan claro y una copia de seguridad, los tiempos de consulta se reducen notablemente. Documentaré el cambio y mediré el efecto.
Paralelamente, creo que la Base de datos De forma integral: el motor, el búfer, las consultas lentas y las tareas programadas influyen en el resultado global. La carga automática es una herramienta fundamental, pero no la única. Una tabla ordenada con una buena indexación interactúa con las cachés y la configuración de PHP. Así consigo ganar unos milisegundos adicionales. Las pequeñas correcciones se van sumando.
Combinar de forma inteligente el alojamiento, la caché de objetos y la carga automática
Un host rápido amortigua los efectos negativos de los grandes Carga automática, pero no sustituye a la limpieza. Resulta especialmente eficaz cuando una caché de objetos gestiona los accesos frecuentes a las opciones. De este modo, los valores se almacenan en la memoria y se evitan las lecturas recurrentes de la base de datos. Sin embargo, la mayor ventaja sigue siendo una suma de autoload reducida. Esta comparación ofrece una breve orientación: mantenga el autoload reducido y luego complemente las cachés de forma sensata. Encontrará más información al respecto en el artículo. Caché de página frente a caché de objetos.
Ocultar cachés Problemas Solo de forma limitada, si la base de datos es innecesariamente grande. Primero limpio la tabla para que las cachés tengan que transportar menos datos. Después, obtengo un doble beneficio: un inicio más rápido y un acceso repetido más rápido. La monitorización me muestra si el TTFB y la RAM se mantienen estables en niveles más bajos. De este modo, se crea una configuración limpia con reservas para los picos de tráfico.
Cuándo es imprescindible autoload=yes
No todo puede pasar a „no“. Hay Opciones principales, que WordPress necesita muy pronto en el arranque o prácticamente en cada solicitud. Entre ellos incluyo normalmente:
- siteurl y home (URL básicas, utilizadas anteriormente)
- active_plugins (se necesita directamente al cargar los plugins)
- hoja de estilo y plantilla (selección de tema)
- nombre del blog, descripción del blog, blog_charset (datos generales de la página)
- rewrite_rules (se necesita para el análisis de solicitudes y puede ser grande)
Por lo general, dejo estas opciones en autoload=sí. En casos límite como rewrite_rules Compruebo si hay conjuntos de reglas excepcionalmente grandes y si hay enlaces permanentes o complementos incorrectos que aumenten el tamaño. Campos como cron y las opciones complejas de los complementos se consideran sensible: Pueden crecer mucho, pero se utilizan con frecuencia. Aquí compruebo en Staging si autoload=no Tiene efectos secundarios antes de tomar una decisión.
Características multisitio y opciones de red
En Multisitio-En cada sitio existen tablas wp_options propias con campo Autoload, además de la tabla global. wp_sitemeta para las opciones de red. Por lo tanto, compruebo la suma de autoload por sitio y, además, el tamaño de los metadatos centrales de la red. Las opciones de red grandes no suponen un coste en cada solicitud individual del sitio, pero pueden ralentizar los procesos de administración y cron.
-- Comprobar por sitio (ajustar el prefijo de la tabla según el ID del blog) SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_2_options WHERE autoload = 'yes'; -- Revisar los metadatos de toda la red SELECT SUM(LENGTH(meta_value)) AS network_meta_size
FROM wp_sitemeta; -- Metadatos más grandes de la red SELECT meta_key, LENGTH(meta_value) AS len FROM wp_sitemeta ORDER BY len DESC LIMIT 10;
Para multisitios se aplica lo siguiente: elimino las opciones más grandes por sitio y mantengo los metadatos de red también reducidos. Las cachés compartidas (caché de objetos) ayudan, pero no sustituyeron Base de datos limpia.
WP-CLI: análisis y modificaciones masivas desde el shell
En los servidores utilizo WP-CLI, para ejecutar directamente los análisis SQL y hacer que los cambios sean reproducibles. De este modo, garantizo auditorías rápidas incluso en configuraciones más grandes.
# Determinar el tamaño total de la carga automática wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload='yes';"
# Mostrar las 20 opciones de autocarga más grandes wp db query "SELECT option_name, LENGTH(option_value) AS len FROM wp_options WHERE autoload='yes' ORDER BY len DESC LIMIT 20;"
Para los cambios masivos, trabajo con una lista de candidatos del análisis y lo pongo en no de forma controlada. Después de cada ronda, vuelvo a medir la suma.
# Ejemplo: candidatos (uno por línea) en names.txt
# autoload=no para todos los nombres (¡cuidado, haz una copia de seguridad antes!) while read -r NAME; do VAL="$(wp option get "$NAME")" wp option update "$NAME" "$VAL" --autoload=no done < names.txt
Con este método, el historial permanece trazable en el terminal y puedo retroceder de forma específica si es necesario.
Mantenimiento automático con el complemento MU
Para evitar el crecimiento futuro, pongo pequeños Barandillas Un plugin MU puede, por ejemplo, cambiar automáticamente la bandera de autocarga para patrones conocidos, como transitorios, entradas de caché y registros, a „no“ y limpiarlos periódicamente. Primero pruebo estas intervenciones en el entorno de pruebas.
update($wpdb->options, array('autoload' => 'no'), array('option_name' => $option)); break; } } }, 10, 3);
// Limpieza programada: eliminar transitorios caducados if (!wp_next_scheduled('autoload_housekeeping')) { wp_schedule_event(time(), 'daily', 'autoload_housekeeping'); } add_action('autoload_housekeeping', function() { global $wpdb;
// Limpiar transitorios caducados (sin tiempos de espera) $wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%'");
$wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_site_transient_%' AND option_name NOT LIKE '_site_transient_timeout_%'");
// Opcional: mitigar opciones de autocarga muy grandes $candidates = $wpdb->get_col("SELECT option_name FROM {$wpdb->options} WHERE autoload='yes' AND LENGTH(option_value) > 500000");
foreach ($candidates as $name) { $wpdb->update($wpdb->options, array('autoload' => 'no'), array('option_name' => $name)); } });
De esta forma, evito que se vuelvan a cargar datos innecesariamente grandes después de actualizaciones o nuevos plugins. Documento las excepciones (lista blanca) en caso de que determinadas opciones deban permanecer deliberadamente en Autoload a pesar de su tamaño.
Eliminación segura: ejemplos SQL más precisos
Borrar objetivo y evita daños colaterales. En el caso de los transitorios, procuro no borrar directamente los tiempos de espera, sino los valores correspondientes.
-- Eliminar solo transitorios caducados (enfoque seguro) DELETE o FROM wp_options o JOIN wp_options t ON o.option_name = REPLACE(t.option_name, '_timeout_', '') WHERE t.option_name LIKE '_transient_timeout_%'
AND t.option_value < UNIX_TIMESTAMP(); -- Transitorios de toda la red (multisitio) DELETE o FROM wp_options o JOIN wp_options t ON o.option_name = REPLACE(t.option_name, '_site_transient_timeout_', '_site_transient_')
WHERE t.option_name LIKE '_site_transient_timeout_%' AND t.option_value < UNIX_TIMESTAMP();
Además, para las opciones grandes que rara vez se utilizan, establezco sistemáticamente el indicador en „no“ en lugar de eliminarlas. De este modo, mantengo un riesgo bajo y puedo volver atrás en cualquier momento si es necesario.
Indexación: crear, probar, desmontar
Si la tabla es grande, un índice combinado acelera las búsquedas frecuentes. Lo creo, lo mido y, si no resulta útil, lo elimino.
-- Crear índice (adaptar el nombre según las reglas del host) CREATE INDEX autoload_name_idx ON wp_options (autoload, option_name); -- Probar, medir y, si es necesario, eliminar DROP INDEX autoload_name_idx ON wp_options;
Antes compruebo los índices existentes para no crear duplicados. Tras la creación, verifico los planes de consulta y los tiempos de respuesta bajo carga real.
Medición y validación: documentar claramente el antes y el después.
Las optimizaciones las acredito con cifras. Mido el TTFB en páginas representativas, realizo un seguimiento de los picos de memoria y cuento las consultas a la base de datos. Para obtener una visión rápida, utilizo una breve salida de registro durante las pruebas (no la dejo activa de forma permanente):
<?php // No utilizar de forma permanente en producción, ¡solo para pruebas! add_action('shutdown', function() { if (defined('WP_DEBUG') && WP_DEBUG) { error_log(sprintf(
'WP-Run: %.3fs | Queries: %d | Peak-Mem: %.1fMB', timer_stop(0, 3), get_num_queries(), memory_get_peak_usage(true) / 1048576 )); } });
Con dos o tres rondas de mediciones antes y después de la optimización, puedo ver si el TTFB, el número de consultas y la memoria máxima mejoran como se esperaba. Al mismo tiempo, observo el backend (páginas de plugins y editores), ya que aquí se notan especialmente los paquetes de autoload grandes.
Errores comunes y cómo evitarlos
- Poner todo en „no“: Las medidas generales interrumpen funciones o generan muchos SQL individuales. Procedo de forma selectiva y realizo pruebas.
- Cambiar opciones críticas del núcleo: Trate con cuidado siteurl, home, active_plugins, campos de tema y rewrite_rules.
- Eliminación incorrecta de transitorios: Eliminar los tiempos de espera en lugar de los valores, o borrar ambos al azar. Mejor: limpiar los valores caducados de forma selectiva.
- Trabajar sin copia de seguridad: Antes de cada ronda, guardo la base de datos y anoto los cambios.
- Pensar solo en „DB“: La caché de objetos, los límites de memoria PHP, las tareas cron lentas y los límites de alojamiento también influyen. Considero el sistema de forma integral.
- Limpiar una vez y olvidarse: Sin un control periódico, Autoload vuelve a crecer. Planifico intervalos de mantenimiento fijos.
Mejores prácticas para el futuro
Decido conscientemente Plugins, que manejan correctamente las opciones y borran los datos al eliminarlos. Después de las pruebas, los complementos se eliminan por completo, no solo se desactivan. Antes de realizar modificaciones importantes, siempre hago una copia de seguridad de la base de datos. A continuación, vuelvo a comprobar el tamaño de la carga automática para detectar inmediatamente cualquier anomalía. Especialmente en las configuraciones de almacenamiento en caché, mantengo la configuración sencilla y evito los típicos problemas. Echa un vistazo a Configuraciones incorrectas de Redis ayuda a evitar efectos secundarios.
Regular Atención evita que la tabla wp_options vuelva a crecer. Me fijo plazos fijos, por ejemplo, trimestrales. Si anoto los valores antes y después de la optimización, puedo detectar tendencias. De este modo, actúo a tiempo, en lugar de reaccionar más tarde bajo presión. Esta rutina ahorra tiempo y nervios a largo plazo.
Flujo de trabajo concreto paso a paso
Primero me aseguro Base de datos y los archivos por completo, para poder volver atrás en cualquier momento. A continuación, determino el tamaño actual de la carga automática y las 10 entradas principales mediante SQL. Después, identifico los datos de plugins huérfanos y las entradas grandes de caché, registro o transitorias. En el siguiente paso, configuro las opciones que se utilizan con poca frecuencia en autoload=no y elimino de forma selectiva los restos superfluos. Por último, vuelvo a medir, documento la nueva suma y planifico una repetición de la comprobación.
En casos delicados Campos Primero pruebo los cambios en el entorno de pruebas. Si se produce alguna anomalía, reactivo valores individuales o restauro la copia de seguridad. A continuación, ajusto mi selección de plugins para evitar un nuevo crecimiento. Basta con un sencillo protocolo por ronda para mantener una visión general. El proceso sigue siendo ágil y conduce de forma fiable a efectos medibles.
Resumen: tabla pequeña, gran efecto
Autoload es un potente mecanismo, que frena considerablemente cuando la tabla wp_options está llena de datos innecesarios. Si mantienes la suma por debajo de 1 MB, el TTFB, los requisitos de RAM y las latencias del backend disminuirán notablemente. El camino para lograrlo es claro: medir, eliminar el lastre, autoload=no para valores poco frecuentes, limpiar transitorios y controlar regularmente. Las cachés y un buen alojamiento refuerzan el efecto, pero no sustituyen a una base de datos limpia. Quien convierta este proceso en una rutina, obtendrá más velocidad de forma permanente con el mismo hardware.
Considero que Autoload es tornillo de ajuste Con una excelente relación calidad-precio: pocos cambios, efecto notable. Las tiendas y las páginas con mucho contenido se benefician de inmediato. Con una breve revisión mensual o trimestral, la tabla se mantiene ágil. Así, las páginas responden más rápido, los administradores trabajan con mayor rapidez y las tareas programadas se ejecutan sin problemas. Se trata de un rendimiento sostenible sin riesgos y sin necesidad de instalar nuevos plugins.
