El sitio que heredamos
Un sitio de comparación de seguros llegó funcionando en WordPress con más de 30 plugins activos, una base de datos de 705 MB y un Largest Contentful Paint de 7.7 segundos. Nada de esto es exótico. Es el patrón del exceso de plugins, un plugin instalado por problema hasta que el stack colapsa bajo su propio peso, y es exactamente lo que los proyectos rápidos y asistidos por IA siguen produciendo. Este es un teardown de lo que estaba realmente mal y de lo que lo arregló.
El exceso de plugins rara vez se anuncia. Ningún plugin individual es el villano. El sitio funciona, lento, hasta que alguien lo mide y descubre que el coste es acumulativo: cada plugin añade consultas, scripts, estilos, una obligación de actualización y una porción de superficie de ataque, y treinta de ellos juntos convierten un simple sitio de contenido en algo que tarda casi ocho segundos en pintarse.
El peor culpable era un contador de visitas
El mayor problema individual no era un page builder pesado ni una imagen. Era un contador de visitas. El sitio contaba las visitas de los artículos incrementando un valor en wp_postmeta en cada carga, de forma síncrona, dentro de la petición. wp_postmeta es una tabla general de clave-valor que WordPress lee constantemente; no está construida para una escritura de alta frecuencia en cada visita. Dejado funcionando, ese único mecanismo había hecho crecer wp_postmeta hasta 322 MB de la base de datos de 705 MB.
El daño no es solo el disco. Una wp_postmeta inflada y caliente ralentiza una gran parte de las consultas normales de WordPress, porque gran parte del sistema lee de ella. Así que una función en la que nadie pensó, un conteo de visitas, gravaba silenciosamente cada página. Eliminar la escritura síncrona y contar las visitas correctamente devolvió a esa tabla un tamaño razonable y quitó carga de cada petición.
El exceso también es una historia de seguridad
El número de plugins no solo costó velocidad. Amplió la superficie de ataque de las formas previsibles:
- Un endpoint
xmlrpc.phpabierto, un vector clásico para brute-force y amplificación. - Errores PHP mostrados en producción, filtrando rutas del servidor (divulgación de información).
- Plugins con vulnerabilidades conocidas, porque los plugins abandonados o no actualizados dejan de recibir parches.
Por eso recortar el número de plugins es una medida de seguridad, no solo de rendimiento. Cada plugin que eliminas es código en el que ya no tienes que confiar, vigilar y actualizar. Es la misma lógica que hay detrás de una auditoría de seguridad WordPress bien hecha: menos superficie, menos vías de entrada.
Qué lo arregló realmente
La corrección fue poco vistosa y eficaz:
- Auditar cada plugin frente a lo que realmente hacía, luego eliminar los solapamientos y los abandonados, y sustituir las pequeñas tareas de plugins por unas pocas líneas de código del tema.
- Reescribir el contador de visitas para que dejara de escribir en
wp_postmetaen cada petición, lo que permitió a la base de datos encogerse de nuevo. - Mover más de 1.5 GB de PDFs estáticos del servidor de aplicación al almacenamiento de objetos Cloudflare R2, para que el VPS no sirviera archivos grandes que no le correspondía servir.
- Añadir una caché de objetos Redis para que las consultas repetidas llegaran a la memoria en lugar de a la base de datos, aliviando el VPS de 3 vCPU.
- Cerrar
xmlrpc.php, desactivar la exhibición de errores en producción y llevar los plugins restantes a versiones parcheadas.
Nada de esto es ingenioso. Es disciplina aplicada a un stack que no tenía ninguna, y es el grueso de lo que el verdadero trabajo de Core Web Vitals resulta ser cuando se mira más allá de la puntuación de laboratorio.
Por qué los proyectos asistidos por IA siguen recreando esto
El exceso de plugins es anterior a la IA. Pero los asistentes de IA lo empeoran de una forma específica: cuando la respuesta a cada requisito es “instala un plugin para eso”, la deuda se acumula más rápido, porque sugerir un plugin es el camino de menor resistencia para un asistente igual que para una persona con prisa. Acabas con el mismo stack de 30 plugins, solo que montado en una tarde. Por eso este teardown se enmarca en nuestro trabajo más amplio de rescate de webs hechas por IA: ya venga el exceso de una persona o de un prompt, la limpieza es idéntica, auditar, eliminar, sustituir por código dirigido y medir.
Glosario
- wp_postmeta - una tabla central de WordPress que almacena metadatos de clave-valor para las entradas; leída con mucha frecuencia, por lo que inflarla ralentiza todo el sitio.
- Caché de objetos (Redis) - un almacén en memoria que guarda los resultados de consultas repetidas a la base de datos para que no lleguen a la base de datos cada vez.
- Almacenamiento de objetos (Cloudflare R2) - almacenamiento para archivos estáticos como PDFs e imágenes, servidos de forma independiente del servidor de aplicación.
- LCP (Largest Contentful Paint) - cuánto tarda en renderizarse el elemento visible más grande; una medida central de la velocidad de carga percibida.
La conclusión
Si tu sitio WordPress ha pasado de una docena o dos de plugins, el coste casi nunca es un culpable obvio. Es la acumulación, más uno o dos mecanismos silenciosos, un contador de visitas, un log sin indexar, una llamada de API síncrona, que causan daño real en segundo plano. La corrección es contar los plugins, encontrar el mecanismo que escribe en cada petición y mover el peso estático pesado fuera del servidor de aplicación. Un sitio a 7.7 segundos no está perdido. Suele ser un stack que nadie ha auditado, lo que es un problema muy distinto y mucho más barato de lo que parece.
