Dimension Core/Dash : Type d'entrée (INP)

Dimension : Type d'entrée INP (inpit)

La dimension Type d'entrée (INP) enregistre le type d'événement DOM qui a déclenché la pire interaction lors de la visite d'une page par un utilisateur. La valeur correspond au nom brut de l'événement fourni par l'Event Timing API du navigateur : click, keydown, pointerdown, pointerup, keypress et quelques autres.

L'INP est une métrique du pire cas. Elle ne fait pas la moyenne des interactions. Elle trouve l'interaction qui a pris le plus de temps entre la saisie et l'affichage suivant, et renvoie sa durée. La dimension du type d'entrée vous indique ce que faisait l'utilisateur à ce moment précis. C'est la différence entre savoir que « l'INP est de 450 ms » et savoir que « l'INP est de 450 ms parce que l'utilisateur a saisi du texte dans votre champ de recherche ».

L'Event Timing API regroupe les événements liés en une seule interaction logique. Une pression sur un écran tactile déclenche pointerdown, pointerup et click au sein d'un même groupe. Le gestionnaire d'événement le plus long de ce groupe détermine la latence de l'interaction. CoreDash enregistre le type d'événement du gestionnaire le plus long, c'est-à-dire celui qui a ralenti l'interaction.

Pourquoi le type d'entrée compte pour l'INP

Chaque type d'entrée correspond à une partie différente de votre base de code JavaScript. Si keydown est le type d'entrée dominant sur une page au mauvais INP, le problème vient de vos gestionnaires de saisie clavier : autocomplétion, recherche instantanée, validation de formulaire à chaque touche pressée. Si vous voyez click, le problème vient de vos gestionnaires de boutons et de liens : logique de navigation, mises à jour d'état, ouverture de modales, appels d'analytics synchrones.

Sans cette dimension, une investigation INP commence par des sessions de profiling, des étapes de reproduction et des suppositions sur l'interaction tentée par l'utilisateur au 75e percentile. Avec la dimension du type d'entrée, vous ciblez directement le gestionnaire concerné. Le gain de temps est réel.

Le type d'entrée révèle également des différences de plateforme. Un site avec une forte navigation au clavier par des utilisateurs avancés affichera une proportion élevée d'événements keydown à l'origine d'un mauvais INP. Un produit principalement utilisé sur mobile verra pointerdown dominer. Une même page et un même score INP peuvent nécessiter des correctifs sur des gestionnaires différents selon qui sont réellement vos utilisateurs.

Les types d'entrée

click et pointerdown

Ce sont les types d'entrée les plus fréquents dans les données CoreDash, représentant environ 75 % des événements au pire INP. Sur ordinateur, click représente le relâchement du bouton de la souris. Sur mobile, un tap déclenche toute la chaîne : pointerdown s'exécute d'abord lorsque le doigt touche l'écran, puis pointerup au relâchement, et enfin click. CoreDash enregistre l'événement de cette chaîne dont le gestionnaire a été le plus long.

Les gestionnaires de clics concentrent la majorité du travail JavaScript synchrone et lourd. Un simple clic sur un élément de navigation peut déclencher des mises à jour d'état, des mutations DOM, des événements d'analytics et un re-rendu, le tout au sein de la même tâche. Chaque milliseconde de travail synchrone dans un gestionnaire de clic s'ajoute directement à l'INP.

La solution pour les gestionnaires de clics lents est la décomposition des tâches. Utilisez scheduler.yield() pour diviser le gestionnaire en tâches plus petites et permettre au navigateur de faire un rendu entre elles. Déplacez le travail non critique, comme les appels d'analytics, dans un setTimeout sans délai, ou différez-le complètement avec requestIdleCallback. Le navigateur doit uniquement effectuer le travail qui modifie la réponse visuelle avant le prochain affichage. Tout le reste peut attendre.

keydown

La saisie au clavier représente environ 15 % des pires événements INP dans les données CoreDash, mais elle génère les scores les plus élevés. La raison est la fréquence : un utilisateur qui tape dans un champ de recherche déclenche keydown à chaque touche pressée. Si votre gestionnaire prend 200 ms, l'utilisateur subit 200 ms de latence après chaque caractère. Une saisie de 10 caractères génère alors 2 secondes de temps de blocage cumulé.

Les coupables habituels sont les implémentations de recherche instantanée qui lancent des requêtes API synchrones ou exécutent un diffing DOM coûteux à chaque touche, ainsi que les validations de formulaire qui revérifient tout le formulaire à chaque frappe. Ces schémas fonctionnent à petite échelle mais s'effondrent en conditions réelles.

Les solutions classiques sont le debouncing et le déchargement de tâches. Appliquez un debouncing à votre gestionnaire de recherche pour qu'il ne se déclenche qu'après une pause de l'utilisateur, typiquement de 200 à 300 millisecondes. Pour les traitements plus complexes comme une recherche floue sur un grand volume de données locales, déplacez les calculs dans un Web Worker pour que le main thread reste disponible pour afficher l'image suivante après chaque événement keydown.

pointerup

Les événements pointer up représentent environ 8 % des pires cas d'INP dans les données CoreDash. pointerup se déclenche à la fin d'une séquence de toucher ou de clic, après pointerdown. Certains frameworks et bibliothèques d'interface lient leur comportement de « clic » principal à pointerup plutôt qu'à click, ce qui déplace le gestionnaire plus tôt dans le cycle de vie de l'interaction.

Lorsque pointerup est le type d'entrée dominant, la méthode est la même que pour les gestionnaires de clics : identifiez le JavaScript exécuté dans le gestionnaire et séparez le travail bloquant pour l'affichage de celui qui peut être différé. La différence avec click vient généralement du framework et non de l'application. Le correctif consiste alors souvent à modifier la liaison d'interaction de votre bibliothèque de composants.

Processus de débogage

1. Filtrer par type d'entrée dans CoreDash : ouvrez la répartition de l'INP pour l'URL en échec et vérifiez quel type d'entrée domine les pires interactions. Si un seul type représente plus de la moitié de vos événements INP lents, commencez par là. La distribution vous indique où concentrer votre temps de profilage.
2. Reproduire avec la bonne interaction : ouvrez Chrome DevTools, activez le profilage de performance et effectuez précisément le type d'interaction indiqué dans CoreDash. Testez une page dominée par keydown en saisissant du texte. Testez une page dominée par click en cliquant sur les éléments ciblés par vos utilisateurs. Enregistrez la trace et identifiez les long tasks dans le main thread qui se déclenchent immédiatement après l'événement d'entrée.
3. Appliquer le correctif adapté et valider : pour les problèmes de keydown, ajoutez du debouncing puis profilez à nouveau. Pour les problèmes de click, insérez des appels à scheduler.yield() aux étapes clés du gestionnaire. Déployez dans un environnement de test, utilisez WebPageTest avec scripts d'interaction ou le panneau Performance de Chrome DevTools, et vérifiez que la durée de la tâche a diminué avant de déployer.

Règles empiriques d'ingénierie

• keydown domine votre mauvais INP : ajoutez du debouncing à tous les gestionnaires de recherche et d'autocomplétion. Un délai de 200 ms est le point de départ standard. Si le calcul reste coûteux malgré ce délai, déplacez-le hors du main thread à l'aide d'un Web Worker.
• click ou pointerdown domine : vos gestionnaires effectuent trop de travail synchrone avant que le navigateur ne puisse effectuer le rendu. Auditez chaque gestionnaire de clic sur l'URL en échec. Supprimez les appels d'analytics synchrones. Divisez la logique complexe à l'aide de scheduler.yield() entre chaque étape.
• pointerup domine : vérifiez si votre framework lie la logique d'interaction à pointerup plutôt qu'à click. Le correctif est généralement le même que pour les gestionnaires de clics, mais le point d'entrée dans la base de code est différent.
• Distribution mixte sans vainqueur clair : le problème ne provient pas d'un type d'interaction unique. Profilez les trois interactions individuelles les plus lentes, tous types confondus, et traitez-les par ordre d'impact. N'optimisez pas de manière abstraite.

Le type d'entrée est un signal d'orientation. Il ne vous dit pas ce qui est lent, il vous indique où chercher. Dès que vous savez si vos utilisateurs cliquent, saisissent du texte ou tapent sur l'écran lorsque l'INP se dégrade, chaque étape d'investigation suivante devient plus rapide et plus ciblée.