El INP Castiga la Analítica Pesada: Por Qué Tu Rastreador Está en el Hilo Principal
Interaction to Next Paint es el Core Web Vital que más sitios suspenden, y los datos de campo muestran que los scripts de seguimiento de comportamiento son una de las causas principales. La solución es enviar menos trabajo al hilo principal.
Interaction to Next Paint (INP) es el Core Web Vital que los desarrolladores suspenden con más frecuencia, y el motivo está dentro de tu <head>. El INP se convirtió en un Core Web Vital estable en 2024, reemplazando al First Input Delay, y mide algo que el FID nunca pudo: cuán responsiva se mantiene una página en cada clic, toque y pulsación de tecla durante todo su ciclo de vida.
La métrica es implacable con el tipo de JavaScript que carga la analítica de vigilancia. Si tu rastreador hace trabajo relevante en el hilo principal, cada interacción de tus usuarios hereda ese costo.
Qué Mide Realmente el INP
El INP reporta la latencia de las interacciones en el percentil 75 de todos los clics, toques y pulsaciones de tecla en una página. Una puntuación de 200 ms o menos es "buena"; de 200 a 500 ms "necesita mejorar"; por encima de 500 ms es "deficiente".
Cada interacción se divide en tres fases:
- Retardo de entrada (input delay) — tiempo hasta que tus event handlers pueden siquiera empezar, porque el hilo principal está ocupado.
- Duración de procesamiento — tiempo que tardan en ejecutarse los callbacks de tus event handlers.
- Retardo de presentación (presentation delay) — tiempo desde que termina el callback hasta que el navegador pinta el siguiente fotograma.
La analítica pesada perjudica las tres fases. Un rastreador que analiza un bundle grande, evalúa lógica de consentimiento, agrupa una cola de tag manager o lee el layout para construir un fingerprint ocupa el hilo principal justo cuando el usuario intenta interactuar.
Las Tareas Largas Son el Mecanismo
El navegador no puede procesar una interacción mientras se ejecuta una tarea. Cualquier tarea que dure más de 50 ms es una tarea larga, y la parte que supera los 50 ms es tiempo muerto durante el cual los clics se acumulan en la cola.
Un tag manager que carga y ejecuta de forma síncrona una docena de scripts de proveedores produce una cascada de tareas largas. El usuario hace clic, no pasa nada, vuelve a hacer clic — y cuando el hilo principal por fin se libera, las entradas en cola se disparan todas a la vez.
Esto no es teórico. El Web Almanac de 2024 de HTTP Archive halló que las páginas con scripts de comportamiento del usuario — session replay, mapas de calor, analítica conductual — alcanzaron buen INP solo el 37% de las veces en móvil, frente al 60% en escritorio. Los scripts de gestión de consentimiento, los banners que esas herramientas requieren, aprobaron el INP en apenas el 53% de las páginas móviles. La instrumentación destinada a "entender a los usuarios" está degradando activamente su experiencia.
La Arquitectura Que Lo Evita
La solución es estructural, no una opción que activas. Envía menos código y mantenlo fuera de la ruta crítica.
Un rastreador privacy-first puede ser lo bastante pequeño como para que su análisis y ejecución nunca cuenten como una tarea larga. El rastreador de Monoid pesa unos 2 KB, no tiene dependencias, no establece cookies y no lee el layout — así que no hay nada que fingerprintear ni nada pesado que ejecutar. Registra una vista de página con una única petición keepalive y, por lo demás, permanece inactivo:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true permite que la petición sobreviva a la página sin retener el hilo principal, de modo que la navegación y el unload nunca quedan bloqueados esperando un beacon.
Cuando ejecutes tus propios scripts, cede el hilo principal entre bloques de trabajo para que las interacciones en cola puedan ejecutarse:
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() divide una tarea larga en piezas y reanuda con prioridad, de modo que un script de terceros no pueda colarse en la cola por delante de tu continuación.
Mídelo en Campo, No en Laboratorio
Lighthouse no puede reportar el INP, porque el INP solo existe cuando una persona real interactúa. Las herramientas de laboratorio estiman; no miden la responsividad.
Usa datos de campo. El Chrome User Experience Report (CrUX) agrega interacciones reales de usuarios de Chrome que optaron por participar, y el informe de Core Web Vitals de Search Console muestra los mismos datos por grupo de URL. Si tu INP en CrUX está bien pero tu Total Blocking Time de laboratorio es alto, tienes margen; si el INP en CrUX es deficiente, tus usuarios ya lo están sintiendo.
El argumento de privacidad y el de rendimiento convergen aquí. Un rastreador que no lee almacenamiento, no construye fingerprint y no carga una cascada de proveedores casi no tiene nada que hacer en el hilo principal — y por eso justamente nunca aparece en tu INP. La vigilancia es cara en milisegundos, no solo en confianza.
Comments
Loading comments…