ES INP y Core Web Vitals: cómo conseguir una web que responda de verdad
Una web puede cargar rápido y, aun así, sentirse lenta. Ocurre cuando el menú no se abre al primer toque, el filtro tarda en reaccionar o el botón de compra parece no haber hecho nada. Interaction to Next Paint, conocido como INP, mide precisamente esa capacidad de respuesta.
INP forma parte de Core Web Vitals y sustituyó a First Input Delay. La diferencia es importante: ya no se observa únicamente la primera interacción, sino los clics, toques y pulsaciones de teclado durante la visita. El resultado representa la interacción más lenta, con un tratamiento de valores atípicos cuando hay muchas acciones.
Qué mide INP en términos sencillos
Cuando una persona pulsa un control, el navegador necesita recibir la entrada, ejecutar el código asociado y pintar el siguiente cambio visible. INP reúne esas fases en una misma latencia. No mide cuánto tarda en completarse toda una petición al servidor, sino cuánto espera el usuario hasta ver una respuesta visual.
La interacción puede dividirse en tres partes:
- Retraso de entrada: el tiempo hasta que el navegador empieza a atender la acción.
- Procesamiento: el trabajo que realizan los controladores de eventos.
- Presentación: el tiempo necesario para calcular y pintar el siguiente fotograma.
Google considera una buena referencia mantener INP en 200 milisegundos o menos en el percentil 75, revisando móvil y ordenador por separado. No significa que todas las acciones deban durar menos de esa cifra, pero sí que la experiencia habitual debe responder con consistencia.
Por qué una página se bloquea
JavaScript demasiado largo
Un script puede ocupar el hilo principal durante cientos de milisegundos. Mientras termina, la interfaz acumula acciones sin responder. Es frecuente en páginas que cargan varias herramientas de marketing, widgets, constructores visuales y bibliotecas aunque el usuario todavía no las necesite.
Una sola acción desencadena demasiado trabajo
Abrir un menú no debería recalcular toda la página. Un filtro no necesita reconstruir cientos de tarjetas si solo cambian unas pocas. Dividir tareas, reducir cambios de DOM y aplazar procesos secundarios suele mejorar la sensación de respuesta.
Diseño visual costoso
Sombras complejas, desenfoques, animaciones y elementos que cambian de tamaño pueden aumentar el tiempo de presentación, sobre todo en móviles modestos. No hace falta renunciar al diseño, pero sí probarlo en dispositivos menos potentes que el ordenador del equipo de desarrollo.
Componentes externos
Chats, mapas, vídeos y herramientas de personalización pueden ejecutar su propio código o utilizar iframes. Aunque el contenido esté aislado, los recursos del dispositivo siguen siendo limitados. La carga bajo demanda reduce trabajo inicial y protege tanto la velocidad como la privacidad.
Cómo diagnosticar un INP alto
El orden correcto evita perder tiempo optimizando lo que no afecta a usuarios reales.
- Empieza por datos de campo. PageSpeed Insights y el informe de Core Web Vitals de Search Console utilizan datos agregados de Chrome cuando hay volumen suficiente.
- Separa móvil y escritorio. Una media conjunta puede ocultar el problema que sufren los teléfonos.
- Identifica el flujo. Prueba navegación, buscador, filtros, formularios, carrito, galería y apertura de modales.
- Reproduce en laboratorio. Las herramientas de rendimiento del navegador permiten localizar tareas largas y cambios de renderizado.
- Mide después de publicar. Los datos de campo tardan en reflejar el cambio; una prueba puntual no sustituye la observación real.
Prioridades que suelen dar resultado
Reducir el JavaScript que llega a cada página
El código debe cargarse donde se utiliza. Un carrusel exclusivo de la portada no necesita acompañar una página legal. También conviene eliminar dependencias duplicadas y revisar etiquetas externas que ya no aportan datos útiles.
Dividir tareas largas
Cuando un proceso puede ejecutarse por bloques, el navegador recupera oportunidades para responder y pintar. La interfaz puede mostrar primero un estado inmediato y completar después el trabajo secundario.
Actualizar solo lo necesario
Filtros, buscadores y calculadoras deben limitar las lecturas y escrituras sobre el documento. Agrupar cambios evita ciclos repetidos de cálculo de estilos y diseño.
Dar una respuesta visual temprana
Si una operación depende de red, el botón puede cambiar de estado, mostrar progreso o bloquear envíos duplicados. El usuario entiende que la acción ha sido recibida, aunque el resultado definitivo tarde más.
No conviertas la métrica en el único objetivo
Una buena cifra no compensa un formulario incomprensible ni una navegación confusa. INP ayuda a detectar fricción técnica, pero debe revisarse junto con estabilidad visual, carga del contenido principal, accesibilidad y resultados de negocio.
En un proyecto de mantenimiento web, la mejora no termina al corregir una tarea lenta. Nuevos scripts, campañas o componentes pueden degradar la experiencia meses después. Por eso es útil integrar la medición en las revisiones periódicas.
Una lista breve antes de publicar
- Prueba los controles principales con ratón, teclado y pantalla táctil.
- Revisa el sitio en un móvil de gama media, no solo con simulación.
- Comprueba si cada etiqueta externa sigue siendo necesaria.
- Evita animaciones que bloqueen o retrasen la acción principal.
- Confirma que formularios y compras muestran estados claros.
- Vuelve a medir después de cambios de diseño o marketing.
La web rápida no es la que gana una captura perfecta de laboratorio, sino la que responde con claridad durante todo el recorrido del usuario.
