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 desencadenó la peor interacción única durante la visita de un usuario a la página. El valor es el nombre en bruto del evento de la Event Timing API del navegador: click, keydown, pointerdown, pointerup, keypress y algunos otros.

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

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

Por qué el Tipo de entrada es importante para el INP

Cada tipo de entrada se asigna a una parte diferente de su código base de JavaScript. Si ve keydown como el tipo de entrada dominante en una página con un mal INP, sabrá de inmediato que el problema está en los controladores de pulsaciones de teclas: autocompletar, búsqueda mientras se escribe, validación de formularios que se ejecuta en cada pulsación. Si ve click, el problema está en los controladores de botones y enlaces: lógica de navegación, actualizaciones de estado, apertura de modales o llamadas de analítica que se disparan de forma síncrona.

Sin esta dimensión, una investigación de INP comienza con sesiones de perfilado, pasos de reproducción y adivinando qué interacción estaba intentando el usuario del percentil 75. Con la dimensión del tipo de entrada, usted salta directamente al controlador relevante. El ahorro de tiempo es real.

El tipo de entrada también revela diferencias de plataforma. Un sitio con una gran navegación por teclado por parte de usuarios avanzados mostrará una alta proporción de eventos keydown impulsando un mal INP. Un producto utilizado principalmente en dispositivos móviles mostrará que domina el pointerdown. La misma página, el mismo puntaje de INP, la misma solución aplicada a diferentes controladores dependiendo de quiénes sean realmente sus 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 la liberación del botón del ratón. En móviles, un toque dispara la cadena completa: pointerdown se dispara primero cuando el dedo toca la pantalla, luego pointerup cuando se levanta, y finalmente click al final. CoreDash registra cualquier evento en esa cadena que haya tenido el controlador más largo.

Los controladores de clics son la ubicación principal del trabajo síncrono pesado de JavaScript. Un solo clic en un elemento de navegación puede desencadenar actualizaciones de gestión de 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 controlador de clic es un milisegundo agregado al INP.

La solución para los controladores de clic lentos es la descomposición de tareas. Use <code>scheduler.yield()</code> para dividir el controlador en tareas más pequeñas y permitir que el navegador renderice entre ellas. Mueva el trabajo no crítico, como las llamadas de analítica, a un setTimeout con retraso cero, o difiéralo por completo a requestIdleCallback. El navegador solo necesita completar el trabajo que afecta la respuesta visual antes del siguiente renderizado. Todo lo demás puede esperar.

keydown

La entrada de teclado representa aproximadamente el 15% de los peores eventos de INP en los datos de CoreDash, pero produce algunos de los puntajes más atroces. La razón es la frecuencia: un usuario que escribe en un campo de búsqueda dispara keydown en cada pulsación de tecla. Si su controlador tarda 200ms, el usuario experimenta 200ms de retraso después de cada carácter que escribe. 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 mientras se escribe que disparan solicitudes síncronas a la API o ejecutan una comparación costosa del DOM en cada pulsación de tecla, y la validación de formularios que vuelve a comprobar todo el formulario en cada pulsación. Estos patrones funcionan bien a pequeña escala y colapsan bajo condiciones reales de los usuarios.

Las soluciones estándar son el debouncing (rebote) y la descarga (offloading). Aplique debounce a su controlador de búsqueda para que solo se dispare después de que el usuario haga una pausa al escribir, típicamente de 200 a 300 milisegundos. Para un procesamiento más complejo, como la búsqueda difusa en un gran conjunto de datos local, mueva el cálculo a un Web Worker para que el hilo principal permanezca 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 clic, después de pointerdown. Algunos frameworks y bibliotecas de interfaz de usuario vinculan su comportamiento principal de "clic" a pointerup en lugar de click, lo que mueve el controlador a una etapa más temprana 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 controladores de clics: encuentre qué JavaScript se ejecuta en el controlador y separe el trabajo que debe bloquear el siguiente renderizado del trabajo que puede diferirse. La distinción respecto a click suele ser una decisión a nivel de framework, no a nivel de aplicación, por lo que la solución puede implicar ajustar cómo la biblioteca de componentes maneja la vinculación de interacciones.

Flujo de trabajo de depuración

1. Filtre por tipo de entrada en CoreDash: Abra el desglose de INP para una URL que esté fallando y verifique qué tipo de entrada domina las peores interacciones. Si un tipo representa más de la mitad de sus eventos INP deficientes, comience por ahí. La distribución le indica dónde invertir su tiempo de perfilado.
2. Reproduzca con la interacción correcta: Abra Chrome DevTools, habilite el perfilado de Rendimiento y realice el tipo de interacción exacto que se muestra en CoreDash. Una página dominada por keydown debe probarse escribiendo. Una página dominada por click debe probarse con clics del ratón en los elementos con los que interactúan sus usuarios. Grabe la traza e identifique las tareas largas en el hilo principal que se disparan inmediatamente después del evento de entrada.
3. Aplique la solución específica del tipo y verifique: Para problemas con keydown, agregue debouncing y vuelva a perfilar. Para problemas con click, agregue llamadas a scheduler.yield() en los puntos de interrupción lógicos del controlador. Implemente en un entorno de pruebas, use WebPageTest con scripting de interacciones o el panel de Rendimiento de Chrome DevTools, y confirme que la duración de la tarea disminuya antes de lanzar a producción.

Regla general de ingeniería

• keydown domina su mal INP: Agregue debouncing a todos los controladores de búsqueda y autocompletar. Un retraso de 200ms es el punto de partida estándar. Si el cálculo es costoso incluso con ese retraso, muévalo fuera del hilo principal con un Web Worker.
• click o pointerdown domina: Sus controladores están haciendo demasiado trabajo síncrono antes de que el navegador pueda renderizar. Audite cada controlador de clic en la URL que falla. Elimine las llamadas síncronas de analítica. Divida la lógica de varios pasos con scheduler.yield() entre cada paso.
• pointerup domina: Compruebe si su framework está vinculando la lógica de interacción a pointerup en lugar de click. La solución suele ser la misma que para los controladores de clics, pero el punto de entrada en el código base es diferente.
• Distribución mixta sin un ganador claro: El problema no es un solo tipo de interacción. Perfile las tres interacciones individuales más lentas en todos los tipos y abórdelas en orden de impacto. No optimice en abstracto.

El Tipo de entrada es una señal de enrutamiento. No le dice qué es lento. Le dice dónde buscar. Una vez que sepa si sus usuarios están haciendo clic, escribiendo o tocando cuando se rompe el INP, cada paso de investigación posterior se vuelve más rápido y mucho más focalizado.