---
title: "Módulo navegador k6: cuándo sumar métricas de navegador real a pruebas de carga API"
description: "Módulo navegador k6 para Core Web Vitals + latencia API: escenarios Chromium, cuándo emparejar con pruebas HTTP y docs oficiales k6 browser."
publishDate: "2026-06-25"
draft: false
keyword: "modulo navegador k6 pruebas carga api"
intent: "TOFU"
cta: "Explora cómo Performate simplifica las pruebas de carga con k6, desde imports hasta resultados, para que tu equipo publique con más confianza en rendimiento."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "navegador", "module"]
translationOf: k6-browser-module-api-load-tests
---

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](https://k6.io/docs/using-k6/browser/) 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`](https://k6.io/docs/using-k6/metrics/) 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](/es/blog/presupuesto-rendimiento-frontend-api)). Alinea umbrales con [p95 vs p99](/es/blog/p95-vs-p99-latencia) 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.

```javascript
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](/es/blog/tipos-escenarios-k6-explicados)).
- **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](/es/blog/k6-observabilidad-metricas-tags)).

**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):**

```bash
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

| Situación | Acción recomendada |
|:---|:---|
| API JSON interna, sin gate UI | Solo HTTP k6 |
| Checkout SPA con SLO vitals | Híbrido: browser bajo-VU + carga API HTTP |
| Regresión LCP landing marketing | Smoke solo browser; 1–3 VUs |
| Shell WebView móvil + APIs | Híbrido; tag `client:webview` en HTTP si aplica |
| CI en cada commit | Smoke HTTP; job browser semanal |

**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](/es/blog/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](https://performate.app) | [Reserva una demo](/demo) | [Módulo browser k6](https://k6.io/docs/using-k6/browser/)