ES Pruebas de carga web: cómo preparar una campaña sin que el sitio se caiga
Una campaña no debería estrenarse descubriendo cuántas visitas soporta la web. Antes de enviar tráfico de Google Ads, correo, redes o una promoción estacional, conviene probar los recorridos que generan negocio con una carga gradual, medir dónde aparece la saturación y dejar preparado un plan de respuesta. El objetivo no es presumir de un número máximo de usuarios, sino comprobar que la página, el buscador, el carrito, el pago y los formularios siguen funcionando dentro de unos límites acordados.
Una prueba útil parte de datos reales o de una previsión razonada. También distingue la velocidad que percibe una persona en el navegador del tiempo que necesita el servidor para responder. Si solo se mide uno de los dos lados, una web puede parecer estable mientras el checkout acumula errores, o entregar respuestas rápidas que el navegador tarda demasiado en representar.
El pico de tráfico debe convertirse en un escenario concreto
«Esperamos muchas visitas» no basta para configurar una prueba. Hay que traducir la campaña a un perfil: cuándo comenzará, cuánto durará, si el tráfico llegará de golpe o crecerá de forma progresiva, desde qué lugares y qué porcentaje de usuarios recorrerá cada página. Una mención en televisión produce una subida distinta de una campaña de búsqueda repartida durante varias horas.
La estimación mejora cuando se combinan históricos de analítica, previsiones publicitarias, tamaño de la base de datos de correo y resultados de campañas anteriores. Si no hay antecedentes, se pueden construir varios escenarios y declarar el margen de incertidumbre: carga habitual, pico previsto y una subida breve por encima de lo esperado. Cada escenario necesita un criterio de éxito y otro de parada.
Para una tienda online, el modelo debería incluir al menos la portada o landing, páginas de categoría y producto, búsqueda, carrito, identificación y checkout. En una web de servicios quizá importen más la landing, los casos, el formulario y la descarga de un recurso. Repetir únicamente la página de inicio genera una cifra vistosa, pero no reproduce el trabajo que tendrá que hacer el sistema.
Prueba frontend y backend: responden preguntas diferentes
Las pruebas a nivel de protocolo envían peticiones HTTP y permiten generar gran parte de la carga con menos recursos. Sirven para observar el servidor, las API, la base de datos y las integraciones. Las pruebas con navegador ejecutan la interfaz y miden lo que sucede al cargar, pulsar, escribir y avanzar por un recorrido real. Son más costosas, pero descubren problemas de JavaScript, renderizado e interacción que una petición HTTP aislada no revela.
La documentación de Grafana k6 propone un enfoque híbrido: producir la mayor parte del volumen con peticiones de protocolo y reservar un grupo menor de navegadores para los recorridos completos. Así se comprueba a la vez la capacidad de la infraestructura y la experiencia de usuario. Los scripts deben verificar que llegaron al estado esperado, no limitarse a contar respuestas con código 200.
Un checkout puede devolver una página correcta y, aun así, no aplicar un cupón, perder un producto o dejar bloqueado el botón de pago. Por eso conviene añadir comprobaciones funcionales: contenido esperado, precio coherente, creación de sesión, persistencia del carrito y resultado del envío. Los datos de prueba deben estar identificados y no mezclarse con pedidos reales.
Qué medir para encontrar el cuello de botella
La media es insuficiente porque oculta a los usuarios que reciben las respuestas más lentas. Para cada recorrido interesa observar percentiles de tiempo de respuesta, tasa de errores, peticiones por segundo y operaciones completadas. En paralelo se revisan CPU, memoria, conexiones, colas, consultas a base de datos, límites del alojamiento y tiempos de servicios externos.
El TTFB —tiempo hasta el primer byte— ayuda a detectar esperas antes de que empiece a llegar el contenido. Según web.dev, lo forman el establecimiento de la conexión, la posible negociación TLS, el envío de la petición y el tiempo que tarda el servidor en generar la respuesta. Un TTFB elevado bajo carga puede apuntar a consultas lentas, trabajo excesivo en el servidor, falta de caché o capacidad insuficiente, pero debe interpretarse junto con el resto de métricas.
- Disponibilidad: porcentaje de recorridos que terminan sin errores técnicos ni funcionales.
- Latencia: percentiles acordados para páginas, API y acciones críticas.
- Capacidad: volumen sostenido antes de que las colas y los errores crezcan.
- Experiencia: carga e interacción en navegadores y dispositivos representativos.
- Recuperación: tiempo que necesita el sistema para volver a la normalidad después del pico.
Los umbrales no deben copiarse de otra empresa. Un catálogo estático y una aplicación que calcula disponibilidad en tiempo real tienen costes distintos. Es preferible fijar objetivos por recorrido y relacionarlos con el negocio: cuántos checkouts completos se necesitan, qué porcentaje de error es inaceptable y cuándo se detiene la campaña.
La caché ayuda, pero hay que saber qué se puede guardar
HTTP permite reutilizar respuestas almacenadas y evitar peticiones innecesarias al servidor. MDN distingue cachés privadas, asociadas normalmente a un cliente, y cachés compartidas, que pueden atender a varios usuarios. En una campaña, los recursos estáticos versionados —CSS, JavaScript e imágenes— suelen ser buenos candidatos para una política de caché larga. Las páginas públicas también pueden beneficiarse si la arquitectura lo permite.
No debe aplicarse la misma regla a todo. Carritos, cuentas, precios personalizados, disponibilidad y respuestas con datos personales requieren controles específicos. Una caché mal configurada puede mostrar información antigua o, en el peor caso, entregar a una persona una respuesta destinada a otra. La prueba debe cubrir tanto una caché caliente como el arranque en frío, la invalidación y el despliegue de una nueva versión.
También hay que separar recursos propios y terceros. Analítica, mapas, pagos, chats o gestores de consentimiento tienen sus límites y condiciones. La guía de k6 recomienda no someter a carga servicios ajenos sin autorización. Se pueden simular sus respuestas en un entorno de prueba y hacer verificaciones controladas de integración, pero no generar tráfico masivo contra ellos.
Del ensayo a un plan de contingencia operativo
La corrección puede consistir en optimizar consultas, reducir trabajo síncrono, comprimir recursos, ajustar cachés, limitar operaciones costosas, ampliar capacidad o degradar de forma controlada funciones secundarias. OWASP aconseja identificar páginas intensivas en recursos, evitar puntos únicos de fallo, aplicar límites proporcionados y manejar excepciones de forma que el sistema pueda seguir respondiendo cuando está sometido a presión.
Antes de lanzar la campaña conviene dejar por escrito quién vigila las métricas, quién puede reducir inversión publicitaria, qué alerta obliga a actuar y qué cambio puede ejecutarse sin improvisar. Un plan mínimo incluye contactos, paneles, umbrales, criterios para pausar tráfico, mensajes de contingencia, copia verificable, rollback y una revisión posterior.
- ejecutar una prueba de humo con carga mínima para validar el guion;
- aumentar progresivamente hasta el nivel habitual y mantenerlo;
- probar el pico previsto y un margen adicional acordado;
- observar qué recurso se satura primero y cómo falla el recorrido;
- aplicar correcciones y repetir exactamente el mismo escenario;
- confirmar la recuperación y documentar la capacidad observada.
Las pruebas agresivas deberían realizarse en un entorno representativo siempre que sea posible. Si la única opción es producción, se reduce la carga, se elige una franja controlada, se activa la monitorización y se acuerdan criterios de parada. Un resultado obtenido en un entorno poco parecido tampoco puede presentarse como garantía de producción.
Checklist antes de activar la campaña
Comprueba que existe una previsión de tráfico con supuestos explícitos, una lista de recorridos prioritarios, datos de prueba, umbrales por recorrido y visibilidad sobre servidor, aplicación y servicios externos. Verifica la política de caché, el comportamiento del checkout, los límites de formularios y búsquedas, la capacidad de rollback y el canal de coordinación durante el lanzamiento.
En proyectos de desarrollo web, estos requisitos pueden incorporarse desde la arquitectura y la preparación del despliegue. Si la web ya está operativa, las pruebas y correcciones se coordinan con el soporte técnico y el servicio de mantenimiento del sitio. Para valorar un lanzamiento concreto, puede iniciarse la conversación desde contacto.
Preguntas frecuentes sobre pruebas de carga y VOWE
¿Puede VOWE preparar una web existente para un pico de tráfico?
Sí. Dentro del soporte técnico y el desarrollo web, VOWE puede revisar la arquitectura, identificar recorridos críticos, proponer un escenario de carga y corregir los cuellos de botella detectados. El alcance depende de la tecnología, el alojamiento, los servicios externos y los accesos disponibles.
¿Es seguro hacer una prueba de carga directamente en producción?
Una prueba intensa en producción puede afectar a usuarios reales. Siempre que sea posible se utiliza un entorno representativo; si hay que validar producción, se acuerdan una carga limitada, una franja controlada, monitorización activa y criterios de parada. Tampoco se incluyen servicios de terceros sin permiso.
¿Qué necesita VOWE para plantear la prueba?
Para una primera valoración hacen falta la URL, la tecnología y el alojamiento, las fechas de la campaña, una estimación razonada del tráfico, los recorridos prioritarios y el acceso a métricas técnicas. No es necesario enviar contraseñas ni secretos mediante el formulario de contacto.
Fuentes y límites de esta guía
Este artículo sintetiza la guía de Grafana k6 para pruebas de carga web, la documentación de MDN sobre caché HTTP, la explicación de web.dev sobre TTFB y la guía de OWASP sobre resistencia ante denegación de servicio. Las cifras y los umbrales deben definirse para cada arquitectura y campaña; una prueba no garantiza que nunca se produzca una incidencia.
