El 12 de marzo de 2024, Google jubiló FID y coronó a INP como Core Web Vital. Han pasado dos años y pico, y la métrica sigue siendo la que más disgustos da en los informes. Tiene sentido: FID era una métrica benévola hasta el ridículo, porque solo medía el retraso de la primera interacción y solo hasta que el navegador empezaba a atenderla. Todo lo que pasaba después —el trabajo de tu handler, el render, el repintado— quedaba fuera de la foto. Cambiar a INP fue como pasar de medir cuánto tarda el camarero en mirarte a medir cuánto tarda en traerte la caña.
Qué mide INP exactamente
INP (Interaction to Next Paint) coge todas las interacciones de la visita —clics, toques y pulsaciones de teclado; el scroll y el hover no cuentan— y se queda, a grandes rasgos, con la peor. De cada una mide tres tramos: el retraso de entrada (lo que el navegador tarda en poder atenderte porque el hilo principal está ocupado), el tiempo de proceso (lo que tarda tu código en ejecutarse) y el retraso de presentación (lo que tarda en pintarse el fotograma resultante). El umbral bueno está en 200 ms o menos; a partir de 500 ms es directamente malo. Y no se evalúa tu sesión: se evalúa el percentil 75 de las visitas reales del origen durante 28 días.
Ese percentil 75 explica media discusión de oficina. Tu MacBook con fibra no entra casi nunca en el cuartil que decide tu nota. El móvil de gama media con cuatro pestañas abiertas, sí.
Dónde mirar los datos sin fiarte de nadie
La gracia de todo esto es que los datos son públicos y no hace falta creerse los titulares. Tienes tres sitios donde mirar antes de opinar:
- El CrUX Dashboard (el informe de Looker Studio que se conecta al Chrome UX Report): te da la distribución de tu propio origen por mes, separando móvil y escritorio.
- La API de CrUX, si prefieres pedir el dato de una URL o un origen concreto y montártelo tú.
- El informe de tecnologías de Core Web Vitals de HTTP Archive, que cruza CrUX con la tecnología detectada. Ahí puedes comparar el porcentaje de orígenes que aprueban INP filtrando por WordPress, Shopify, Wix, Squarespace o Duda, y también por país. Es la fuente honesta para las conversaciones del tipo «es que WordPress va lento».
Cuando filtras por tecnología aparece el patrón que cualquiera que haya tocado estos proyectos se huele: los sitios montados sobre constructores visuales y los ecommerce con muchas apps de terceros lo pasan bastante peor que los sitios con front hecho a medida. No porque el CMS sea malo, sino por lo que se le acaba enchufando encima.
Los tres patrones que aparecen una y otra vez
1. El handler que lo hace todo de golpe
Un clic en «añadir al carrito» que, en la misma tarea, actualiza el estado, recalcula el total, dispara tres eventos de analítica, reordena el DOM y abre un panel lateral. Todo eso ocurre antes de que el navegador tenga permiso para pintar un solo píxel. El usuario ve una pantalla congelada durante 400 ms y decide que la web «va rara».
El arreglo es aburrido y funciona: pinta primero el feedback visual y aplaza el resto. Ceder el hilo con scheduler.yield() (o, si necesitas soporte más amplio, un setTimeout a cero o requestIdleCallback para lo que no urge) corta la tarea larga en trozos y permite que el fotograma salga. Lo que el usuario percibe no es el trabajo total, es cuándo ve la respuesta.
2. Los terceros que se enganchan al documento
Gestores de etiquetas, chats de soporte, herramientas de tests A/B, mapas de calor, banners de consentimiento. Muchos registran escuchadores a nivel de documento y hacen trabajo síncrono en cada clic que ocurre en tu página, aunque el clic no vaya con ellos. Sumas cinco scripts así y ya tienes 150 ms de peaje fijo en cada interacción, con tu código todavía sin empezar.
Aquí no hay refactor que valga: hay inventario. Lista qué está cargado, quién lo pidió y qué aporta. Suele sobrar la mitad, y suele haber una app instalada hace dos años para una campaña que terminó.
3. El DOM enorme que hace caro cualquier repintado
Este es el favorito de las páginas hechas con constructores visuales y de los temas de tienda con secciones infinitas. El JavaScript se ejecuta rápido, pero el navegador tiene después que recalcular estilos y maquetar veinte mil nodos para pintar un cambio mínimo. El coste se va al tercer tramo, el de presentación, y por eso a mucha gente le cuadran mal los números: mira el JavaScript, lo ve razonable y no encuentra al culpable.
Menos nodos, menos selectores que obliguen a recalcular medio árbol, y content-visibility en las secciones que están fuera de pantalla. Y si el panel que abres monta doscientos elementos, móntalo una vez y reutilízalo.
Cómo medirlo en tu sitio (Lighthouse no te va a ayudar)
Conviene decirlo claro: Lighthouse no mide INP. No puede, porque INP necesita que alguien interactúe de verdad. Lighthouse te dará TBT, que correlaciona pero no es lo mismo. La forma seria de tener el dato es medir a tus usuarios reales.
La receta mínima cabe en una tarde. Instalas la librería web-vitals de Google y usas la variante de atribución, importando desde web-vitals/attribution. Llamas a onINP con la opción reportAllChanges si quieres ver la evolución, y en el callback te llega, además del valor, un objeto attribution con lo que de verdad sirve: interactionTarget (el selector del elemento que causó el problema), inputDelay, processingDuration y presentationDelay. Con esos tres números sabes en cuál de los tres patrones de arriba has caído sin abrir un perfilador.
La versión reciente añade además las entradas de Long Animation Frames, que te dicen qué script concreto ocupó el hilo, con su URL y su duración. Es la diferencia entre «algo bloquea» y «bloquea el script de la herramienta X en la línea Y».
Luego solo queda mandar el dato a algún sitio. El patrón habitual es acumular en memoria y enviar todo junto con navigator.sendBeacon cuando el documento pasa a estado oculto, porque el evento unload es poco fiable en móvil. Destino: tu propio endpoint, tu almacén de analítica o donde ya guardes eventos. Cien líneas mal contadas y dejas de discutir con capturas de PageSpeed.
Lo que llevo viendo desde 2024 es que casi nadie tiene un problema de INP repartido por todo el sitio. Tienen dos o tres interacciones concretas —el filtro del catálogo, el desplegable del menú, el botón de añadir— que arrastran el percentil de todo el origen. Con atribución las encuentras en una semana de tráfico. Sin ella, puedes pasarte seis meses optimizando imágenes y preguntándote por qué el informe no se mueve.