WordPress autoload: Por qué wp_options ralentiza su sitio web

WordPress Autoload carga masas de opciones de la tabla wp_options en la memoria con cada petición de página y por lo tanto aumenta los requisitos de TTFB, CPU y RAM. Si aquí se acumulan demasiados datos de carga automática, esta tabla ralentizará notablemente tu sitio.

Puntos centrales

Resumiré los hechos más importantes para que puedas evaluar inmediatamente si las opciones autoloaded te están ralentizando. Con cada petición, WordPress carga todas las entradas con autoload=yes, independientemente de si son necesarias. Esto actúa como una mochila invisible que se hace más pesada con cada plugin instalado. A partir de un tamaño de autoload de alrededor de 1 MB, el rendimiento cae rápidamente, lo que es particularmente notable en los hosts más pequeños. Con unos pocos pasos específicos, puedo reducir permanentemente la carga y mantener el wp_opciones limpio.

• Carga automáticaTodo lo que tiene autoload=yes se guarda con cada petición de página.
• Tamaño crítico: TTFB aumenta bruscamente a partir de ~1 MB; 2-3 MB se considera un rango de alarma.
• Conductor principalPlugins, transitorios, registros y cron jobs defectuosos.
• MediciónSQL/WP-CLI muestra el tamaño y el originador superior inmediatamente.
• soluciónLimpiar, autocargar a „no“, subcontratar, comprobar regularmente.

Por qué se ralentiza la carga automática

Las opciones autocargadas se almacenan en memoria con cada petición, independientemente de si la página las necesita o no; esto es exactamente lo que consume memoria. Recursos. Los valores pequeños apenas se notan, pero con muchos plugins el total crece rápidamente hasta cientos de kilobytes o incluso varios megabytes. A partir de alrededor de 1 MB, observo regularmente un aumento del TTFB, páginas de administración más lentas y más picos de CPU. En alojamiento compartido, la carga se multiplica porque las peticiones paralelas aumentan el base de datos wordpress Además. Cuanto mayor sea el bloque de autocarga, más tardará la deserialización y más tiempo perderá su servidor antes del primer byte.

Cómo carga WordPress internamente (alloptions y caché de objetos)

WordPress combina todas las opciones autocargadas en un gran bloque. Con la primera petición, este bloque se carga con una única consulta y se almacena bajo la clave colectiva alopciones se almacena en la caché de objetos. Esto reduce el número de consultas a la base de datos, pero no la cantidad de datos que hay que procesar: Hay que deserializar todo el bloque y mantenerlo en memoria. Con un Caché de objetos persistente (por ejemplo, Redis o Memcached), la carga de la base de datos desaparece, pero los procesos PHP todavía tienen que desempaquetar los datos y mantenerlos en RAM. Esto significa que un gran bloque de autoload también es perjudicial si los datos provienen de la caché - sólo el cuello de botella se desplaza de la base de datos a la CPU y la RAM.

Esto es especialmente crítico en el caso de:

• alto paralelismo (muchas peticiones simultáneas): Cada PHP worker carga el bloque por separado.
• tiempos de proceso cortos (FPM/Serverless): La sobrecarga se produce de nuevo por cada nuevo proceso.
• Área de administración y cronLas cachés se puentean o invalidan con más frecuencia, el bloque de autocarga cuenta cada vez.

Cómo encontrar a los mayores infractores del autoload

Empiezo con una medida de tamaño directamente en el wp_opciones. Obtengo la suma mediante SQL: SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';. Los valores superiores a 1 MB son críticos, a partir de 2-3 MB se vuelve peligroso, especialmente con tráfico. A continuación, ordeno por tamaño: SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY bytes DESC LIMIT 20;. Así identifico las matrices grandes, antiguas Transitorios y entradas de plugins que a menudo no necesitan ser autocargados; un breve Instrucciones paso a paso ayuda a evaluar los resultados de forma fiable.

Diagnóstico avanzado: recuento, agrupación, reconocimiento de patrones

Además del tamaño total, también compruebo el número y el origen de las entradas:

• Número de opciones autocargadas: SELECT COUNT(*) FROM wp_options WHERE autoload='yes';
• Top namespaces (heurísticamente mediante prefijos): SELECT SUBSTRING_INDEX(option_name,'_',1) AS ns, COUNT(*) AS cnt, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes' GROUP BY ns ORDER BY by bytes DESC LIMIT 10;
• Transitorios que se autocargan falsamente: SELECT option_name FROM wp_options WHERE autoload='yes' AND option_name LIKE '_transient_%' ESCAPE '';

Utilizo estas consultas para encontrar rápidamente cachés de estadísticas, artefactos de constructores de páginas o restos de registros, por ejemplo. Los patrones suelen ser claramente reconocibles: varios miles de pequeñas entradas de un plugin de análisis o unas cuantas matrices muy grandes de un constructor.

Valores límite y medidas

Para una evaluación rápida, utilizo umbrales fijos y los utilizo para organizar la siguiente Pasos off. Esto me permite tomar decisiones sin perder tiempo en corazonadas. La tabla ayuda a categorizar y ofrece opciones claras de actuación en cada área. Me atengo a ella porque funciona de forma fiable en muchos proyectos. Especialmente cuando los recursos son escasos. Claridad en menos de un minuto.

Tamaño de carga automática	Riesgo	Medida recomendada
0-500 KB	bajo	Documentar el estado, comprobar de vez en cuando
500 KB-1 MB	medio	Compruebe las entradas más grandes, elimine las innecesarias
> 1 MB	alta	Identificar al remitente principal, indicador de autocarga „no“.“
> 2-3 MB	Crítica	Limpieza sistemática, eliminar transitorios

Limpieza segura: paso a paso

Hago una copia de seguridad de la base de datos antes de cada cambio, porque una copia de seguridad completa me protege de Errores. Con WP-CLI es rápido y fácil: exportación wp db. Borro los transitorios caducados: wp transient delete --expired y sólo si es necesario todas ellas: wp transient delete --all. En concreto, elimino las opciones de plug-in huérfanas, por ejemplo con wp option eliminar mi_opcion_plugin. Para entradas grandes que no tienen que ser autoloaded, implemento la bandera: wp option update nombre_opcion 'valor' --autoload=no; luego compruebo el frontend y el Backend a fondo.

Red de seguridad, pruebas y desmantelamiento

Después de cada cambio, compruebo estas áreas en este orden: página de inicio (como invitado), una subpágina profunda, inicio de sesión/cierre de sesión, panel de control del administrador y guardar una entrada. También activo Cron: wp cron event run --due-now y compruebo el registro de errores. Si algo se rompe, reinicio específicamente: wp option update nombre_opcion 'valor' --autoload=yes o establecer la copia de seguridad. Para matrices grandes, exporto su contenido por adelantado con wp option get nombre_opcion > backup.json, Puedo restaurarlo en cualquier momento.

Lo que no pongo en „autoload=no“

WordPress utiliza algunas opciones muy temprano en el bootstrap o con cada solicitud de procesamiento. Yo no cambio ciegamente su bandera autoload, incluso si son grandes:

• siteurl, inicio: URLs básicas, requeridas con antelación.
• permalink_structure, rewrite_rules: Imprescindible para la resolución de solicitudes; si no están en alopciones, a continuación, más resultados de la base de datos.
• plantilla, hoja de estiloDeterminación del tema.
• blog_charset, timezone_string y otros valores por defecto del núcleo.

Regla básica: Dejo las opciones principales y las que se usan en casi todas las peticiones autoloaded. Me concentro en entradas de plugins grandes y poco utilizadas, artefactos de caché, registros y transitorios antiguos.

Cuando las opciones deben seguir siendo grandes

Algunos datos pueden ser de gran tamaño, pero no es necesario almacenarlos en memoria para cada solicitud. terreno. Para configuraciones extensas, uso mis propias tablas en lugar de wp_options; esto mantiene la cantidad de autoload pequeña. La información relacionada con el usuario pertenece a la meta del usuario, no a las opciones globales. Yo guardo contenido estático como largas cadenas CSS/JS como un archivo y las cargo específicamente. Al guardar, pongo autoload directamente a „no“, por ejemplo con add_option('nombre', $data, '', 'no');, para evitar Cargando que hay que evitar.

Guía del desarrollador: Patrones escalables

Como desarrollador, evito las enormes „megaopciones“ que recogen todo en una matriz. Es mejor un conjunto básico reducido (autoload=yes) más cargas perezosas específicas (autoload=no). Patrones prácticos:

• Opciones de división: mi_plugin_core (pequeño, autoload=yes) y mi_plugin_cache_* (grande, autoload=no).
• Almacenamiento en caché específico: Subconjuntos requeridos frecuentemente con wp_cache_set() en lugar de cargar automáticamente las opciones grandes.
• Utilizar correctamente los transitorios: Por defecto, no guardar autoloaded y recuperar conscientemente; sólo muy pequeño, transitorios utilizados con frecuencia autoloaded.
• Detener el crecimiento de las opciones: No almacene registros o cachés no limitados en las opciones; aplique el tamaño máximo y el TTL.

Prevención en lugar de reparación

Mantengo mis plugins magra y desactivar cualquier cosa que no tiene un beneficio claro, por lo que el bloque de carga automática se mantiene pequeño. Una vez al mes compruebo el tamaño con SQL o WP-CLI y documento los valores. En Herramientas > Estado del sitio web, controlo las notas sobre las opciones cargadas automáticamente. Para sitios con mucho tráfico, merece la pena utilizar un alojamiento que optimice el base de datos wordpress eficientemente y mantiene wp_options limpio. Una colección de probada eficacia Estrategias de ajuste me ayuda a reconocer los problemas a tiempo y evitar que se agraven.

Automatización: pequeños trabajos, gran impacto

Programo una limpieza regular. Una tarea cron nocturna (o una cron de servidor que ejecute WP-CLI) elimina los transitorios caducados y registra el tamaño de la carga automática en un archivo o tabla. Esto me permite ver las tendencias antes de que los usuarios las noten. Ejemplo de proceso (simplificado):

wp transient delete --expired
wp db query "SELECT NOW(), SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';" >> autoload_stats.log

Es conveniente un pequeño chequeo que guarde las 10 entradas principales con fecha. Basta con echar un vistazo al registro para asignar los valores atípicos a un momento concreto, normalmente tras la actualización de un plugin o una nueva función.

Ejemplo práctico: limpieza de 60 minutos

En un proyecto encontré 5.500 opciones autocargadas que totalizaban unos 2 MB; la página devolvía el primer byte después de aproximadamente 1.900 ms. Tras la copia de seguridad, el borrado transitorio, la comprobación de los 20 primeros y los ajustes de las banderas, el tiempo de carga se redujo a la mitad, a unos 500 ms. La utilización de la CPU bajó de 89 % a alrededor de 2,5 %, y el backend respondió mucho más rápido. El procedimiento era sencillo: medir, limpiar, probar, documentar. Esta es exactamente la rutina que utilizo regularmente para controlar el crecimiento del wp_opciones permanentemente.

Causas típicas y soluciones

A los creadores de páginas les gusta escribir grandes matrices de caché en opciones que yo prefiero escribir en archivos. descarte. Guardo las estadísticas como transitorios no cargados automáticamente y los recupero específicamente. Los registros deben estar en archivos rotativos, no en wp_options. Las tareas cron fallidas provocan transitorios antiguos; aquí ajusto los intervalos y los tiempos de espera. Estos simples cambios reducen rápidamente la cantidad de autoloads y los mantienen estables a largo plazo. estable.

Influencia de las cachés, el FPC y el alojamiento

Una caché de página completa (FPC) protege principalmente a los visitantes anónimos. Sin embargo, cuando la caché se salta - usuarios registrados, cesta de la compra, pago, admin, cron, WP-CLI - el bloqueo de carga automática tiene pleno efecto. Un servidor de base de datos rápido oculta la carga de E/S, pero el tiempo de CPU para la deserialización y el consumo de RAM permanecen. Especialmente en instancias pequeñas con pocos trabajadores FPM, un gran bloque de autocarga lleva a colas y tiempos de espera, aunque los datos vengan „de la caché“. Por lo tanto, el objetivo es siempre mantener pequeño el bloque en sí, no sólo hacer más rápido el origen.

Seguimiento y cifras clave

Hago un seguimiento de TTFB, First Contentful Paint y el tiempo de carga del backend antes y después de cada Limpieza. Al mismo tiempo, documento el tamaño de autocarga, el número de opciones autocargadas y las entradas más grandes. Una pequeña hoja con la fecha, el tamaño y el TTFB es suficiente para obtener tendencias claras. Para el mantenimiento, utilizo consultas SQL mensuales y un breve Mantener la base de datos-lista de control. Esto me permite reconocer a tiempo los valores atípicos y mantener la base de datos wordpress permanentemente delgado.

Multisitio: Dos obras de un vistazo

En las configuraciones multisitio, hay carga automática tanto por sitio como a nivel de red. Por lo tanto, compruebo la wp_opciones de cada sitio (prefijo de tabla por blog) y adicionalmente las opciones de red. Las matrices grandes utilizadas globalmente afectan a todos los sitios. Proceda como en la configuración única: mida, identifique las entradas más importantes, externalice los valores grandes o cambie a autoload=no si no se necesitan para cada solicitud. La reducción se nota de inmediato, sobre todo en el administrador de red.

Malentendidos frecuentes - aclarados brevemente

• „Redis resuelve el problema“.“ Reduce las consultas a la BD, pero no el tamaño del bloque de autocarga. Los costes de CPU y RAM se mantienen.
• „El FPC hace que el autoload sea irrelevante“.“ No para los usuarios registrados, Cron y Admin. La ventaja FPC no se aplica allí.
• „Borrar todos los transitorios es peligroso“.“ Es seguro, pero sólo provoca nuevas acumulaciones. Utilícelo de forma selectiva y planificada.
• „Un bloque grande está bien si hay pocas entradas“.“ Lo decisivo es la suma de los bytes y la deserialización, no el número por sí solo.

Plan de pruebas tras la limpieza

• Parte delanteraPágina de inicio, archivo aleatorio y página detallada, como invitado y usuario conectado.
• FuncionesBúsqueda, formulario de contacto, cesta de la compra/caja (si es una tienda).
• AdminPanel de control, lista de entradas, guardar una entrada/producto, página de plugins.
• AntecedentesEjecuta eventos cron programados, comprueba el registro de errores, mide aleatoriamente TTFB.

Resumen para decisiones rápidas

Las opciones autocargadas son un asesino silencioso del rendimiento, que puedo eliminar con unos pocos pasos claros. captura. Mido el tamaño, elimino los transitorios antiguos, establezco las entradas innecesarias en autoload=no y externalizo los datos grandes. Después pruebo el frontend y el backend y anoto los puntos de medición. Con una hora de trabajo concentrado, suelo reducir la carga autoload en 30-70 % y reducir a la mitad los tiempos de carga. Si repites esta rutina cada mes, puedes mantener el wp_opciones rápido y el sitio responde notablemente.