Hay webs que cargan en menos de un segundo y aun así se sienten lentas. El usuario hace clic en «filtrar», pasan 600 milisegundos y no ocurre nada; vuelve a pulsar, y entonces la tabla se actualiza dos veces. Eso es lo que mide INP, y desde marzo de 2024 es una de las tres métricas con las que Google evalúa la experiencia de página.
INP sustituyó a First Input Delay. FID medía solo el retraso hasta que el navegador empezaba a procesar el primer clic; INP mide todo el recorrido: desde la interacción hasta que la pantalla muestra el resultado. La diferencia es enorme, porque una web puede reaccionar rápido al primer clic y tardar medio segundo en pintar la respuesta.
Qué mide exactamente y con qué umbrales
INP (Interaction to Next Paint) toma las interacciones de la visita —clics, toques y teclas— y se queda con la peor, descartando un pequeño porcentaje de outliers. El valor que cuenta es el percentil 75 de los usuarios reales, no el de tu portátil.
- 200 ms o menos: correcto.
- Entre 200 y 500 ms: mejorable.
- Más de 500 ms: mal. El usuario nota que la web no responde.
Se mide con datos de campo (el informe de experiencia de página de Search Console o la API de CrUX) y se aproxima en laboratorio con Lighthouse. Ojo: aprobar en laboratorio no garantiza aprobar en campo, porque tus usuarios tienen móviles peores y más pestañas abiertas que tu equipo.
Las tres causas que vemos una y otra vez
1. Tareas largas en el hilo principal
El navegador tiene un solo hilo para ejecutar JavaScript y calcular estilos y layout. Si una tarea lo ocupa 400 ms, cualquier clic durante ese tiempo espera. Las fuentes habituales son la hidratación de frameworks, el JavaScript de terceros y los scripts de analítica o consentimiento.
2. Manejadores que hacen demasiado
Un buscador que filtra 5.000 filas en cada pulsación de tecla, una tabla que se reordena en el cliente o un formulario que valida contra el servidor en cada carácter. El evento se procesa, pero la respuesta llega tarde.
3. Terceros que no controlas
Chat, mapas, píxeles publicitarios, pruebas A/B, vídeos incrustados. Cada uno añade kilobytes y tareas. El chat de soporte suele ser el primer sospechoso cuando el resto de la web está bien construida.
Cómo se arregla sin rehacer la web
- Medir por URL y por dispositivo. Empieza por las páginas con más tráfico y más conversión. No optimices la home si el formulario de presupuesto es el que suspende.
- Partir las tareas largas. Divide el trabajo en bloques y cede el hilo entre ellos con scheduler.yield() cuando esté disponible, o con setTimeout como alternativa. Para lo que no es urgente, requestIdleCallback.
- Cargar terceros bajo interacción. Un botón de «abrir chat» que carga el widget al pulsarlo elimina cientos de milisegundos de la ruta crítica. Lo mismo con mapas y vídeos: fachada primero, iframe después.
- Virtualizar listas y tablas grandes. Renderizar solo lo visible es la diferencia entre 80 y 4.000 nodos en el DOM.
- Debounce en búsquedas y filtros, y delegación de eventos en lugar de un listener por fila.
- Revisar el CSS que se recalcula en el evento. Leer medidas y escribir estilos en el mismo manejador provoca un reflow forzado que se come el presupuesto entero.
El patrón que se repite en webs corporativas
LCP por debajo de 1,5 segundos, CLS impecable, diseño cuidado y, sin embargo, INP por encima de 400 ms. Casi siempre hay tres culpables: el widget de chat cargado al inicio, el banner de cookies que bloquea el hilo al pintarse y un carrusel con una librería de 80 KB para pasar tres imágenes.
Ninguno de los tres exige rediseñar nada. Exige decidir qué se carga, cuándo y con qué presupuesto. En una web bien construida, el JavaScript de terceros debería ser la excepción que se justifica, no el punto de partida.
Qué pedir a quien te hace la web
- Un presupuesto de JavaScript por página, acordado por escrito.
- Inventario de terceros, con motivo y coste de rendimiento de cada uno.
- Monitorización de Core Web Vitals de campo, no solo una captura de Lighthouse el día de la entrega.
- Que las métricas estén en el mantenimiento: si suben, alguien lo mira.
Una web rápida no es la que saca 100 en una herramienta. Es la que responde cuando el cliente pulse «comprar» con el móvil en el tren. Si quieres que revisemos la tuya con datos reales, empezamos por la auditoría de rendimiento.