INP: diagnosticar y corregir el Core Web Vital que más sitios suspenden

Entre los tres Core Web Vitals, el Interaction to Next Paint (INP) es el que más se resiste. Alrededor del 43 % de los sitios aún suspende el umbral de 200 milisegundos, lo que lo convierte en la señal que más se falla. A diferencia de su predecesor, el INP juzga la capacidad de respuesta de una página durante toda la visita, no solo en el primer clic — un cambio de método que explica por qué tantas interfaces consideradas «fluidas» se ponen en rojo.

#Qué mide el INP y por qué sustituyó al FID

First Input Delay solo medía el retraso antes de atender la primera interacción e ignoraba todo el trabajo posterior. La mayoría de los sitios obtenía un «buen» FID sin que reflejara la experiencia real. El INP corrige ese sesgo: observa la latencia de todas las interacciones de una visita — clics, toques, pulsaciones de teclado — y conserva un valor cercano al peor. Una interfaz puede, por tanto, mostrar un LCP y un CLS impecables y seguir suspendiendo el INP.

Cada interacción se descompone en tres fases, y el INP las suma: el retraso de entrada (el tiempo que el hilo principal permanece ocupado antes de poder procesar el evento), el tiempo de procesamiento (la ejecución de los manejadores de eventos) y el retraso de presentación (el cálculo del estilo y el pintado del siguiente frame).

#Los umbrales a alcanzar

Los umbrales se miden en el percentil 75 de las interacciones reales, sobre el dispositivo del percentil 75. Un valor de laboratorio no basta para validar un sitio.

El INP no se corrige en el laboratorio: se mide en el campo, en el percentil 75 de las interacciones reales.

#Medir el INP en el campo

El dato que cuenta es el de campo, no el de una auditoría sintética. La biblioteca web-vitals del equipo de Chrome expone el INP con la atribución del elemento y la fase responsables, lo que convierte una cifra abstracta en una pista de acción. Estos valores pueden enviarse a la herramienta analítica del sitio para un seguimiento continuo.

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const a = metric.attribution;
  // Élément et phase responsables de la pire interaction
  console.log('INP', metric.value, a.interactionTarget, {
    inputDelay: a.inputDelay,
    processingDuration: a.processingDuration,
    presentationDelay: a.presentationDelay,
  });
  navigator.sendBeacon('/rum', JSON.stringify({ inp: metric.value }));
}, { reportAllChanges: false });

La fase señalada orienta la corrección: un inputDelay alto apunta a un hilo principal saturado, un processingDuration largo señala un manejador demasiado pesado y un presentationDelay elevado delata un renderizado costoso.

#Dividir las tareas largas

La causa más frecuente de un mal INP es una tarea larga que monopoliza el hilo principal y retrasa el procesamiento de la interacción. La solución consiste en devolver el control al navegador entre bloques de trabajo. La API scheduler.yield() permite esta división recuperando el control con prioridad, allí donde un setTimeout clásico manda la tarea al final de la cola.

async function handleClick() {
  updateUIImmediately();        // retour visuel instantané

  for (const chunk of workChunks) {
    processChunk(chunk);
    // Rend la main au navigateur pour traiter d'autres interactions
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Otros tres palancas completan la división: aplazar el trabajo no esencial hasta después del pintado con requestIdleCallback, evitar el layout thrashing separando las lecturas y las escrituras del DOM, y reducir el coste de renderizado limitando el alcance de los recálculos de estilo. Reducir la cantidad de JavaScript ejecutado al arranque — code splitting, hidratación diferida — sigue siendo la palanca de fondo.

#Lo que hay que recordar

El INP mide la capacidad de respuesta de todas las interacciones de una visita, con un objetivo de 200 ms en el percentil 75. Se diagnostica con datos de campo y la atribución de web-vitals, nunca sobre una sola auditoría de laboratorio. Las mejoras vienen sobre todo de dividir las tareas largas y reducir el JavaScript ejecutado en el hilo principal. Es un trabajo de fondo, pero también es el Core Web Vital donde el esfuerzo se ve más rápido en los datos reales.

Para profundizar: la documentación de referencia «Interaction to Next Paint (INP)» en web.dev detalla las fases de una interacción y las técnicas de optimización.