Dominios, comandos y eventos: el mapa del protocolo

El protocolo tiene decenas de dominios y cientos de métodos, y recorrer esa lista no es forma de aprenderlo. La estructura, en cambio, es muy regular: dominios que agrupan métodos por área funcional, un patrón de activación que hay que conocer para que nada funcione a la primera, y unos pocos dominios que cubren casi todo lo que se hace en la práctica. Con esa estructura y el monitor del panel, encontrar el comando que necesitas deja de ser un problema.

La estructura

Un método del protocolo se nombra como dominio y operación separados por un punto. El dominio agrupa por área: uno para el árbol del documento, otro para la red, otro para la ejecución de código, otro para el depurador, y así.

El patrón de activación previa es la primera cosa que hay que saber, porque explica por qué nada funciona al principio. La mayoría de los dominios que emiten eventos requieren que se les active explícitamente antes de recibir nada. Sin esa activación, los comandos de consulta pueden funcionar y los eventos no llegan nunca. Es el error número uno de quien empieza.

La activación tiene además un coste: un dominio activado hace que el navegador registre y envíe información que de otro modo no produciría, y eso afecta al rendimiento de lo que estés midiendo. Activar el dominio de red mientras se graba un perfil de rendimiento cambia el perfil.

Los dominios que cubren casi todo

De esa lista, los cuatro primeros y el de emulación cubren la práctica totalidad de la automatización habitual.

Cuatro capacidades sin equivalente en la interfaz

Uno: ejecutar código antes que cualquier otra cosa de la página. Hay un comando que registra un script para que se ejecute en cada documento nuevo, antes de cualquier script de la página. Es la forma de instrumentar el arranque, de sustituir APIs antes de que nadie las use, o de fijar condiciones deterministas.

// Instrumentar el arranque de cualquier pagina antes de que ejecute nada
await cliente.enviar('Page.addScriptToEvaluateOnNewDocument', {
  source: `
    // Fijar el tiempo para hacer deterministas las pruebas
    const AHORA = new Date('2026-08-06T09:00:00Z').getTime();
    const FechaOriginal = Date;
    globalThis.Date = class extends FechaOriginal {
      constructor(...args) { return args.length ? new FechaOriginal(...args) : new FechaOriginal(AHORA); }
      static now() { return AHORA; }
    };

    // Fijar el generador aleatorio
    let semilla = 42;
    Math.random = () => { semilla = (semilla * 1103515245 + 12345) % 2147483648; return semilla / 2147483648; };

    // Registrar todos los errores desde el primer instante
    globalThis.__errores = [];
    addEventListener('error', e => globalThis.__errores.push({ tipo: 'error', mensaje: e.message, fuente: e.filename }));
    addEventListener('unhandledrejection', e => globalThis.__errores.push({ tipo: 'promesa', mensaje: String(e.reason) }));
  `
});

Fijar el tiempo y el generador aleatorio es lo que convierte una prueba visual inestable en una determinista, y es imposible de conseguir desde la propia página porque el código de la aplicación ya ha capturado las referencias originales.

Dos: interceptar y modificar peticiones. El dominio de interceptación permite pausar una petición antes de que salga, modificar su URL, sus cabeceras o su cuerpo, o responderla directamente sin que llegue a la red.

// Simular respuestas de API sin tocar el codigo ni levantar un servidor
await cliente.enviar('Fetch.enable', {
  patterns: [{ urlPattern: '*/api/*', requestStage: 'Request' }]
});

cliente.al('Fetch.requestPaused', async ({ requestId, request }) => {
  if (request.url.includes('/api/usuarios')) {
    const cuerpo = JSON.stringify([{ id: 1, nombre: 'Prueba' }]);
    await cliente.enviar('Fetch.fulfillRequest', {
      requestId,
      responseCode: 200,
      responseHeaders: [{ name: 'Content-Type', value: 'application/json' }],
      body: Buffer.from(cuerpo).toString('base64')
    });
    return;
  }
  if (request.url.includes('/api/lento')) {
    await new Promise(r => setTimeout(r, 5000));   // simular latencia extrema
  }
  await cliente.enviar('Fetch.continueRequest', { requestId });
});

Esa capacidad convierte cualquier escenario de error de servidor en algo reproducible en un segundo: respuestas de error, respuestas malformadas, latencias extremas, respuestas vacías.

Tres: emular condiciones que no están en ningún menú. Ralentización de CPU con valores arbitrarios, métricas de dispositivo con cualquier combinación, características de medios concretas, zonas horarias, idiomas, geolocalización.

Cuatro: controlar la recolección de basura. Forzar una recolección desde código es lo que hace posible automatizar la detección de fugas.

// Deteccion automatizada de fugas: el ciclo de los tres snapshots, en CI
async function detectarFuga(cliente, ciclo, vueltas = 10) {
  await cliente.enviar('HeapProfiler.enable');

  const medirMonton = async () => {
    await cliente.enviar('HeapProfiler.collectGarbage');
    const { result } = await cliente.enviar('Runtime.evaluate', {
      expression: 'performance.memory ? performance.memory.usedJSHeapSize : 0',
      returnByValue: true
    });
    return result.value;
  };

  await ciclo();                       // calentamiento: inicializa lo perezoso
  const base = await medirMonton();

  for (let i = 0; i < vueltas; i++) await ciclo();
  const despues = await medirMonton();

  const crecimientoMB = (despues - base) / 1048576;
  const porCiclo = crecimientoMB / vueltas;
  console.log('Crecimiento total:', crecimientoMB.toFixed(2), 'MB |',
    'por ciclo:', (porCiclo * 1024).toFixed(1), 'KB');
  return { crecimientoMB, porCicloKB: porCiclo * 1024 };
}

El ciclo de calentamiento antes de la medida base es lo que evita el falso positivo de la inicialización perezosa, exactamente por la misma razón que la técnica de las tres instantáneas necesita tres.

Encontrar el comando que necesitas

El método fiable no es leer la documentación entera sino este procedimiento de tres pasos.

Uno: haz la acción a mano en las DevTools con el monitor de protocolo abierto.

Dos: lee el comando que se envió, con sus parámetros exactos.

Tres: búscalo en la documentación del protocolo para conocer el resto de sus parámetros y su respuesta completa.

Ese recorrido convierte una búsqueda en un espacio enorme en una lectura dirigida, y es lo que hace viable trabajar con el protocolo sin memorizar nada.