Llevo doce años auditando señales de autoridad y, con ellas, los informes de rendimiento que las acompañan. Hay un patrón que se repite en casi cada revisión que cae en mis manos: el cliente llega con una captura de pantalla en verde y una pregunta en la cara. «Si todo está bien, ¿por qué la gente dice que la web va lenta?». La respuesta casi siempre está en la misma casilla, la que mide si tu página contesta cuando alguien le habla.
Y ahí está el malentendido de fondo. Los Core Web Vitals en 2026 siguen siendo tres señales, pero esta es la única que no habla de lo que el usuario ve, sino de lo que el usuario hace. Cargar rápido y responder rápido son dos problemas distintos, resueltos por equipos distintos, con causas distintas. Confundirlos cuesta meses de trabajo mal dirigido.
Conviene empezar por el nombre, porque aún circula mal escrito: INP son las siglas de Interaction to Next Paint, no de «Input No Procesado» como repiten algunas guías. Vamos a desmontar la métrica por dentro: qué mide exactamente, cómo se elige el número que acaba en tu informe y por qué la herramienta que todo el mundo usa para medirla no puede medirla.
Qué mide realmente la métrica de capacidad de respuesta
El INP mide el tiempo que transcurre entre que el usuario interactúa con la página y el momento en que la pantalla muestra el siguiente fotograma actualizado. Por debajo de 200 milisegundos se considera una buena respuesta. No mide la latencia del clic: mide el ciclo completo, hasta que el ojo recibe confirmación visual de que algo pasó.
¿Y por qué importa tanto ese matiz? Porque un navegador puede registrar tu clic en 8 milisegundos y tardar 700 en dibujar el resultado. Para el motor de métricas, esos 700 son el dato. Para el usuario, también.
| Valoración | Rango |
|---|---|
| Buena | 200 ms o menos |
| Necesita mejora | Entre 200 y 500 ms |
| Deficiente | Más de 500 ms |
Son cifras que parecen generosas sobre el papel. En la práctica, cualquier interfaz con un gestor de etiquetas mal configurado y tres scripts de terceros las supera sin despeinarse.
Hace un par de años audité una tienda de decoración con 340 ms de media en móvil. El equipo de desarrollo juraba que el problema era el servidor. Pasamos once días revisando backend. Perdí casi dos semanas por no mirar primero dónde tocaba.
Total, que esto no evalúa velocidad de carga, ni peso de página, ni tiempo hasta el primer byte. Evalúa una cosa concreta: cuánto tarda tu interfaz en reaccionar cuando el hilo principal del navegador ya está ocupado haciendo otra cosa.
Esa última parte es la clave de todo lo que viene a continuación.
La diferencia con la métrica que sustituyó
First Input Delay solo medía la primera interacción, y solo la parte de espera. Nada más. Era una métrica piadosa: la inmensa mayoría de los sitios la aprobaban sin esfuerzo, lo cual la volvía poco útil como señal de calidad.
El relevo se completó el 12 de marzo de 2024, y el cambio fue brutal en los informes agregados. Sitios con historial impecable aparecieron de golpe en ámbar. No habían empeorado. Simplemente, por fin se estaba midiendo lo que importaba.
Las tres fases de una interacción: retardo, procesamiento y pintado
Cada interacción se descompone en tres bloques temporales, y diagnosticar sin saber cuál de los tres está inflado es apuntar a ciegas.
- Input delay: el evento espera en cola porque el hilo principal está ocupado.
- Processing time: tus propios event listeners se ejecutan.
- Presentation delay: el navegador recalcula estilos y compone el fotograma.
Input delay: la espera antes de empezar
Es el tiempo que el evento pasa en cola porque el hilo principal está ocupado. Si hay una tarea larga ejecutándose cuando el usuario pulsa, el navegador no puede atenderle hasta que esa tarea termine. Aquí viven los scripts de analítica que se ejecutan al cargar, los polyfills pesados y las hidrataciones de framework mal escalonadas.
Processing time: el trabajo propio
Lo que tardan tus event listeners en ejecutarse. Un onClick que recorre un array de 4.000 elementos para filtrar resultados vive justo aquí. En las auditorías que firmamos, esta fase suele ser la segunda más gorda, aunque los desarrolladores tienden a asumir que es la primera.
Presentation delay: dibujar en pantalla
La fase olvidada. Entre que tu código termina y el píxel cambia, el navegador tiene que recalcular estilos, reconstruir el layout y componer el fotograma. Un cambio de clase que fuerza reflow sobre un DOM de 3.000 nodos puede costar 180 ms de pintado puro, sin una sola línea de JavaScript lenta de por medio.
Mi hipótesis inicial, allá por 2022, era que la optimización de interactividad consistía básicamente en partir tareas largas con setTimeout. Después de instrumentar once proyectos con medición por fases, los datos dijeron otra cosa: en seis de ellos el cuello de botella estaba en el pintado, no en la ejecución. Cambié la metodología entera.
Por qué Lighthouse nunca te dará esta cifra
Abre la herramienta de laboratorio, lanza una auditoría y busca el dato. No está. Y no es un bug pendiente de arreglar: es una imposibilidad estructural.
Una auditoría simulada carga la página en un entorno controlado, sin nadie al otro lado. No hay dedos. No hay teclado. No hay nadie que decida abrir el menú justo cuando el carrusel está hidratándose. Sin interacción humana no hay nada que cronometrar, así que la herramienta devuelve Total Blocking Time como sustituto aproximado.
TBT es un buen proxy, dentro de lo que cabe. Correlaciona razonablemente con los problemas de la primera fase. Pero ignora por completo el procesamiento de tus listeners y el coste de pintado, que es donde se concentra buena parte del problema en los proyectos que hemos instrumentado.
¿Dónde sí aparece el número real? En PageSpeed Insights, pero en el bloque de arriba, el de datos de campo. Ese bloque no lo genera la herramienta: lo lee de CrUX, el repositorio donde Chrome vuelca telemetría anónima de usuarios reales. Dos secciones, dos mundos, una confusión que he visto repetirse en reuniones de dirección más veces de las que me gustaría admitir.
Lo que esto implica para tu flujo de trabajo
Que no puedes validar una mejora de interactividad en local. Puedes sospechar que ha funcionado mirando TBT, pero la confirmación tarda semanas en llegar, porque el repositorio de campo trabaja con ventanas móviles de 28 días. Ese desfase condiciona el calendario entero de despliegues, y por eso cualquier metodología seria de optimización técnica de la web tiene que asumirlo desde el primer sprint y planificar las validaciones en consecuencia, o acabarás revirtiendo cambios buenos por pura impaciencia.
El percentil 75 y la peor interacción: cómo se elige el número final
Aquí hay dos capas de selección apiladas, y casi nadie distingue entre ellas.
Primera capa, dentro de cada visita. El navegador registra todas las interacciones de la sesión y se queda con la más lenta. No la media. La peor. Si un usuario hace 30 taps y 29 responden en 50 ms pero uno tarda 900, esa visita vale 900. Con una excepción: cuando se superan las 50 interacciones, el algoritmo descarta la peor por cada bloque de 50, para que un pico aislado no condene sesiones largas.
Segunda capa, entre todas las visitas. De ese conjunto de valores, el informe publica el percentil 75. Tres de cada cuatro visitas tuvieron una experiencia igual o mejor que la cifra reportada.
La consecuencia práctica es incómoda: tu número está determinado por el cuartil peor atendido de tu audiencia. Móviles de gama media con tres años de uso, conexiones móviles reales, navegadores con extensiones. (No por el portátil del desarrollador, que es precisamente donde se validan casi todas las mejoras.)
En un proyecto de febrero pasado, el percentil 75 estaba en 410 ms mientras la mediana marcaba 120. Toda la diferencia venía de dispositivos Android de 4 GB de RAM que representaban el 22% del tráfico. Arreglar eso movió la cifra agregada 190 ms. Tocar el resto del sitio no habría movido nada.
Qué cuenta como interacción y qué el navegador ignora
El criterio es más estrecho de lo que la gente asume. Solo se contabilizan tres tipos de evento: clic de ratón, toque táctil y pulsación de tecla. Fin de la lista.
- Scroll: no cuenta
- Hover: no cuenta
- Zoom o pinch: no cuenta
- Arrastre continuo: no cuenta como interacción discreta
Lo cual genera un punto ciego real. Un scroll que va a tirones por culpa de listeners sin passive: true arruina la percepción de calidad y no aparece en ninguna casilla. Nos ha pasado: cifras en verde, usuarios quejándose, y el problema en un comportamiento que la métrica no observa.
Dicho de otro modo: aprobar no equivale a estar bien. Equivale a estar bien en lo que se mide.
Una web rápida puede responder mal: el engaño del LCP perfecto
Si existe un escenario que resume por qué los Core Web Vitals necesitan leerse en conjunto y no como tres notas sueltas, es este.
Imagina un sitio con Largest Contentful Paint en 1,1 segundos. Contenido visible casi al instante, imagen principal preloaded, CSS crítico en línea. En el informe se ve precioso. Y sin embargo, la primera vez que el usuario pulsa un filtro, la interfaz se queda muda 600 ms.
¿Cómo es posible? Porque el pintado rápido y la disponibilidad del hilo principal son independientes. Puedes mostrar píxeles pronto y seguir teniendo 2,8 segundos de JavaScript pendiente ejecutándose detrás. La página parece lista. No lo está. Ese intervalo entre «parece lista» y «está lista» es, en mi experiencia, la fuente número uno de frustración silenciosa en comercio electrónico.
Esa contradicción entre señales es exactamente el motivo por el que auditamos las tres de forma cruzada y nunca por separado, y en nuestro artículo sobre qué es el SEO técnico premium desarrollamos la metodología completa de diagnóstico que aplicamos a este tipo de casos, con el orden de comprobaciones que seguimos antes de tocar código.
Del dato agregado al clic culpable: atribución con web-vitals.js
Saber que tu cifra es 380 ms no sirve de nada operativamente. Lo que necesitas es saber qué botón la produce.
La librería oficial de Google incluye una variante de atribución que resuelve esto. En lugar de devolver un número pelado, devuelve el elemento concreto sobre el que ocurrió la interacción lenta, el desglose por fases y, cuando el navegador lo soporta, los datos de Long Animation Frames: qué script bloqueó, desde qué archivo y durante cuántos milisegundos.
import {onINP} from 'web-vitals/attribution';
onINP(({value, attribution}) => {
console.log(attribution.interactionTarget);
console.log(attribution.inputDelay);
console.log(attribution.processingDuration);
console.log(attribution.presentationDelay);
}, {reportAllChanges: true});Con eso enviado a tu analítica, el informe deja de ser una nota y pasa a ser una lista de tareas: el selector .filtro-categoria button acumula 48 eventos lentos, con 310 ms de media en la fase de pintado. Por ahí se empieza.
Un apunte honesto: reportAllChanges genera mucho ruido en producción y puede inflar el coste de tu endpoint de recogida. Lo usamos en campañas de diagnóstico de dos o tres semanas, nunca de forma permanente.
Preguntas frecuentes sobre interactividad y rendimiento web
¿Cuánto tarda en reflejarse una mejora en los datos de campo?
Entre tres y cuatro semanas para ver movimiento claro, porque el repositorio público trabaja con ventanas móviles de 28 días. Las primeras señales aparecen antes si instrumentas tu propia medición en tiempo real con la librería.
¿Cómo se mejora la capacidad de respuesta de una página?
Primero se identifica la fase dominante con atribución, y solo después se interviene. Si pesa el retardo de entrada, hay que reducir tareas largas y JavaScript de terceros al cargar. Si pesa el procesamiento, se simplifican los listeners. Si pesa el pintado, se evitan reflows sobre DOM extensos.
¿Un valor alto penaliza directamente mi posicionamiento?
Funciona como señal de desempate, no como factor dominante. Entre dos páginas con relevancia equivalente, la que ofrece mejor experiencia tiene ventaja. Nadie ha caído veinte posiciones por 350 milisegundos.
¿Se puede medir sin herramientas de terceros?
Sí. La API de PerformanceObserver expone los eventos de interacción de forma nativa en navegadores basados en Chromium. La librería de Google es simplemente una capa de conveniencia sobre eso, con el algoritmo de selección ya implementado.
¿Por qué mi informe de campo aparece vacío?
Porque tu URL no acumula tráfico suficiente para alcanzar el umbral de privacidad del repositorio. En ese caso verás datos a nivel de origen completo, o nada. Es el escenario habitual en sitios de menos de 1.000 visitas mensuales.
¿Afecta igual en escritorio que en móvil?
Los informes separan ambos. El escritorio casi siempre aprueba con holgura por potencia de CPU; el problema vive en móvil, donde el hilo principal tiene mucha menos capacidad de absorber tareas largas.
Lo que queda cuando quitas el ruido
Esta señal no es un indicador de velocidad. Es un indicador de atención: mide si tu interfaz está disponible para el usuario en el momento exacto en que el usuario la necesita.
Mídela donde se puede medir, que es en campo. Desglósala por fases antes de tocar código. Y acepta que aprobar el umbral no significa que la experiencia sea buena, solo que no es demostrablemente mala en los tres eventos que el navegador vigila.
El resto de la calidad percibida sigue sin tener casilla. Y probablemente nunca la tenga.
