Dimensión de Core/Dash: Tipo de entrada (INP)

Dimensión: Tipo de entrada INP (inpit)

La dimensión Tipo de entrada (INP) registra el tipo de evento del DOM que activó la peor interacción durante la visita de un usuario a la página. El valor es el nombre de evento sin procesar de la API Event Timing del navegador: click, keydown, pointerdown, pointerup, keypress y algunos otros.

El INP es una métrica del peor caso. No promedia las interacciones. Encuentra la interacción que tomó más tiempo desde la entrada hasta el siguiente pintado y reporta esa duración. La dimensión de tipo de entrada te dice qué estaba haciendo el usuario en ese momento exacto. Esa es la diferencia entre saber que "el INP es de 450 ms" y saber que "el INP es de 450 ms porque el usuario escribió en tu campo de búsqueda".

La API Event Timing agrupa eventos relacionados en una sola interacción lógica. Un toque en una pantalla táctil activa pointerdown, pointerup y click como un único grupo. El manejador de eventos más largo dentro de ese grupo determina la latencia de la interacción. CoreDash registra el tipo de evento del manejador más largo, que es el que ralentizó la interacción.

Por qué importa el tipo de entrada para el INP

Cada tipo de entrada se asigna a una parte diferente de tu base de código JavaScript. Si ves keydown como el tipo de entrada dominante en una página con un INP deficiente, sabes de inmediato que el problema está en tus manejadores de pulsaciones de teclas: autocompletado, búsqueda a medida que escribes o validación de formularios que se ejecuta con cada pulsación de tecla. Si ves click, el problema está en los manejadores de tus botones y enlaces: lógica de navegación, actualizaciones de estado, apertura de ventanas modales o llamadas de analítica que se ejecutan de forma síncrona.

Sin esta dimensión, una investigación de INP comienza con sesiones de perfilado, pasos de reproducción y conjeturas sobre qué interacción intentaba realizar el usuario del percentil 75. Con la dimensión de tipo de entrada, vas directo al manejador correspondiente. El ahorro de tiempo es real.

El tipo de entrada también revela diferencias entre plataformas. Un sitio con mucha navegación por teclado por parte de usuarios avanzados mostrará una alta proporción de eventos keydown que empeoran el INP. Un producto utilizado principalmente en dispositivos móviles mostrará un predominio de pointerdown. La misma página, la misma puntuación de INP, pero la solución se aplica a diferentes manejadores según quiénes sean realmente tus usuarios.

Los tipos de entrada

click y pointerdown

Estos son los tipos de entrada más comunes en los datos de CoreDash y representan aproximadamente el 75% de los peores eventos de INP. En escritorio, click representa soltar el botón del mouse. En móviles, un toque activa la cadena completa: primero se dispara pointerdown cuando el dedo toca la pantalla, luego pointerup al levantarlo y, finalmente, click. CoreDash registra el evento de esa cadena que haya tenido el manejador más largo.

Los manejadores de click son el lugar principal donde ocurre el trabajo síncrono pesado de JavaScript. Un solo click en un elemento de navegación puede desencadenar actualizaciones en la gestión del estado, mutaciones del DOM, eventos de analítica y un re-renderizado, todo en la misma tarea. Cada milisegundo de trabajo síncrono en un manejador de click es un milisegundo que se suma al INP.

La solución para los manejadores de click lentos es la desviación de tareas. Usa <code>scheduler.yield()</code> para dividir el manejador en tareas más pequeñas y permitir que el navegador renderice entre ellas. Mueve el trabajo no crítico, como las llamadas de analítica, a un setTimeout con retraso cero, o delégalo por completo a requestIdleCallback. El navegador solo necesita completar el trabajo que afecte la respuesta visual antes del siguiente pintado. Todo lo demás puede esperar.

keydown

La entrada por teclado representa aproximadamente el 15% de los peores eventos de INP en los datos de CoreDash, pero genera algunas de las peores puntuaciones. La razón es la frecuencia: un usuario que escribe en un campo de búsqueda activa keydown con cada pulsación de tecla. Si tu manejador tarda 200 ms, el usuario experimentará 200 ms de retraso después de cada carácter que escriba. Una consulta de búsqueda de 10 caracteres se convierte en 2 segundos de tiempo de bloqueo acumulado.

Los culpables habituales son las implementaciones de búsqueda a medida que escribes que realizan peticiones API síncronas o ejecutan un costoso diffing del DOM en cada pulsación de tecla, y la validación de formularios que vuelve a verificar todo el formulario con cada pulsación. Estos patrones funcionan bien a pequeña escala y colapsan en condiciones de uso reales.

Las soluciones estándar son el debouncing y la delegación de tareas. Aplica debouncing a tu manejador de búsqueda para que solo se active cuando el usuario haga una pausa al escribir, típicamente de 200 a 300 milisegundos. Para procesamientos más complejos, como la búsqueda difusa (fuzzy search) en un conjunto de datos local grande, mueve el cálculo a un Web Worker para que el main thread quede libre para renderizar el siguiente frame después de cada evento keydown.

pointerup

Los eventos pointer up representan aproximadamente el 8% de los peores casos de INP en los datos de CoreDash. pointerup se dispara al final de una secuencia de toque o click, después de pointerdown. Algunos frameworks y librerías de UI vinculan su comportamiento principal de "click" a pointerup en lugar de a click, lo que adelanta la ejecución del manejador en el ciclo de vida de la interacción.

Cuando pointerup aparece como el tipo de entrada dominante, la investigación es la misma que para los manejadores de click: descubre qué JavaScript se ejecuta en el manejador y separa el trabajo que debe bloquear el siguiente pintado del que se puede diferir. La distinción con respecto a click suele ser una decisión a nivel de framework, no de aplicación, por lo que la solución puede requerir ajustar cómo la librería de componentes vincula las interacciones.

Flujo de trabajo de depuración

1. Filtra por tipo de entrada en CoreDash: Abre el desglose de INP para una URL con problemas y comprueba qué tipo de entrada domina las peores interacciones. Si un tipo representa más de la mitad de tus eventos de INP deficientes, empieza por ahí. La distribución te indica dónde dedicar tu tiempo de perfilado.
2. Reproduce con la interacción correcta: Abre Chrome DevTools, activa el perfilado en la pestaña Performance y realiza el tipo de interacción exacto que muestra CoreDash. Una página dominada por keydown debe probarse escribiendo. Una página dominada por click debe probarse haciendo click con el mouse en los elementos con los que interactúan tus usuarios. Registra la traza e identifica las long tasks en el main thread que se disparan inmediatamente después del evento de entrada.
3. Aplica la solución específica para el tipo de entrada y verifica: Para problemas de keydown, añade debouncing y vuelve a perfilar. Para problemas de click, añade llamadas a scheduler.yield() en puntos de interrupción lógicos del manejador. Despliega en un entorno de pruebas, usa WebPageTest con scripts de interacción o el panel Performance de Chrome DevTools, y confirma que la duración de la tarea disminuya antes de subir a producción.

Regla práctica de ingeniería

• keydown domina tu INP deficiente: Añade debouncing a todos los manejadores de búsqueda y autocompletado. Un retraso de 200 ms es el punto de partida estándar. Si el cálculo es costoso incluso con ese retraso, muévelo fuera del main thread con un Web Worker.
• click o pointerdown dominan: Tus manejadores están haciendo demasiado trabajo síncrono antes de que el navegador pueda pintar. Audita cada manejador de click en la URL con problemas. Elimina las llamadas de analítica síncronas. Divide la lógica de varios pasos con scheduler.yield() entre cada paso.
• pointerup domina: Comprueba si tu framework está vinculando la lógica de interacción a pointerup en lugar de a click. La solución suele ser la misma que para los manejadores de click, pero el punto de entrada en la base de código es diferente.
• Distribución mixta sin un ganador claro: El problema no es un único tipo de interacción. Perfila las tres interacciones individuales más lentas de todos los tipos y abórdalas en orden de impacto. No optimices en abstracto.

El tipo de entrada es una señal de enrutamiento. No te dice qué es lento; te dice dónde buscar. Una vez que sabes si tus usuarios hacen click, escriben o tocan la pantalla cuando el INP falla, cada paso posterior de la investigación se vuelve más rápido y enfocado.