El desglose de INP en sus tres fases

Cuando alguien dice que un botón responde mal, la reacción automática es abrir el manejador del clic y buscar qué hace de más. En un número sorprendente de casos el manejador es trivial y el problema está antes o después de él: en el tiempo que el navegador tardó en poder atenderlo, o en el que tardó en pintar el resultado. Son tres fases con tres arreglos que no se parecen en nada, y el panel las separa.

Las tres fases

flowchart LR
a[El usuario pulsa] -->|Retraso de entrada| b[Empieza el manejador]
b -->|Tiempo de procesamiento| c[Terminan los manejadores]
c -->|Retraso de presentacion| d[El fotograma con el cambio se presenta]
style a fill:#cba6f7,color:#11111b
style b fill:#f38ba8,color:#11111b
style c fill:#f9e2af,color:#11111b
style d fill:#a6e3a1,color:#11111b

Retraso de entrada. Desde que el usuario actúa hasta que empieza a ejecutarse el primer manejador. El navegador registró el evento y no pudo atenderlo porque el hilo principal estaba ocupado con otra tarea que no puede interrumpirse. Esta fase no tiene nada que ver con tu botón: es culpa de lo que estuviera corriendo en ese momento.

Tiempo de procesamiento. La ejecución de todos los manejadores registrados para ese evento. Aquí sí está tu código, y también el de cualquier librería o script de terceros que haya puesto un escucha en el mismo evento o en un ancestro.

Retraso de presentación. Desde que terminan los manejadores hasta que el fotograma con el resultado aparece en pantalla. Contiene el recálculo de estilo, la disposición, el pintado y la composición del cambio que acabas de provocar, más cualquier otro trabajo que se colara antes del siguiente fotograma.

En el panel, cada interacción aparece como una caja en su pista, con las tres fases distinguidas al seleccionarla y con la lista de manejadores que se ejecutaron.

Qué significa que cada fase domine

Domina el retraso de entrada. El culpable está en otro sitio del perfil: una tarea larga solapando con el momento del clic. Mira qué es y cuándo empezó. Las causas típicas son un script de terceros inicializándose, un temporizador periódico que hace demasiado, trabajo de hidratación todavía en curso, o un procesamiento de datos que se lanzó al recibir una respuesta. El arreglo nunca está en el manejador: está en partir o mover esa otra tarea.

Hay un caso particular que merece mención porque es contraintuitivo: si el usuario interactúa durante la carga, el retraso de entrada suele ser enorme, y el motivo es que el arranque de la aplicación monopoliza el hilo. Es la razón de que la métrica de respuesta de muchas aplicaciones esté dominada por las interacciones de los tres primeros segundos.

Domina el procesamiento. Aquí sí toca leer el manejador, con dos comprobaciones antes de reescribirlo. La primera: ¿cuántos manejadores hay realmente para ese evento? La lista del panel puede tener sorpresas, incluidos escuchas delegados en ancestros y escuchas de terceros. La segunda: ¿el manejador hace trabajo síncrono que podría ser asíncrono? La respuesta visual al clic —el estado activo, el cargador— necesita ocurrir ya; el resto puede esperar al siguiente fotograma sin que nadie lo note.

Domina la presentación. El manejador terminó rápido y el navegador tardó en pintar. Las causas son un cambio que provoca recálculo de estilo masivo, un cambio que fuerza disposición de todo el documento, o simplemente demasiado DOM nuevo. También, con frecuencia, otro trabajo que se coló entre el manejador y el fotograma: una promesa pendiente que se resolvió justo entonces.

Medir el desglose en campo

Este observador registra cada interacción con sus tres fases y permite ordenarlas. Funciona en producción y es la instrumentación que convierte una métrica agregada en una lista de culpables.

// Desglose por fases de cada interaccion, agrupado por interactionId
(() => {
  const porInteraccion = new Map();

  new PerformanceObserver(lista => {
    for (const e of lista.getEntries()) {
      if (!e.interactionId) continue;
      const g = porInteraccion.get(e.interactionId) || { eventos: [], inicio: Infinity, fin: 0 };
      g.eventos.push(e);
      g.inicio = Math.min(g.inicio, e.startTime);
      g.fin = Math.max(g.fin, e.startTime + e.duration);
      porInteraccion.set(e.interactionId, g);
    }
  }).observe({ type: 'event', buffered: true, durationThreshold: 16 });

  window.desgloseInteracciones = () => {
    const filas = [];
    for (const [id, g] of porInteraccion) {
      // El evento mas largo del grupo aporta el desglose de fases
      const e = g.eventos.slice().sort((a, b) => b.duration - a.duration)[0];
      const entrada = e.processingStart - e.startTime;
      const proceso = e.processingEnd - e.processingStart;
      const presentacion = (e.startTime + e.duration) - e.processingEnd;
      filas.push({
        id,
        tipo: e.name,
        totalMs: Math.round(g.fin - g.inicio),
        entradaMs: Math.round(entrada),
        procesoMs: Math.round(proceso),
        presentacionMs: Math.round(presentacion),
        dominante: [['entrada', entrada], ['proceso', proceso], ['presentacion', presentacion]]
          .sort((a, b) => b[1] - a[1])[0][0],
        destino: e.target?.tagName?.toLowerCase() +
          (e.target?.id ? '#' + e.target.id : '') || '(desconocido)'
      });
    }
    filas.sort((a, b) => b.totalMs - a.totalMs);
    console.table(filas.slice(0, 20));

    const cuenta = {};
    for (const f of filas) cuenta[f.dominante] = (cuenta[f.dominante] || 0) + 1;
    console.log('Fase dominante por numero de interacciones:', cuenta);
    return filas;
  };

  console.log('Midiendo interacciones. Ejecuta desgloseInteracciones() cuando hayas usado la pagina.');
})();

El resumen final es la parte que orienta el trabajo: si la mayoría de las interacciones lentas están dominadas por el retraso de entrada, no hay ningún manejador que reescribir y todo el esfuerzo tiene que ir a reducir tareas largas. Si están dominadas por la presentación, el trabajo está en el CSS y en la estructura del DOM. Es una decisión de dirección que cuesta un minuto tomar con datos y semanas tomar mal.

El patrón que arregla la mayoría de los casos

Hay una reestructuración de manejador que resuelve una fracción grande de los problemas de respuesta y que consiste en separar el manejador en dos mitades: lo que el usuario tiene que ver ya, y todo lo demás.

// Patron de respuesta inmediata: pintar primero, trabajar despues
async function alPulsar(evento) {
  const boton = evento.currentTarget;

  // 1. Feedback inmediato. Barato y sincrono: entra en este mismo fotograma.
  boton.setAttribute('aria-busy', 'true');
  boton.disabled = true;

  // 2. Ceder el control para que el navegador pinte ese cambio ahora.
  await new Promise(r => requestAnimationFrame(() => setTimeout(r, 0)));

  // 3. Trabajo pesado, ya con la interfaz respondiendo.
  const datos = await calcularAlgoCaro();
  pintarResultado(datos);

  boton.removeAttribute('aria-busy');
  boton.disabled = false;
}

function calcularAlgoCaro() {
  return new Promise(r => {
    const t = performance.now();
    while (performance.now() - t < 120) {}
    r({ resultado: 'listo' });
  });
}
function pintarResultado(d) { console.log('Pintado:', d); }

document.body.addEventListener('click', e => {
  if (e.target.matches('button[data-demo]')) alPulsar(e);
});
document.body.insertAdjacentHTML('beforeend', '<button data-demo>Probar</button>');

La espera combinada del paso dos —un fotograma más una cesión— es la forma fiable de garantizar que el cambio visual se ha pintado antes de empezar el trabajo pesado. Con solo la sincronización de fotograma no basta: esa devolución de llamada se ejecuta antes del pintado, no después, y un error muy común es poner ahí el trabajo caro y bloquear precisamente el fotograma que se quería pintar.