Acortar el procesamiento: separar la respuesta visual del trabajo pesado

La duración del procesamiento es el tiempo de tu código dentro del manejador, y su optimización tiene una particularidad frente a las otras dos partes del INP: casi nunca consiste en hacer el trabajo más rápido. Consiste en hacer menos trabajo antes del primer pintado y el resto después. El usuario no necesita el resultado completo en el primer fotograma; necesita saber que su acción se registró. Separar esas dos cosas es la técnica más rentable de todo este nivel.

La clasificación del trabajo

Ante un manejador lento, el primer paso es separar su contenido en tres categorías.

Respuesta visual. Lo mínimo para que el usuario sepa que su acción se registró: cambiar el estado del botón, marcar la pestaña activa, mostrar el indicador, cerrar el menú. Casi siempre es una o dos escrituras al DOM y cuesta menos de un milisegundo.

Trabajo esencial. Lo que produce el resultado que el usuario pidió: filtrar la lista, calcular el total, abrir el panel con contenido. Tiene que ocurrir, y puede ser caro.

Trabajo diferible. Todo lo demás: enviar telemetría, guardar en almacenamiento local, precargar lo siguiente, actualizar un contador secundario, registrar en un sistema de sesiones. No afecta a lo que el usuario ve ahora.

Un manejador típico sin optimizar mezcla los tres en orden arbitrario:

// 320 ms de procesamiento, todo antes del primer pintado
filtro.addEventListener('change', (e) => {
  analitica.evento('filtro_cambiado', { valor: e.target.value });   // diferible, 25 ms
  localStorage.setItem('ultimoFiltro', e.target.value);             // diferible, 8 ms
  const resultado = filtrarYOrdenar(productos, e.target.value);     // esencial, 180 ms
  renderizarLista(resultado);                                       // esencial, 95 ms
  actualizarContador(resultado.length);                             // visual, 1 ms
  precargarSiguientePagina(resultado);                              // diferible, 12 ms
});

El patrón de ceder antes de renderizar

La reescritura tiene tres bloques, en este orden:

import { ceder } from './planificacion.js';

filtro.addEventListener('change', async (e) => {
  const valor = e.target.value;

  // 1. RESPUESTA VISUAL: sincrona, minima, antes de cualquier cesion
  lista.dataset.estado = 'filtrando';
  contador.textContent = '…';

  // 2. Ceder: el navegador pinta la respuesta visual AHORA
  await ceder();

  // 3. TRABAJO ESENCIAL: ya fuera de la interaccion medida
  const resultado = filtrarYOrdenar(productos, valor);
  renderizarLista(resultado);
  contador.textContent = String(resultado.length);
  delete lista.dataset.estado;

  // 4. TRABAJO DIFERIBLE: con prioridad baja, sin prisa
  programar(() => {
    analitica.evento('filtro_cambiado', { valor });
    localStorage.setItem('ultimoFiltro', valor);
    precargarSiguientePagina(resultado);
  }, { priority: 'background' });
});

El efecto sobre la métrica es grande y conviene entender exactamente por qué. La interacción se mide desde la pulsación hasta el siguiente fotograma pintado. Con la cesión colocada justo después de la respuesta visual, ese siguiente fotograma contiene el estado de «filtrando», y la interacción termina ahí: unos pocos milisegundos. Los 300 restantes ocurren después y no cuentan para el INP.

Y no es hacer trampa con la métrica: es exactamente lo que la métrica pretende medir. El usuario ha recibido confirmación visual en 8 milisegundos en lugar de en 320. Su percepción de la respuesta ha mejorado de forma real.

Hay una variante sin scheduler que funciona en todos los navegadores y que a veces es preferible porque garantiza que el pintado ha ocurrido:

function trasElPintado(fn) {
  requestAnimationFrame(() => {
    // Dentro del rAF: el fotograma se va a componer. Un setTimeout desde aqui
    // se ejecuta despues de que ese fotograma este presentado.
    setTimeout(fn, 0);
  });
}

Ese es el patrón de doble paso que la gente conoce como doble fotograma. La combinación de requestAnimationFrame y setTimeout es más fiable que dos requestAnimationFrame anidados para este propósito concreto, porque el segundo rAF se ejecuta antes del pintado del siguiente fotograma, no después.

Los tres errores que anulan el patrón

Error uno: ceder antes de la respuesta visual. Si el await está al principio del manejador, la interacción sigue midiendo hasta que llegue el primer cambio visual, que ahora está después de la cesión. No has ganado nada y has añadido una cesión.

// MAL: se cede antes de cambiar nada. El primer pintado sigue conteniendo el resultado.
elemento.addEventListener('click', async () => {
  await ceder();
  hacerTodoElTrabajo();
});

Error dos: la respuesta visual no produce un cambio pintable. Cambiar una propiedad de un objeto de estado no es una respuesta visual; el navegador no tiene nada que pintar. Con marcos que renderizan de forma asíncrona, un cambio de estado antes de ceder puede no haberse aplicado al DOM cuando el fotograma se compone. La respuesta visual tiene que ser un cambio que llegue al DOM antes de la cesión, y con marcos asíncronos eso exige la primitiva de descarga síncrona del marco o una escritura directa al DOM.

Error tres: el trabajo diferido bloquea la siguiente interacción. Has movido 300 milisegundos fuera de esta interacción y los has puesto justo donde el usuario va a hacer el siguiente clic. Ahora el retraso de entrada de la interacción siguiente es de 300 milisegundos y el INP no ha mejorado, solo se ha desplazado. La solución es que ese trabajo diferido esté troceado con cesión y tenga prioridad baja.

Ese tercer error es el más común y el más difícil de ver, porque la métrica que empeora no es la que estabas mirando.

Los oyentes múltiples

Una causa de procesamiento largo que no está en tu manejador: hay más manejadores de los que crees.

Todos los oyentes registrados para un evento se ejecutan en la misma tarea. Un clic en un botón dentro de una tarjeta dentro de un formulario puede disparar el oyente del botón, dos oyentes delegados en el contenedor, uno en el documento para cerrar menús abiertos, y uno de la biblioteca de analítica que registra todos los clics.

La forma de verlos, en la consola del navegador, sobre un elemento seleccionado en el inspector:

// $0 es el elemento seleccionado en el panel de elementos
getEventListeners($0);
// Y los heredados por propagacion, subiendo por los ancestros
let n = $0;
while (n) { const l = getEventListeners(n); if (Object.keys(l).length) console.log(n, l); n = n.parentElement; }

getEventListeners es una utilidad de la consola, no una API del lenguaje: no se puede usar en código.

Lo que suele aparecer: dos o tres oyentes que registró una biblioteca de terceros sobre el documento, capturando todos los clics de la página para su propia contabilidad. Cada uno con su coste, sumado a todas las interacciones del sitio. Es una de las razones por las que el coste de un script de terceros no se limita a su carga.

// React: flushSync fuerza la aplicacion sincrona de este cambio
import { flushSync } from 'react-dom';

async function alFiltrar(valor) {
  flushSync(() => setEstado('filtrando'));   // llega al DOM ya
  await ceder();                              // el navegador pinta el indicador
  const resultado = filtrarYOrdenar(datos, valor);
  setEstado('listo');
  setResultado(resultado);
}

// Vue: esperar al siguiente ciclo de actualizacion antes de ceder
import { nextTick } from 'vue';

async function alFiltrar(valor) {
  estado.value = 'filtrando';
  await nextTick();        // el cambio esta en el DOM
  await ceder();           // y ahora se puede pintar
  resultado.value = filtrarYOrdenar(datos, valor);
  estado.value = 'listo';
}

elemento.addEventListener('click', async (e) => {
  const t0 = e.timeStamp;
  flushSync(() => setEstado('cargando'));
  requestAnimationFrame(() => {
    performance.measure('respuesta visual', { start: t0, end: performance.now() });
    console.assert(document.querySelector('[data-estado="cargando"]'), 'el indicador no llego al DOM');
  });
  await ceder();
  /* ... */
});