Tu sitio responde tarde: cómo diagnosticar INP sin empezar por un rediseño

Una página puede terminar de cargar y aun sentirse atorada. El menú aparece, pero abre tarde; el filtro recibe el toque, pero no cambia; el botón de agregar confirma cuando la persona ya volvió a presionarlo. Interaction to Next Paint, o INP, ayuda a detectar esa falta de respuesta: observa cuánto transcurre desde un clic, toque o pulsación de teclado hasta que el navegador puede mostrar el siguiente cuadro.

El objetivo publicado por web.dev para INP es de 200 milisegundos o menos en el percentil 75, separado entre móvil y escritorio. Ese umbral sirve para reconocer un problema, no para adivinar su arreglo. Un diagnóstico útil sigue una cadena: señal de campo, interacción concreta, reproducción en laboratorio, fase dominante, cambio acotado y nueva medición. Saltarse esos pasos puede convertir una demora local en un rediseño costoso que conserva la causa.

INP empieza cuando el sitio ya parece listo

INP no mide la descarga inicial ni pregunta cuánto tardó en aparecer el contenido principal. Evalúa la capacidad de responder durante toda la visita y considera interacciones calificadas con mouse, pantalla táctil o teclado. Desplazarse o pasar el cursor no forman parte de la métrica. Si nadie interactúa con una página, puede no existir un valor de INP para esa visita.

Esto importa porque las tres Core Web Vitals describen problemas distintos. Largest Contentful Paint se concentra en carga; Cumulative Layout Shift, en estabilidad visual; INP, en respuesta. La documentación de Google Search sobre Core Web Vitals recomienda alcanzar buenos valores para la experiencia general, pero no convierte una cifra aislada en garantía de posiciones, tráfico o ventas.

El valor agregado tampoco nombra al culpable. Puede venir de un selector de variantes, el botón de enviar, un acordeón, la navegación móvil, un filtro o una interacción dentro de un iframe. Antes de pedir cambios a desarrollo, hay que pasar del indicador a la acción que una persona intentó completar.

Campo y laboratorio responden preguntas diferentes

PageSpeed Insights combina datos de campo de Chrome User Experience Report, o CrUX, con diagnósticos de laboratorio de Lighthouse. El bloque de campo refleja experiencias reales en distintos dispositivos, redes y comportamientos; el laboratorio reproduce una condición controlada. Por eso ambos pueden mostrar resultados diferentes sin que uno esté necesariamente equivocado.

Los datos de campo contestan si existe un patrón para personas reales, pero CrUX suele llegar al nivel de URL u origen y no identifica por sí solo el botón que produjo la interacción lenta. Una solución de monitoreo de usuarios reales puede aportar el objetivo de la interacción, el tipo de entrada y el desglose de demoras. La guía de web.dev para encontrar interacciones lentas en campo explica cómo la versión de atribución de la biblioteca `web-vitals` puede registrar ese contexto.

El laboratorio sirve después. Permite repetir el recorrido, grabar una traza, probar una hipótesis y comparar el mismo gesto bajo condiciones conocidas. No sustituye a la población real: una prueba sintética no sabe cuándo decidirán interactuar las personas ni reproduce toda la variedad de dispositivos. Una estrategia de analítica y medición debe conservar esa diferencia para no usar un resultado de laboratorio como si fuera la experiencia completa.

Usa una escalera de evidencia

El diagnóstico puede organizarse en seis peldaños. Cada uno reduce una incertidumbre distinta:

1. Señal: confirma si el problema aparece en campo, en qué dispositivo y para qué grupo de URLs.
2. Segmento: identifica la plantilla, ruta o estado compartido por las páginas afectadas.
3. Interacción: registra el control, la acción esperada y el momento en que ocurre la demora.
4. Traza: reproduce el gesto en laboratorio y localiza su entrada en la pista de interacciones.
5. Fase: separa demora de entrada, duración de procesamiento y demora de presentación.
6. Verificación: prueba el cambio de inmediato en laboratorio y espera evidencia de campo suficiente antes de cerrar el hallazgo.

No todos los equipos contarán con atribución propia desde el primer día. En ese caso, CrUX o Search Console pueden abrir la investigación y una lista de recorridos críticos puede orientar las pruebas. La limitación debe quedar escrita: “vemos un grupo lento en móvil” no equivale a “este script causa el problema”.

Inventaría interacciones, no sólo páginas

Una URL puede contener diez acciones con costos y valor muy distintos. Conviene registrar para cada una: plantilla, control, intención de la persona, estado previo, siguiente cuadro esperado, dispositivo, frecuencia observada, criticidad operativa y evidencia disponible. El inventario une lenguaje de negocio y lenguaje técnico.

Imagina un ejemplo hipotético de ecommerce. La ficha carga rápido, pero elegir una talla tarda en reflejar disponibilidad. El equipo no debería anotar sólo “producto con INP alto”. Necesita distinguir el toque sobre la variante, la actualización visual esperada, la consulta o cálculo disparado y el estado del botón de compra. Ese nivel permite reproducir el problema sin presentar el ejemplo como un caso o resultado de Albi.

Prioriza primero las interacciones que bloquean una tarea importante, se repiten en varias plantillas, afectan a una porción relevante del tráfico o no tienen una salida clara. La demora más larga no siempre merece el primer cambio: un control raro y secundario puede ser menos urgente que un botón de cotización moderadamente lento. El análisis debe conectarse con el recorrido de optimización de conversión, sin confundir rapidez con causalidad comercial.

Las tres fases piden soluciones distintas

La latencia de una interacción se compone de tres partes. La guía de optimización de INP recomienda identificarlas porque reducir la fase equivocada desperdicia tiempo.

Demora de entrada

Empieza cuando la persona interactúa y termina cuando el navegador puede ejecutar el primer callback. Suele crecer cuando el hilo principal ya está ocupado con tareas largas: evaluación de JavaScript, temporizadores, trabajo de terceros u otra interacción. El primer análisis debe preguntar qué estaba corriendo antes del gesto. Cargar menos código, posponer trabajo no crítico o dividir tareas puede abrir espacio, pero cada cambio necesita considerar funciones, consentimiento y dependencias reales.

Duración de procesamiento

Es el tiempo que consumen los manejadores de eventos. Un clic puede validar demasiados campos, recalcular datos, actualizar estado y preparar una llamada antes de permitir que la interfaz responda. La primera corrección suele ser hacer menos dentro del callback y diferir lo que no necesita aparecer en el siguiente cuadro. Dividir trabajo no significa ocultar una demora de red: la interfaz debe dar retroalimentación honesta mientras continúa la operación.

Demora de presentación

Ocurre después de los callbacks y termina cuando el navegador pinta el resultado. Un DOM grande, recálculos de estilo, layout forzado o una actualización extensa de componentes puede encarecer esa fase. Reducir el árbol que cambia, evitar leer y escribir layout dentro de la misma tarea y revisar qué se vuelve a renderizar son hipótesis distintas a eliminar JavaScript de arranque.

La referencia del panel Performance de Chrome DevTools muestra la pista de interacciones y sus tres segmentos. Esa separación transforma “el clic tarda” en una pregunta verificable sobre trabajo anterior, callbacks o renderizado.

Traza una interacción de principio a fin

Un protocolo breve evita grabaciones imposibles de comparar:

1. Elige una ruta, dispositivo, estado e interacción exactos.
2. Describe qué cambio visual debería aparecer en el siguiente cuadro.
3. Repite el recorrido y confirma que la demora puede observarse.
4. Graba el gesto en Performance y localiza la entrada correspondiente en Interactions.
5. Compara los tres segmentos con la actividad del hilo principal y las capturas de la traza.
6. Formula una sola hipótesis y aplica el cambio mínimo que pueda refutarla.
7. Repite bajo las mismas condiciones y revisa que no se rompan teclado, foco, estados de error ni acciones relacionadas.

La guía de diagnóstico manual de interacciones lentas recomienda alinear la interacción con la actividad del hilo principal. Una ejecución verde después del cambio es evidencia de laboratorio, no la conclusión final. Conserva versión, entorno, recorrido y resultado para que otra persona pueda repetirlo.

INP no decide entre optimizar y reconstruir

Una mala respuesta puede originarse en un script de terceros, un callback local o una actualización visual demasiado amplia. Ninguna de esas causas exige por sí sola reemplazar todo el sitio. Primero corrige la restricción identificada y verifica la tarea afectada.

Una intervención más estructural cobra sentido cuando la misma limitación aparece en muchas plantillas, el sistema de componentes obliga a actualizar árboles extensos, el CMS impide retirar dependencias o cada reparación crea otra incompatibilidad. La guía de Albi para decidir entre optimizar, migrar o reconstruir ayuda a separar esos alcances sin usar la edad o la apariencia del sitio como diagnóstico.

El criterio debe ser la menor intervención que resuelve la causa comprobada y deja una base mantenible. También hay que presupuestar regresiones: un menú puede responder antes y, al mismo tiempo, perder navegación por teclado; un formulario puede pintar rápido pero permitir envíos duplicados. Rendimiento, accesibilidad y lógica de negocio comparten el mismo recorrido.

Convierte la corrección en un criterio de aceptación

Antes de cerrar el trabajo, registra:

• Periodo, dispositivo, plantilla y fuente de la línea base de campo.
• Control exacto, estado previo y cuadro esperado tras la interacción.
• Pasos para reproducir y archivo de la traza de laboratorio.
• Fase dominante y evidencia que sostiene la hipótesis.
• Cambio aplicado, versión y responsable técnico.
• Pruebas de teclado, foco, error, doble acción y funciones relacionadas.
• Resultado inmediato bajo las mismas condiciones de laboratorio.
• Método y ventana para revisar la señal de campo después de publicar.

Ese contrato evita dos cierres prematuros: “PageSpeed ya está verde” y “el código se siente más rápido”. Un proyecto de sitios y aplicaciones debe entregar una interacción verificable, no sólo una puntuación ni una lista de archivos modificados.

Empieza por el clic que sí importa

Para diagnosticar INP, no necesitas rediseñar primero. Necesitas encontrar una interacción real, observarla en campo cuando exista información suficiente, reproducirla, separar sus tres fases y comprobar el cambio. Esa secuencia reduce apuestas grandes y deja evidencia reutilizable para la siguiente plantilla.

Si tu sitio parece listo pero menús, filtros, formularios o botones siguen respondiendo tarde, comparte con Albi el recorrido que quieres revisar. Podemos delimitar una interacción crítica, la evidencia disponible y el criterio de aceptación antes de estimar una optimización o una intervención mayor.