Core Web Vitals e INP 2026

En marzo de 2024, Google introdujo oficialmente Interaction to Next Paint (INP) como Core Web Vital, reemplazando a First Input Delay (FID). A primera vista parece una nota técnica menor — no lo es. FID medía únicamente el retraso hasta que el navegador procesaba por primera vez una entrada, ignorando cuánto tardaba en actualizar algo visiblemente en pantalla. INP captura exactamente eso: la latencia completa desde el clic del usuario hasta la respuesta visible de la página, medida a lo largo de todas las interacciones de una sesión, no solo la primera.

Para quienes toman decisiones en empresas medianas B2B, este cambio tiene dos consecuencias directas. Primero: páginas que parecían correctas bajo FID pueden puntuar significativamente peor bajo INP — porque responden rápido al primer toque pero se atascan en interacciones posteriores como entradas en formularios, acciones de filtro o cambios de pestaña. Segundo: Google usa INP como señal de ranking en la actualización Page Experience. Una puntuación INP deficiente puede costar posiciones aunque LCP y CLS estén en verde.

Desde mi trabajo con sitios web B2B, observo con regularidad que las plataformas con gran carga de JavaScript — especialmente configuraciones de React y Next.js con renderizado extenso del lado del cliente — están estructuralmente en desventaja respecto a INP a menos que ciertas decisiones arquitectónicas se tomen de forma deliberada. No es un argumento en contra de los frameworks modernos, sino un argumento para priorizar el rendimiento desde el principio.

Las Core Web Vitals no son un ejercicio académico. Modelan tres experiencias concretas del usuario: ¿con qué rapidez se hace visible el contenido más importante? ¿Con qué fluidez responde la página durante la interacción? ¿Y con qué estabilidad se carga el diseño? Estas tres dimensiones — velocidad de carga, interactividad y estabilidad visual — se correlacionan de forma demostrable con la tasa de rebote, la duración de la sesión y la conversión.

Largest Contentful Paint (LCP) mide el tiempo hasta renderizar el elemento de contenido visible más grande, normalmente una imagen hero o un H1. El umbral para 'bueno' es de 2,5 segundos. Causas frecuentes de un LCP deficiente: imágenes sin comprimir, ausencia de hints de preload para recursos críticos, tiempos de respuesta lentos del servidor (TTFB) y JavaScript que bloquea el renderizado.

Cumulative Layout Shift (CLS) cuantifica los desplazamientos de diseño inesperados — cuando los elementos saltan durante la carga y los usuarios tocan por error el botón equivocado. El umbral es 0,1. Causas frecuentes: imágenes sin dimensiones definidas, banners insertados después del renderizado inicial y fuentes web cargadas sin estrategia de font-display.

Interaction to Next Paint (INP) es la nueva métrica clave. Bueno significa menos de 200 ms, necesita mejora se sitúa entre 200 y 500 ms, y deficiente supera los 500 ms. INP mide la latencia desde la entrada del usuario hasta el siguiente frame renderizado — a lo largo de todas las interacciones de la sesión, tomando el valor del percentil 98 como puntuación global. Esto hace que INP sea más sensible a caídas puntuales pero graves que FID en su momento.

La distinción entre datos de campo y de laboratorio es central para el trabajo práctico de optimización. Los datos de laboratorio provienen de entornos de medición controlados — Lighthouse, WebPageTest, PageSpeed Insights en modo laboratorio. Son reproducibles, adecuados para pruebas de regresión y proporcionan trazas detalladas. Pero simulan una única carga de página en un dispositivo definido bajo condiciones de red definidas.

Los datos de campo, en cambio, provienen del Chrome User Experience Report (CrUX) — mediciones agregadas y anonimizadas de sesiones reales de usuarios. Reflejan la experiencia real de la audiencia: con sus dispositivos, conexiones y patrones de uso. Para el algoritmo de ranking de Google, solo cuenta la señal de datos de campo. Las puntuaciones de Lighthouse no se traducen automáticamente en mejoras de ranking a menos que los datos de CrUX lo reflejen.

INP es por definición una métrica de campo: las herramientas de laboratorio no pueden capturar secuencias de interacción reales a lo largo de una sesión de usuario completa. Lighthouse mide Total Blocking Time (TBT) como proxy de laboratorio — un indicador de las tareas largas que pueden empeorar INP — pero TBT e INP no son equivalentes. Un TBT bajo no garantiza un buen INP.

La implicación práctica: la optimización de INP requiere Real User Monitoring (RUM). Google Search Console muestra valores INP basados en CrUX a nivel de URL. Para diagnósticos más profundos son adecuadas herramientas como SpeedCurve, Sentry Performance o el fragmento JavaScript de Web Vitals integrado directamente en la pila de analítica propia. Solo cuando se sabe qué interacciones en qué páginas afectan a qué grupos de usuarios se puede intervenir con precisión.

Los problemas de INP rara vez tienen una única causa. En la práctica, suelen ser varios factores superpuestos los que conjuntamente provocan que el navegador tarde cientos de milisegundos después de un clic antes de que algo cambie en pantalla. Los tres grupos de causas más frecuentes son: tareas largas en el hilo principal, sobrecarga de hidratación en frameworks con renderizado del lado del servidor, y manejadores de eventos ineficientes.

Las tareas largas son bloques de JavaScript que bloquean el hilo principal durante más de 50 ms. Mientras una tarea larga está en ejecución, el navegador no puede responder a la entrada del usuario ni renderizar nuevos frames. El resultado: el usuario hace clic, no ve que ocurra nada, vuelve a hacer clic — y la cola de interacciones acumulada alarga aún más el INP medido. Las tareas largas son visibles en el panel de rendimiento de Chrome DevTools como bloques rojos, etiquetados explícitamente como 'Long Tasks'.

La hidratación es el problema específico de frameworks como Next.js, Nuxt o SvelteKit en modo SSR/SSG: la página se sirve inicialmente como HTML estático (favorable para LCP), luego carga JavaScript e 'hidrata' la página estática convirtiéndola en una aplicación interactiva. Durante esta fase de hidratación la página es visible para los usuarios, pero las interacciones pueden causar picos drásticos de INP porque el proceso de hidratación bloquea el hilo principal. La hidratación progresiva, la arquitectura de islas (p. ej. Astro) y React Server Components son respuestas arquitectónicas a este problema.

Los manejadores de eventos ineficientes son la causa que se subestima con mayor consistencia. Cada vez que un usuario hace clic o escribe, el manejador de eventos asociado se ejecuta de forma síncrona. Si ese manejador desencadena operaciones DOM complejas, recuperaciones de datos síncronas o actualizaciones de estado en cascada, el tiempo hasta el siguiente paint aumenta directamente. Especialmente crítico: los manejadores de eventos que causan layout thrashing — leyendo y escribiendo alternativamente en el DOM, lo que obliga al navegador a recalcular el diseño repetidamente.

La optimización del rendimiento sin priorización es un desperdicio de recursos. El siguiente framework describe un camino estructurado desde la primera medición hasta una mejora productiva — con prioridad clara en las medidas de mayor impacto con un esfuerzo razonable.

Paso 1 — Diagnóstico base: Abrir Google Search Console, sección 'Core Web Vitals'. ¿Qué URLs tienen valores INP 'deficientes'? ¿Son plantillas (p. ej. todas las páginas de producto) o páginas individuales? Estos grupos de URLs definen el alcance de la optimización. En paralelo: comprobar los datos de CrUX mediante PageSpeed Insights a nivel de página para entender las diferencias por dispositivo y conexión.

Paso 2 — Trazado de interacciones: Chrome DevTools, panel de rendimiento, grabar durante una sesión de usuario típica en la página problemática. Concretamente: hacer clic en la interacción más frecuente (botón CTA, filtro, campo de formulario) y analizar la traza. ¿Cuánto dura la latencia de entrada a pintura? ¿Qué bloque de código causa la tarea más larga? El panel de rendimiento muestra tareas largas, carga de scripting y operaciones de diseño en una vista de cascada.

Paso 3 — Priorizar medidas por categoría: El code splitting para bundles de JavaScript reduce la carga de hidratación. Delegar scripts de terceros a un Web Worker o externalizarlos mediante Partytown. Dividir los manejadores de eventos usando requestAnimationFrame o la Scheduler API (scheduler.yield()) para que el navegador pueda procesar interacciones entre tareas. Para React/Next.js: usar startTransition() para actualizaciones de estado no urgentes y mantener la capacidad de respuesta visual.

Paso 4 — Validación en staging: Después de cada cambio, medir TBT en Lighthouse como proxy y repetir las trazas de DevTools. Ningún despliegue sin evidencia medible de mejora en el laboratorio. Los datos de staging no reemplazan los datos de campo, pero evitan regresiones.

Paso 5 — Monitorización de datos de campo: Configurar RUM (o ampliar la pila de analítica existente para incluir Web Vitals). Esperar al menos 28 días hasta que los datos de CrUX reflejen la mejora — Google actualiza CrUX de forma continua durante ese período. Solo entonces el ciclo de optimización está completo.

La pregunta que surge en toda conversación con responsables de marketing: '¿Qué aporta esto en concreto?' La respuesta honesta es matizada. Las Core Web Vitals son una señal de ranking confirmada en la actualización Page Experience de Google, pero no es una señal dominante. La relevancia, los backlinks y la calidad del contenido siguen pesando más. Lo que hacen las Vitals: actúan como factor diferenciador entre páginas que de otro modo serían equivalentes, y como estándar mínimo por debajo del cual incluso contenido de calidad puede verse perjudicado.

La relevancia de negocio de INP reside, sin embargo, menos en el algoritmo de ranking y más en su efecto directo sobre el comportamiento del usuario. Las propias investigaciones de Google indican que mejorar las Core Web Vitals un nivel (p. ej. de 'deficiente' a 'necesita mejora') puede tener efectos medibles sobre la tasa de rebote y la duración de la sesión. Amazon, Pinterest y otros han documentado en pruebas internas que las mejoras de tiempo de carga en el rango de milisegundos tuvieron efectos en la conversión — aunque a volúmenes de tráfico que los sitios web de empresas medianas típicamente no alcanzan.

Lo que puedo reportar de proyectos concretos: los sitios web B2B con Core Web Vitals deficientes no pierden posiciones de ranking de la noche a la mañana, pero acumulan con el tiempo una desventaja estructural frente a competidores que optimizan activamente. Y el efecto directo sobre el usuario es real: una página que tarda 600 ms en responder a un clic genera fricción medible — especialmente en formularios, flujos de pago y herramientas interactivas. No es un valor de conversión visible en un test A/B en dos semanas, pero es acumulativamente significativo.

Para la priorización estratégica aplico este marco: si las Core Web Vitals están en rango 'deficiente', la optimización no es una medida opcional sino un requisito de higiene. Si están en 'necesita mejora', primero compruebo si los picos de INP se producen en interacciones críticas para la conversión. Si es así, el caso de negocio es claro. Si las tres Vitals están en verde, la atención se desplaza a otras palancas.

Las siguientes fuentes constituyen la base de los hechos técnicos y umbrales presentados en este artículo.