Una web WordPress puede empezar a ir más lenta sin que haya cambiado nada visible en la portada. No siempre se debe a una imagen grande, a un servidor pequeño o a un plugin concreto.

En algunos casos, el problema está en la base de datos. Con el tiempo puede acumular revisiones de entradas, datos temporales, opciones de plugins que ya no existen y registros que se cargan automáticamente en cada petición.

El resultado es una instalación que tiene que consultar y transportar más información de la necesaria. La web sigue funcionando, pero cada operación puede costar un poco más. En una tienda, un proyecto con muchos plugins o una web con tráfico constante, esa acumulación puede terminar afectando al tiempo de respuesta.

La solución no consiste en borrar cosas al azar. Primero hay que saber qué está creciendo, quién lo ha creado y si sigue siendo necesario.

Qué significa que una base de datos esté hinchada

Una base de datos grande no es necesariamente una base de datos problemática. Una tienda con muchos pedidos, un medio con miles de entradas o una web con bastante actividad necesita almacenar datos.

El problema aparece cuando una parte importante del contenido no aporta valor operativo o se carga en momentos en los que no hace falta.

Algunos ejemplos habituales son:

  • Revisiones antiguas de entradas y páginas.
  • Transients caducados o acumulados.
  • Opciones creadas por plugins que ya no están instalados.
  • Metadatos de plugins y themes que han dejado de utilizarse.
  • Registros de tareas, estadísticas o eventos antiguos.
  • Tablas propias de extensiones que ya no existen.
  • Opciones marcadas para cargarse automáticamente en cada petición.

Cada caso requiere una comprobación diferente. El tamaño de una tabla puede llamar la atención, pero no explica por sí solo el impacto real sobre el rendimiento.

Revisiones: útiles, pero sin límite pueden crecer demasiado

WordPress guarda revisiones cuando se editan entradas y páginas. Esta función permite volver a una versión anterior y recuperar contenido después de un cambio accidental.

Las revisiones son útiles, pero una web con muchas ediciones puede acumular un número elevado de registros. Un constructor visual, un equipo editorial o un proceso automático que guarde repetidamente el contenido puede hacer que crezcan con rapidez.

La pregunta no debería ser “¿puedo borrar todas las revisiones?”, sino:

  • ¿Cuántas revisiones necesita realmente este proyecto?
  • ¿Existe una política de copias de seguridad que permita recuperar contenido?
  • ¿Hay usuarios que dependen de ese historial?
  • ¿El constructor o algún plugin utiliza esos registros?
  • ¿Se ha medido el tamaño antes y después de la limpieza?

Limitar las revisiones futuras puede evitar que vuelvan a crecer sin control. Borrarlas de forma puntual puede reducir el tamaño de la base de datos, pero no resolverá otros problemas si el origen está en un plugin o en una configuración que sigue generando registros.

Transients: datos temporales que no siempre desaparecen cuando esperas

Los transients son una API de WordPress para guardar temporalmente datos que pueden reutilizarse durante un periodo determinado. Los utilizan plugins y themes para almacenar resultados de consultas, respuestas de servicios externos, datos de sesiones y otros valores que no conviene calcular continuamente.

Por definición, deberían caducar. Pero su comportamiento depende del entorno. Sin una caché de objetos persistente, muchos transients se almacenan en la tabla wp_options de la base de datos. Además, los datos caducados no siempre desaparecen inmediatamente.

Esto puede producir una tabla de opciones con muchos registros temporales. No todos son inútiles y no todos deben borrarse manualmente. Un plugin puede regenerarlos, necesitarlos durante una operación o utilizarlos para evitar consultas más costosas.

La limpieza debe identificar primero el origen de los registros. Borrar todos los transients puede provocar que se reconstruyan en la siguiente visita o que un proceso tenga que repetir trabajo. En algunos casos, eso aumenta temporalmente la carga en lugar de reducirla.

Opciones autoload: los datos que WordPress carga en cada petición

Las opciones marcadas para cargarse automáticamente se recuperan en cada petición de WordPress. Esto permite que configuraciones importantes estén disponibles rápidamente, pero también significa que el volumen acumulado puede afectar a todas las páginas.

Un plugin puede registrar opciones pequeñas sin causar ningún problema. La dificultad aparece cuando una extensión guarda grandes cantidades de datos como autoload o cuando quedan opciones antiguas de plugins que ya no existen.

La documentación de WordPress recomienda prestar atención al tamaño total de las opciones autoload. No hay una cifra universal que convierta automáticamente una instalación en problemática, pero el propio equipo de WordPress utiliza 800 KB como referencia general para intentar mantener el autoload por debajo de ese nivel.

No conviene cambiar el valor autoload de una opción sin saber qué hace. Desactivar la carga automática de un dato necesario puede producir errores, consultas adicionales o comportamientos diferentes en el front-end y en el panel.

Una revisión responsable debería localizar:

  • Las opciones autoload más grandes.
  • El plugin o theme que probablemente las creó.
  • Si el componente sigue instalado y activo.
  • Si la opción se utiliza en todas las peticiones o solo en una sección.
  • Qué cambia después de modificarla.

Plugins que dejan datos después de ser eliminados

Desinstalar un plugin no siempre significa que desaparezca toda la información que creó. Algunos plugins ofrecen una opción específica para eliminar sus tablas y opciones; otros conservan datos para facilitar una reinstalación posterior.

Esto puede ser razonable desde el punto de vista del producto, pero deja residuos cuando se prueban muchas extensiones, se cambia de proveedor o se abandona un theme.

Antes de borrar tablas u opciones hay que confirmar que realmente pertenecen a un componente que ya no se utiliza. Los nombres pueden variar entre versiones y no siempre permiten identificar el origen con seguridad.

Una tabla sin el prefijo habitual del plugin no es automáticamente basura. Del mismo modo, una opción con un nombre desconocido puede ser necesaria para otro componente. La identificación debe apoyarse en la documentación, el código del plugin, el historial de la instalación y una copia recuperable.

Cómo investigar una base de datos que ha crecido

El diagnóstico debería empezar por una fotografía del estado actual. Antes de limpiar, conviene guardar una copia de la base de datos y anotar los tamaños principales.

Después se pueden revisar varias capas:

1. Tamaño de las tablas

Comprueba qué tablas ocupan más espacio y si ese tamaño es coherente con el contenido de la web. En una tienda, las tablas relacionadas con pedidos y metadatos pueden ser grandes por motivos legítimos.

2. Tabla de opciones

Revisa el tamaño de wp_options, el volumen de opciones autoload y los registros con valores especialmente grandes. No modifiques una opción solo porque ocupe mucho: primero hay que saber quién la utiliza.

3. Revisiones y datos temporales

Calcula cuántas revisiones existen y si hay transients caducados en grandes cantidades. Comprueba si el crecimiento vuelve a producirse después de una limpieza controlada.

4. Plugins y themes instalados

Relaciona las opciones y tablas detectadas con los plugins y themes actuales. Busca también componentes desactivados, abandonados o eliminados parcialmente.

5. Medición antes y después

Una optimización debería poder medirse. Compara el tamaño de la base de datos, el tiempo de respuesta, las consultas y el comportamiento de las páginas antes y después del cambio.

Qué no conviene hacer

Hay varias acciones aparentemente rápidas que pueden causar problemas:

  • Borrar directamente filas de wp_options sin identificar su origen.
  • Vaciar todas las revisiones sin conservar una copia previa.
  • Eliminar tablas por el nombre que tienen.
  • Borrar transients durante una operación importante.
  • Optimizar tablas mientras hay procesos de escritura intensivos.
  • Ejecutar una limpieza en producción sin probarla.
  • Confundir el tamaño de la base de datos con la causa única de la lentitud.

Una limpieza agresiva puede eliminar configuraciones, romper plugins o hacer imposible recuperar una función que todavía era necesaria.

La optimización no termina al borrar datos

Si una tabla vuelve a crecer después de limpiarla, el problema no era únicamente la acumulación histórica. Algún plugin, theme, integración o tarea programada está generando datos de forma continua.

En ese caso hay que investigar el origen:

  • Qué componente escribe los registros.
  • Con qué frecuencia lo hace.
  • Si existe una política de caducidad.
  • Si la información se usa realmente.
  • Si puede almacenarse de otra manera.
  • Si existe una caché de objetos persistente adecuada.

La documentación oficial de WordPress recuerda que la caché de objetos persistente puede reducir los viajes repetidos a la base de datos, pero no sustituye a una revisión de las opciones y tablas que se están generando.

Cuándo pedir una revisión técnica

Una revisión especializada puede ser recomendable cuando:

  • La web se ha vuelto lenta sin un cambio evidente.
  • La tabla wp_options ha crecido de forma anormal.
  • Hay muchos plugins instalados y no se conoce su historial.
  • Se ha cambiado varias veces de theme o constructor.
  • La base de datos contiene tablas de componentes que ya no existen.
  • La limpieza anterior produjo errores o no resolvió el problema.
  • La instalación es una tienda o proyecto crítico y no se puede experimentar en producción.

En esos casos, lo importante no es hacer una limpieza genérica, sino relacionar el contenido de la base de datos con el funcionamiento real de la web.

Conclusión

Una base de datos WordPress hinchada puede ser el resultado de años de revisiones, plugins, themes, tareas automáticas y cambios de configuración. No todo lo que ocupa espacio es innecesario, y no todo lo que parece antiguo se puede borrar sin más.

La estrategia segura consiste en medir, identificar el origen, hacer una copia, probar los cambios y volver a medir.

Las revisiones pueden limitarse. Los transients pueden revisarse. Las opciones autoload pueden analizarse. Pero cada acción debe partir de una pregunta sencilla: ¿sé qué dato estoy eliminando y qué componente lo necesita?

Si la respuesta es no, todavía no es el momento de borrar.

¿Necesitas revisar el rendimiento de tu WordPress?

Si tu web se ha vuelto lenta y sospechas que la base de datos, los plugins o la configuración del servidor pueden estar influyendo, puedo ayudarte a analizar el problema y priorizar las mejoras.

→ Ver el servicio de mantenimiento y optimización WordPress

Fuentes