¿Qué pasaría si tu sitio WordPress aparece en las noticias mañana y recibe 100 veces el tráfico habitual? Para la mayoría de los sitios sin preparación, el resultado es una caída que dura horas y pérdida de la oportunidad exacta en el momento en que más importaba. Las pruebas de carga son la única forma de saber, antes de que pase, cuánto tráfico puede manejar tu sitio y dónde está el cuello de botella.

Por qué los sitios WordPress se caen bajo carga

WordPress es una aplicación PHP dinámica: cada visita ejecuta código PHP, hace consultas SQL y genera el HTML en tiempo real (a menos que esté correctamente cacheado). Bajo carga alta, el cuello de botella puede estar en cualquier punto de este flujo: el servidor PHP-FPM puede quedarse sin workers disponibles, la base de datos MySQL puede saturarse con conexiones concurrentes, o el servidor web puede agotar sus conexiones máximas.

La caché resuelve gran parte del problema para contenido estático, pero los sitios con áreas dinámicas (WooCommerce, membresías, formularios) tienen páginas que no pueden cachearse y son vulnerables bajo carga.

Herramientas de prueba de carga para WordPress

• k6: Herramienta open source de Grafana, scripts en JavaScript, excelente integración con pipelines de CI/CD. La opción más recomendada para equipos técnicos.
• Locust: Framework Python para pruebas de carga, muy flexible para definir comportamientos de usuario complejos.
• Artillery: Alternativa a k6, scripts en YAML o JavaScript, con soporte para WebSockets y Socket.io.
• Gatling: Orientado a pruebas de performance a escala enterprise, reportes detallados.
• Load Impact / k6 Cloud:

Cómo diseñar una prueba de carga realista

Una prueba de carga mal diseñada puede dar una falsa sensación de seguridad. La clave es simular tráfico que se parezca al real: no 1000 usuarios pidiendo todos la misma URL al mismo tiempo, sino 1000 usuarios navegando por diferentes páginas, con tiempos de pausa entre peticiones similares a los de usuarios reales.

El proceso recomendado: primero, identificar las 10-20 URLs más visitadas del sitio (de Google Analytics). Segundo, crear un script de carga que visite esas URLs en las proporciones reales. Tercero, empezar con carga baja e ir aumentando gradualmente mientras se monitorean las métricas del servidor.

Qué métricas monitorear durante la prueba

En el servidor: uso de CPU, memoria, cantidad de workers PHP-FPM activos, conexiones activas a MySQL y número de queries por segundo. En la base de datos: slow query log para identificar consultas que degradan bajo carga. En el servidor web: porcentaje de errores 5xx, tiempo de respuesta promedio y percentil 95.

New Relic, Datadog o la combinación Prometheus + Grafana son las herramientas de monitoreo más completas para capturar todas estas métricas en tiempo real durante la prueba.

En Octopus Agencia Digital preparamos sitios WordPress para soportar picos de tráfico. Si tenés un evento, lanzamiento o campaña que podría generar mucho tráfico, contactanos con anticipación.