Módulo navegador k6: cuándo sumar métricas de navegador real a pruebas de carga API

Tu prueba de carga API muestra p95 bajo 400 ms—pero usuarios dicen que checkout se siente lento. La brecha suele ser trabajo client-side: bundles JS, layout y tags de terceros que k6 HTTP-only nunca ejecuta. El módulo navegador k6 controla Chromium real para medir Core Web Vitals junto con latencia backend—sin reemplazar tus escenarios HTTP.

Pruebas de carga con navegador no son «correr todo en Selenium». Es una capa targeted para flujos donde el render domina rendimiento percibido, emparejada con tests HTTP que escalan barato. En esta guía verás cuándo importan métricas de navegador, cómo combinar escenarios browser y API en una corrida k6, y qué señales justifican el CPU extra—no solo Lighthouse en localhost.

Por qué tests solo HTTP pierden latencia visible al usuario

SLOs backend pueden estar verdes mientras la experiencia degrada:

• Bundles JS grandes bloquean interactividad aunque /api/cart sea rápido.
• Routing client-side dispara waterfalls que scripts HTTP modelan como calls aislados—no grafo de navegación real.
• Scripts de terceros (analytics, iframe pagos) suman trabajo en main thread invisible a http.get plano.
• Hydration y SSR mueven trabajo entre servidor y navegador; tests solo API ven un lado.
• Gates Core Web Vitals (LCP, INP) requieren APIs de navegador—http_req_duration no sustituye.

Piensa en rendimiento como restaurante: tests API miden tiempo de ticket de cocina; tests browser miden plato-a-mesa—incluyendo garnish y presentación.

Cuándo emparejar browser con escenarios HTTP

Usa browser k6 en paths UX críticos (login, shell checkout, first paint dashboard) y HTTP k6 en superficies API alto volumen (presupuesto rendimiento frontend + API). Alinea umbrales con p95 vs p99 en ambas capas.

Implementación práctica en k6: escenarios híbridos browser + HTTP

Corre escenario browser bajo-VU para Core Web Vitals y escenario HTTP alta tasa para throughput API en el mismo bloque options.scenarios.

Script de ejemplo (ilustrativo—no listo para producción). Requiere k6 con soporte browser. Adapta URLs y selectores.

Qué demuestra este ejemplo:

• Escenarios browser y HTTP paralelos: executor browser a 2 VUs para UI checkout; constant-arrival-rate a 30 req/s para API cart.
• Checks estilo Web Vitals: page.goto con wait y locators aproximan timing de path crítico LCP.
• Base URL compartida vía env: un target staging para ambas capas—correlación más fácil en reportes.
• Umbrales separados por capa: SLOs HTTP más estrictos; p95 browser relajado reflejando overhead Chromium.

import http from 'k6/http';
import { browser } from 'k6/browser';
import { check, sleep } from 'k6';

const BASE = __ENV.APP_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    checkout_browser: {
      executor: 'constant-vus',
      vus: 2,
      duration: '5m',
      options: { browser: { type: 'chromium' } },
      exec: 'browserCheckout',
      tags: { layer: 'browser', flow: 'checkout' },
    },
    cart_api: {
      executor: 'constant-arrival-rate',
      rate: 30,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 10,
      maxVUs: 40,
      exec: 'cartApi',
      tags: { layer: 'http', route: 'cart' },
    },
  },
  thresholds: {
    'http_req_duration{layer:http}': ['p(95)<450'],
    'browser_web_vital_lcp{layer:browser}': ['p(95)<2500'],
  },
};

export async function browserCheckout() {
  const page = await browser.newPage();
  try {
    await page.goto(`${BASE}/checkout`, { waitUntil: 'networkidle' });
    await page.locator('[data-testid="pay-button"]').waitFor({ state: 'visible' });
    check(page, { 'checkout shell visible': () => true });
    sleep(2);
  } finally {
    await page.close();
  }
}

export function cartApi() {
  const res = http.get(`${BASE}/api/v1/cart`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { layer: 'http', route: 'cart' },
  });
  check(res, { 'cart 2xx': (r) => r.status >= 200 && r.status < 300 });
}

Patrones que funcionan

• Mantén VUs browser bajos (1–5)—Chromium es CPU-heavy; escala APIs con HTTP (tipos escenario k6).
• Selectores estables: preferí data-testid sobre CSS frágil—misma disciplina que E2E.
• Smokes browser en CI programados, no cada PR—costo y flake.
• Correlaciona tags layer:browser|http en Grafana o reportes Performate (tags observabilidad k6).

Anti-patrones a evitar

• Reemplazar todos los tests HTTP por browser—costo explota, señal se ahoga.
• Maxear VUs browser para «simular carga»—usa arrival rate HTTP para esa pregunta.
• Ignorar auth en flujos browser—refleja cookie o token setup de usuarios reales.

Pro tip (comando de ejemplo):

K6_BROWSER_ENABLED=true k6 run hybrid-checkout.js --summary-trend-stats="p(95),p(99)"

Qué demuestra este comando: habilita escenarios Chromium localmente o en agents CI con binarios browser.

Marco de decisión: solo HTTP vs híbrido vs solo browser

Usa solo HTTP si releases gatean latencia API sin compromisos vitals client-side.

Usa híbrido si producto trackea LCP/INP y SLOs API juntos—mayoría ecommerce y dashboards SaaS.

Usa solo browser si el riesgo es enteramente front-end (sitio estático, landing) con superficie API mínima.

Observabilidad, documentación y próximos pasos

Tests híbridos solo ayudan si equipos saben qué capa falló. Antes de escalar:

• Documenta cap VU browser, requisitos CPU agent, y path instalación Chromium en runbook.
• Alerta umbrales browser_web_vital_* separados de HTTP—owners distintos pueden aplicar.
• Correlaciona tags layer:* con RUM en las mismas rutas.
• Automatiza smoke HTTP cada merge; programa smokes browser (pruebas de carga en CI/CD).
• Archiva JSON escenario y lista selectores cuando UI refactoriza—actualiza script browser en mismo PR.

Cómo Performate simplifica testing híbrido browser + API

Saltar entre Lighthouse, HTTP k6 y hojas divide ownership. Abajo un ejemplo de flujo concreto para testing híbrido checkout.

Ejemplo: un workspace para carga cart API y vitals checkout

1. Importa requests Postman cart API y mantén checkout browser como lista URL documentada con selectores en notas de escenario. Problema resuelto: verdad API en colección; path browser explícito.
2. Crea escenario HTTP cart_api a 30 req/s con bearer token desde env. Problema resuelto: carga escalable sin costo Chromium.
3. Agrega escenario browser checkout_shell a 2 VUs con URL target y notas umbral LCP. Problema resuelto: path vitals visible para QA sin tool separada.
4. Taggea escenarios layer:http y layer:browser para reportes filtrados. Problema resuelto: mismo modelo tags del ejemplo k6.
5. Corre suite híbrida pre-release y revisa reporte integrado con producto/diseño. Problema resuelto: un export para sign-off perf backend y frontend.
6. Exporta script k6 para smoke HTTP CI; job browser nightly en agents con K6_BROWSER_ENABLED=true. Problema resuelto: gates PR rápidos más cobertura vitals.

Ese flujo mapea al cta: imports hasta resultados en un flujo de escritorio.

Cierre

Browser k6 es instrumento de precisión, no reemplazo de load tests HTTP. Empareja escenarios Chromium bajo-VU en paths UX críticos con escenarios API alta tasa, taggea capas por separado, y gatea releases en ambos cuando Core Web Vitals son parte del contrato.

Corre el smoke híbrido de checkout esta semana—anota si API p95 o LCP se movió primero cuando usuarios reportaron lentitud.

Try Performate free | Reserva una demo | Módulo browser k6