"¿Aguanta el Buen Fin?" es la pregunta que todo dueño de tienda en línea hace en octubre, y casi siempre se responde con una opinión: "debería", "el año pasado sí", "el proveedor dice que sí".
Se puede responder con un número. Esta guía es para conseguirlo.
Qué es una prueba de carga, en corto
Simular muchos visitantes simultáneos para ver a partir de qué punto tu sitio se degrada. No es una prueba de si funciona: es una prueba de hasta dónde funciona.
El resultado que buscas es una frase concreta: "Mi tienda responde bien hasta X usuarios simultáneos; a partir de ahí los tiempos se disparan y el cuello de botella es Y."
Con eso puedes decidir. Sin eso, estás apostando.
Paso 0: avisa antes de lanzar nada
Y dos precauciones más: nunca pruebes contra un sitio que no es tuyo, y hazlo fuera del horario comercial.
Paso 1: consigue tu línea base
No se puede medir un aumento sin saber el punto de partida.
De tu herramienta de analítica, saca los números de tu mejor hora de un día normal:
- Visitas por hora
- Páginas vistas por hora
- Pedidos por hora
- Reparto entre móvil y escritorio
Usa el pico, no el promedio diario. En temporada alta el tráfico se concentra en las horas de la promoción; un promedio diario oculta exactamente el momento que te va a tumbar.
Paso 2: define el escenario
Un error común es probar solo la página de inicio. Es la más ligera y la menos representativa.
Una prueba útil simula el recorrido completo de compra, con un reparto realista:
| Paso | Peso típico | Por qué importa |
|---|---|---|
| Página de inicio o categoría | 40% | Entrada, normalmente cacheable |
| Búsqueda de producto | 20% | Golpea la base de datos |
| Ficha de producto | 25% | Consulta existencia en vivo |
| Agregar al carrito | 10% | Escribe en la sesión |
| Iniciar checkout | 5% | Lo más pesado del sitio |
Ese último 5% es el que decide todo. El checkout casi nunca se puede cachear: consulta inventario, calcula envío, habla con la pasarela. Si tu prueba no lo incluye, no estás probando tu tienda.
Paso 3: elige la herramienta
Para una tienda de empresa mediana no hace falta nada sofisticado:
- k6 — escribes el escenario en un archivo de texto, corre desde línea de comandos, reportes claros. Es la opción que mejor equilibra esfuerzo y resultado.
- Apache Bench (ab) — viene instalado en casi cualquier Linux. Sirve para una primera medición rápida de una sola URL.
- Servicios en la nube — varios ofrecen pruebas básicas gratuitas. Útiles porque el tráfico llega desde fuera, como el real.
Si nadie en tu equipo puede escribir un escenario, empieza con Apache Bench contra tres URL: inicio, una ficha de producto y la búsqueda. Es tosco y ya te dice mucho.
Paso 4: sube la carga por escalones
No arranques con mil usuarios. Sube por escalones y anota dónde cambia el comportamiento:
| Escalón | Usuarios simultáneos | Qué observas |
|---|---|---|
| 1 | Tu pico normal | Debe verse como un día cualquiera |
| 2 | 2× | Los tiempos suben poco |
| 3 | 3× | Aquí empieza a notarse |
| 4 | 5× | El objetivo de temporada alta |
| 5 | Hasta que falle | Tu techo real |
En cada escalón, registra tres cosas:
- Tiempo de respuesta promedio y el del 95% de las peticiones. El promedio miente; el percentil 95 es la experiencia de la cola.
- Porcentaje de errores. Cualquier cosa arriba de 1% ya es visible para los clientes.
- Consumo del servidor: procesador, memoria y conexiones a base de datos.
Paso 5: lee los resultados
Los números que importan, con su interpretación honesta:
| Tiempo de respuesta | Qué significa |
|---|---|
| Menos de 1 s | Bien |
| 1 – 3 s | Aceptable; se empiezan a perder compras |
| 3 – 8 s | Malo; abandono notable |
| Más de 8 s | Equivale a estar caído |
Y el patrón de la curva dice más que el número suelto:
- Sube parejo con la carga → falta capacidad; es el caso más simple.
- Se dispara de golpe en un punto → hay un límite duro: conexiones a base de datos, procesos del servidor web, memoria. Es el caso más común.
- Sube y baja sin patrón → hay competencia por un recurso, típicamente la base de datos.
Paso 6: arregla en el orden correcto
Aquí es donde se gasta mal el dinero. El orden que rinde:
1. Imágenes. La causa más frecuente y la más barata. Fotos de producto de 3 MB servidas sin comprimir hunden cualquier sitio. Comprimir y servir en formato moderno es cuestión de horas y suele resolver la mitad del problema.
2. Caché. Si tu tienda genera cada página desde cero en cada visita, estás haciendo mil veces el mismo trabajo. Una capa de caché para páginas de catálogo —nunca para carrito ni checkout— multiplica la capacidad sin tocar el servidor.
3. Base de datos. Consultas lentas, búsquedas sin índice, complementos que consultan de más. Es el punto que requiere ayuda técnica, y el que más rinde en tiendas con catálogo grande.
4. Capacidad del servidor. Hasta el final. Es lo más caro, lo que más tarda y lo que menos resuelve si el problema estaba en los tres puntos anteriores.
Paso 7: vuelve a probar
Corrección aplicada, prueba repetida, número nuevo. Sin esa segunda medición no sabes si arreglaste algo o solo moviste el problema.
Y documenta el resultado final en una línea: "La tienda aguanta N usuarios simultáneos con tiempos por debajo de 2 segundos." Esa frase es lo que le entregas a dirección, y lo que te permite decidir con tranquilidad en noviembre.
Cuándo hacerla
Tres semanas antes del evento, no la semana previa. Necesitas margen para corregir y volver a probar. Si el Buen Fin es del 13 al 17 de noviembre, la prueba va a más tardar el 23 de octubre — que es justo la fecha de el checklist completo de preparación.
Y si la prueba revela que el problema no es capacidad sino que tu inventario no está sincronizado o que tu tienda tiene complementos sin actualizar, mejor: esos son problemas peores y se arreglan antes de que lleguen los clientes.
Rendimiento y capacidad
Sabe cuántos clientes aguanta tu tienda, con número
Ejecutamos la prueba de carga, identificamos el cuello de botella real y te entregamos el plan de corrección con esfuerzo y prioridad.
