Por qué WordPress es tan lento: El impacto oculto de la base de datos

Cuando una empresa nota que las conversiones caen o el panel de administración se congela, la pregunta inevitable es por qué WordPress es tan lento. En la mayoría de los casos, la reacción inmediata consiste en instalar más plugins de optimización, comprimir imágenes o contratar un hosting superior.

Sin embargo, si tu web WordPress va lenta incluso tras configurar sistemas de caché, el origen del problema suele estar en el motor de base de datos relacional (MySQL o MariaDB).

La caché no soluciona una base de datos sobrecargada

La caché de página completa es efectiva para usuarios anónimos que visitan páginas corporativas estáticas. No obstante, en un entorno B2B o en tiendas online con WooCommerce, gran parte del tráfico crítico no puede cachearse: paneles de clientes, pasarelas de pago, filtros complejos de catálogo y la propia administración interna.

Cada vez que se procesa una petición dinámica, WordPress ejecuta decenas o cientos de consultas SQL. Si la base de datos tarda dos segundos en responder, el tiempo hasta el primer byte (TTFB) se dispara. Los workers de PHP quedan retenidos, agotando la memoria del servidor y provocando que toda la web responda con lentitud extrema.

1. La saturación silenciosa de wp_options y el autoload

El principal cuello de botella en instalaciones con tiempo de vida suele residir en la tabla wp_options, concretamente en los registros con autoload = 'yes'. WordPress carga todos estos datos en memoria en cada petición para inicializar el sitio y sus plugins.

Muchos plugins almacenan configuraciones masivas o cachés temporales con autoload activo. Cuando el tamaño agregado supera 1 MB o 2 MB, el servidor debe transferir y deserializar ese bloque en cada visita. Identificar y depurar opciones obsoletas reduce de inmediato el consumo de memoria de PHP y acelera la respuesta del servidor.

2. El modelo EAV en wp_postmeta y las consultas lentas

WordPress gestiona los campos personalizados mediante el modelo EAV (Entity-Attribute-Value) en la tabla wp_postmeta. Aunque aporta flexibilidad, este esquema castiga el rendimiento en bases de datos con volumen.

Filtrar productos por varios atributos o consultar historiales de pedidos obliga a MySQL a realizar múltiples uniones (JOINs) sobre tablas con millones de filas. Sin índices compuestos adecuados, el motor recurre a escaneos completos de tabla (full table scans), disparando el uso de CPU y bloqueando peticiones concurrentes.

3. Transients vencidos y datos huérfanos

Una instalación madura acumula residuos que degradan la agilidad de las consultas:

• Transients expirados: Datos temporales que no son eliminados por las rutinas de limpieza.
• Sesiones de WooCommerce huérfanas: Registros de carritos que saturan tablas completas.
• Revisiones y metadatos huérfanos: Registros asociados a publicaciones o extensiones eliminadas hace años.

Este volumen innecesario fragmenta las tablas y satura el buffer pool de InnoDB, expulsando de la memoria RAM los datos consultados con frecuencia.

Cómo auditar y sanear la base de datos

Si tu web WordPress va lenta por la base de datos, antes de cambiar de infraestructura conviene seguir estos pasos:

1. Activar el registro de consultas lentas (Slow Query Log): Aísla con precisión las consultas que superan 500 ms.
2. Medir el tamaño del autoload: Audita la tabla wp_options y purga datos de extensiones inactivas.
3. Implantar caché de objetos persistente: Configurar Redis o Memcached reduce las lecturas recurrentes a disco.
4. Optimizar índices y arquitectura: En tiendas con alto tráfico, activar HPOS y crear índices en metadatos críticos.

El rendimiento no se soluciona acumulando capas de caché. Si necesitas diagnosticar y resolver los cuellos de botella de un WordPress lento, en Lanzamiento Digital auditamos tu base de datos para recuperar la velocidad operativa de tu negocio.