Cómo implementar testing de carga y rendimiento en tu aplicación web a medida antes del lanzamiento

He visto lanzamientos espectaculares hundirse en menos de dos minutos. El producto era bueno, el marketing había hecho su trabajo, y la base de datos se cayó antes de que nadie entendiera por qué. Lanzar una app sin pruebas de carga se parece a abrir un restaurante sin haber probado la cocina con un servicio lleno: con cinco comensales todo va bien, con quinientos descubres los problemas en directo y con público.

En esta guía te cuento cómo implementar testing de carga y rendimiento en tu aplicación web a medida antes del lanzamiento sin teoría innecesaria: qué herramienta elegir según tu equipo, qué métricas miran de verdad los ingenieros que han apagado fuegos en producción, y cómo encajar todo en tu pipeline sin que se convierta en un trámite vacío.

Qué tipo de pruebas necesitas (y para qué sirve cada una)

Las pruebas de rendimiento no son una cosa única. Cada tipo responde a una pregunta distinta, y mezclarlas es el primer paso para sacar conclusiones equivocadas.

Load testing: el escenario normal

Simulan la carga que esperas en un día tranquilo. Si tu hora punta son 200 usuarios concurrentes, lanzas 200 y compruebas que los tiempos de respuesta aguantan. Punto. La pregunta es sencilla: ¿soporta esto el tráfico previsto sin degradarse?

Stress testing: el punto de ruptura

Aquí empujas la aplicación más allá de su capacidad de diseño hasta que algo cede. Lo interesante no es saber cuándo rompe (siempre rompe), sino cómo se comporta al romperse y si vuelve sola a un estado sano cuando baja el pico. Una app que se cae es un problema; una app que se cae y necesita reinicio manual a las 3 de la mañana es un problema mucho peor.

Spike testing: el golpe seco

Un Black Friday no llega con rampa progresiva. Llega de golpe. Una mención en La Resistencia, una notificación push que se manda a 50.000 usuarios a la vez, un tuit que se viraliza. El spike testing simula exactamente eso: pasas de 50 a 5.000 usuarios en cuestión de segundos sin avisar al sistema.

Soak testing: lo que solo aparece con el tiempo

Carga moderada mantenida durante horas o días. Aquí cazas memory leaks, conexiones a base de datos que no se cierran bien, logs que llenan el disco. Son problemas que pasan desapercibidos en una prueba de 10 minutos y aparecen el martes a las cuatro de la tarde cuando llevas tres días sin desplegar.

Herramientas: cuál elegir según tu equipo

k6, mi recomendación por defecto

Si tu equipo escribe JavaScript, k6 es la apuesta segura. Los scripts viven en el mismo repositorio que tu código, se integran con GitHub Actions o GitLab CI sin fricción y consumen pocos recursos. Soporta gRPC, WebSocket y HTTP/2 de serie, algo que ya no es opcional. La curva de aprendizaje de un desarrollador web a k6 es de tarde y media.

Apache JMeter, el clásico que sigue ahí

JMeter no es bonito, pero tiene su sitio. Si tu equipo de QA no programa, la interfaz gráfica les permite diseñar pruebas sin escribir una línea. Y para protocolos antiguos (SOAP, JMS, FTP) sigue siendo el rey. Si tu sistema habla con un mainframe, no busques más.

Gatling, para escenarios complejos

Basada en Scala, con un DSL muy expresivo y unos informes HTML que valen su peso en oro cuando tienes que justificarle a negocio por qué hay que reescribir un endpoint. La curva es más empinada, pero en proyectos grandes con muchos flujos correlacionados compensa.

Locust, si vivís en Python

Modelo de usuarios basado en código Python, distribuye carga entre workers sin complicación. Si tu backend ya está en Python, no introduces una tecnología nueva por la puerta de atrás.

Define los SLOs antes de tocar nada

Este es el paso que más equipos se saltan, y luego se quejan de que las pruebas "no dicen nada". Sin criterios de aceptación, los números son solo números.

Lo mínimo que tienes que dejar fijado por escrito:

• Latencia P95: entre 200 y 500 ms para una app web típica. Por debajo de 200 ms si compites en e-commerce serio.
• Latencia P99: aquí están los usuarios que se acuerdan de tu marca. No los ignores.
• Throughput mínimo: peticiones por segundo que la app tiene que sostener sin que las colas se acumulen.
• Error rate: por encima del 0,1% de 5xx bajo carga normal ya hay que mirar logs.
• Disponibilidad durante la prueba: 99,9% como suelo razonable.

Para fijar valores realistas, cruza tres fuentes: datos históricos si tienes una versión anterior en producción, lo que ofrecen competidores parecidos al tuyo, y los requisitos del negocio. Un dashboard interno de 30 usuarios no necesita los mismos SLOs que la ficha de producto de una tienda en campaña.

Escenarios realistas o no estás probando nada

El error más caro en testing de carga es disparar mil usuarios virtuales al mismo endpoint con el mismo payload. Eso no es una prueba, es un benchmark de un endpoint. El tráfico real no se parece a eso ni por casualidad.

Un escenario decente mezcla:

• Distribución por tipo de acción. En un e-commerce, por ejemplo, podrías repartir 60% navegación, 25% búsqueda, 10% añadir al carrito, 5% compra. Ajusta a tu producto.
• Think time. La gente lee, duda, rellena formularios mal y los corrige. Mete pausas de 2 a 10 segundos entre acciones o estarás midiendo un robot, no a tus clientes.
• Datos variables. Pools de términos de búsqueda, IDs de producto distintos, usuarios diferentes. Si todos buscan "zapatillas", la caché te dará un resultado precioso y completamente falso.
• Flujos completos. Login, navegación, acción principal, logout. No peticiones aisladas.

Y por favor, rampa progresiva: 2-5 minutos subiendo hasta la carga objetivo, 10-30 minutos manteniendo, opcionalmente un pico extra del 20-50% durante cinco minutos, y bajada gradual. Tirar 5.000 usuarios de golpe sin contexto te dice poco sobre el comportamiento real.

Leer los resultados sin engañarte

La media de latencia es una mentira piadosa. Si la mitad de los usuarios responde en 100 ms y la otra mitad en 3 segundos, la media te dirá 1,5 segundos y nadie estará viviendo esa experiencia. Mira siempre percentiles: P50, P90, P95, P99.

La gráfica que importa es throughput contra latencia. Hay un punto en el que la latencia deja de crecer linealmente y se dispara. Ese codo es tu capacidad real, no la que pone el comercial del proveedor cloud.

Separa errores 4xx (problemas del cliente, normalmente no son tuyos) de 5xx (problemas tuyos, casi siempre de capacidad). Y monitoriza CPU, RAM, I/O de disco y conexiones de red en los servidores durante toda la prueba, no después.

Dónde está el cuello de botella casi siempre

La base de datos. Queries sin índice, connection pool agotado, locks por transacciones largas. Activa los slow query logs antes de empezar y revísalos al acabar.

Después, por orden de frecuencia: threads agotados o pausas largas de garbage collection en el servidor de aplicaciones, límites de conexiones simultáneas en el balanceador, APIs de terceros que se saturan con timeouts mal configurados, y cachés que no se pre-calientan o tienen un hit rate ridículo.

Cuándo ejecutar cada cosa en el ciclo

Tres momentos distintos, tres intensidades distintas:

En desarrollo, integra un smoke test ligero en CI. 10-20 usuarios virtuales, 2 minutos, cada merge a la rama principal. No estás validando capacidad, estás cazando regresiones gordas antes de que se cuelen.

En staging, antes de cada release significativo, ejecuta la suite completa contra un entorno que replique producción de verdad: misma infraestructura (o proporcional), datos anonimizados con volumen similar, servicios externos reales o mocks de alta fidelidad, y la misma configuración de red.

Pre-lanzamiento, la semana de antes, una prueba contra el entorno de producción real en horario valle o contra una réplica exacta. Esta es tu última red de seguridad para pillar configuraciones específicas del entorno productivo que no estaban en staging.

Integración con CI/CD que no se vuelva ruido

Un flujo realista con k6 y GitHub Actions: push a feature branch lanza unit tests y un smoke de carga; merge a develop ejecuta la prueba estándar de 5 minutos; deploy a staging dispara la suite completa de 30 minutos con carga, estrés y pico; y antes de release, un soak de 2 a 4 horas.

Lo importante es automatizar el pass/fail. Configura thresholds para que el pipeline falle si el P95 supera tu SLO, si el error rate sube del umbral o si el throughput cae por debajo del mínimo. Sin esto, las pruebas se convierten en un informe que nadie lee.

El coste que nadie te cuenta

El testing de carga no es gratis. Replicar producción duplica costes de cloud durante las pruebas. Las herramientas cloud (k6 Cloud, BlazeMeter) facturan por usuarios virtuales y duración. Diseñar y mantener escenarios consume horas de ingeniería de verdad. Y los datasets realistas requieren mantenimiento continuo.

Para una pyme o una startup, lo pragmático es empezar con k6 o JMeter en local desde un servidor dedicado y saltar a soluciones cloud solo cuando la escala lo pida. No al revés.

Tres lanzamientos que no hicieron pruebas

Una plataforma española de venta de entradas lanzó un festival popular sin spike testing. La base de datos se saturó en 90 segundos, las colas de pago se corrompieron y se vendieron entradas duplicadas. La resolución superó los 200.000 euros.

Una fintech migró de monolito a microservicios sin pruebas end-to-end. Cada servicio pasaba sus tests por separado, pero la latencia acumulada entre llamadas hacía que las operaciones completas tardaran más de 10 segundos. Tuvieron que revertir la migración en producción.

Un e-commerce recibió 15 veces su tráfico habitual en Black Friday. El CDN aguantó perfectamente. El servicio de búsqueda colapsó con más de 50 queries por segundo. Los usuarios veían la home pero no encontraban productos. Las ventas cayeron un 70% sobre el forecast.

Lo que de verdad importa

Si te llevas una sola idea de aquí, que sea esta: las pruebas de rendimiento no son una fase final, son una disciplina continua. Empieza con un smoke test ligero en CI esta misma semana, fija SLOs por escrito antes de la siguiente sprint planning, y construye sobre eso. Vale más un smoke imperfecto corriendo en cada merge que una suite perfecta que se ejecuta dos veces al año.

Si quieres una segunda opinión sobre la estrategia de testing de tu aplicación web a medida, o necesitas una auditoría de rendimiento antes de un lanzamiento crítico, habla con nuestro equipo técnico y te ayudamos a salir a producción sin sorpresas.