Qué medir en cada commit y qué medir cada noche

La tentación es ejecutarlo todo siempre, y produce un sistema que tarda veinticinco minutos por petición de cambios, que la gente aprende a saltarse y que acaba desactivado por lento antes de que llegue a desactivarse por ruidoso. El reparto correcto no lo decide la exhaustividad sino dos restricciones duras: cuánto tiempo puede tardar una comprobación sin que la gente la esquive, y cuánto ruido puede tener sin perder credibilidad. Con esas dos restricciones, el reparto se deduce casi solo.

La pirámide

Cuatro niveles. La regla que los ordena: cuanto más frecuente, más rápido y más determinista.

Los presupuestos de tiempo no son orientativos. Una comprobación que tarda más de dos minutos en cada commit hace que la gente deje de esperar y empiece a integrar sin mirar; una que tarda más de diez en una petición de cambios se salta con una etiqueta de urgencia que enseguida se convierte en costumbre. El límite lo pone la paciencia humana y no negocia.

Nivel 1, cada commit. Todo determinista y calculado sobre los artefactos de la compilación, sin arrancar ningún navegador. Bytes por fragmento con presupuesto, número de fragmentos, dependencias nuevas, y comprobaciones estáticas del tipo “esta biblioteca no se puede importar desde el paquete de entrada”. Esto último se hace muy bien con una regla de análisis estático y es de lo más eficaz que existe:

{
  "rules": {
    "no-restricted-imports": ["error", {
      "paths": [
        {
          "name": "libreria-de-graficas",
          "message": "Solo con import dinamico dentro de la ruta de informes."
        },
        {
          "name": "libreria-de-fechas",
          "message": "Usa Intl.DateTimeFormat. Ver docs/rendimiento/fechas.md."
        }
      ],
      "patterns": [
        {
          "group": ["libreria-de-iconos"],
          "message": "Importa el icono concreto, no el paquete entero."
        }
      ]
    }]
  }
}

Estas reglas son extraordinariamente eficaces porque fallan en el editor, antes de compilar, con un mensaje que dice exactamente qué hacer. No hay comprobación de rendimiento más barata ni más rápida que una que se ejecuta mientras la persona escribe.

Nivel 2, cada petición de cambios. Aquí va la auditoría entrelazada con la rama base, cinco pasadas de cada, sobre las tres o cuatro rutas más importantes. El resultado es un comentario con la diferencia y su intervalo, y no rompe el trabajo, por lo visto sobre falsos positivos. Su función es informar a quien revisa, no bloquear.

Nivel 3, cada noche. Aquí cabe todo lo que es demasiado lento o demasiado ruidoso para las peticiones de cambios. Es el nivel donde se ejecutan las cosas que de verdad se parecen a la realidad, y merece detalle.

Nivel 4, continuo. Los datos reales. Es el único nivel que mide lo que de verdad pasa, y por eso es el que manda cuando los cuatro se contradicen.

La ejecución nocturna

Sin presión de tiempo, la ejecución nocturna puede hacer lo que las otras no. Cinco cosas que merecen estar ahí:

Todas las rutas, no una muestra. Una plantilla que casi nadie mira puede tener una regresión durante meses sin que ninguna comprobación de nivel 2 la vea.

Dispositivos reales en redes reales. Un servicio de pruebas con teléfonos físicos en varias localizaciones. Es la única medida del conjunto que se parece a un usuario, y su valor no está en el número absoluto sino en la serie temporal.

Sesiones largas. Un recorrido guiado de diez minutos con navegación entre rutas, midiendo el INP a lo largo del tiempo y la memoria al final. Es donde aparecen la degradación térmica, las fugas y el crecimiento del DOM, que ninguna carga de treinta segundos detecta. Con lo visto sobre medir memoria en producción, la comprobación concreta es sencilla: repetir un ciclo de uso completo N veces y ver si la memoria vuelve a su punto de partida.

// Comprobacion nocturna de fuga. Se ejecuta con un navegador dirigido.
async function comprobarFuga(pagina, ciclos = 12) {
  const medir = async () => {
    await pagina.evaluate(() => new Promise((r) => setTimeout(r, 1500)));
    const m = await pagina.evaluate(() =>
      performance.measureUserAgentSpecificMemory
        ? performance.measureUserAgentSpecificMemory().then((x) => x.bytes)
        : null
    );
    return m;
  };

  await recorridoCompleto(pagina);        // calentar y estabilizar
  const inicial = await medir();

  for (let i = 0; i < ciclos; i++) await recorridoCompleto(pagina);
  const final = await medir();

  const crecimientoPorCiclo = (final - inicial) / ciclos;
  return {
    inicial, final,
    crecimientoPorCiclo: Math.round(crecimientoPorCiclo),
    // Menos de 200 KB por ciclo es ruido; mas es una fuga.
    sospechoso: crecimientoPorCiclo > 200 * 1024,
  };
}

Muchas más pasadas. Con treinta pasadas por ruta, el suelo de detección baja lo bastante como para ver regresiones que en la petición de cambios eran indistinguibles del ruido.

Comparación con la competencia. Los datos públicos de experiencia de usuario permiten seguir la evolución de sitios que no son tuyos. Es el único número de todo este nivel que interesa fuera de ingeniería, y tenerlo en la serie sale gratis.

Y una regla sobre qué hacer cuando la nocturna encuentra algo: abre una incidencia con el rango de commits, no despiertes a nadie. La ejecución nocturna detecta derivas y regresiones de días; su latencia de respuesta correcta es de horas, no de minutos.

Cerrar el bucle con el campo

Los tres primeros niveles son laboratorio y el cuarto es realidad. La pregunta interesante es qué se hace cuando no coinciden, y las cuatro combinaciones tienen respuestas distintas:

La tercera fila es la más frecuente y la más instructiva. Casi siempre significa que el escenario de laboratorio está limpio de algo que en producción sí está: los terceros, un contenido más grande, un dispositivo más lento, una latencia mayor, una tasa de aciertos de caché real. Cada vez que ocurre, la reacción correcta no es descartar el campo sino ampliar el escenario de laboratorio hasta que reproduzca el problema, y ese escenario ampliado se queda para siempre. Es el mecanismo por el que un montaje de pruebas se vuelve bueno con el tiempo: cada regresión que se escapó añade el caso que la habría detectado.

Y una alerta de campo que conviene tener, porque es la única que detecta la clase de regresión que ninguna comprobación de laboratorio puede ver: una alerta sobre la tasa de aciertos de caché y sobre el peso de los terceros, medidos en producción. Esas dos cosas cambian sin que tú despliegues nada, y por tanto son invisibles para cualquier comparación entre commits.