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

Identifiez l'action de l'utilisateur à l'origine de votre pire INP et corrigez en priorité le bon gestionnaire d'interaction.

Essai gratuit [include]partners.html[\/include]

Dimension : Navigation : 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 unique lors de la visite d'un utilisateur sur une page. La valeur est le nom brut de l'événement provenant de l'API Event Timing 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 l'entrée et le rendu suivant (next paint) et rapporte cette durée. La dimension du type d'entrée vous indique ce que l'utilisateur faisait à 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 tapé dans votre champ de recherche".

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

coredash metric table urls

Pourquoi le type d'entrée est important pour l'INP

Chaque type d'entrée correspond à une partie différente de votre code JavaScript. Si vous voyez keydown comme type d'entrée dominant sur une page avec un mauvais INP, vous savez immédiatement que le problème réside dans vos gestionnaires de frappe : autocomplétion, recherche instantanée, validation de formulaire s'exécutant à chaque pression de touche. Si vous voyez click, le problème se situe dans vos gestionnaires de boutons et de liens : logique de navigation, mises à jour d'état, ouvertures de modales, appels d'analyse s'exécutant de manière synchrone.

Sans cette dimension, une investigation INP commence par des sessions de profilage, des étapes de reproduction et des suppositions sur l'interaction que l'utilisateur du 75e percentile tentait d'effectuer. Avec la dimension du type d'entrée, vous passez directement au 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 experts affichera une proportion élevée d'événements keydown entraînant un mauvais INP. Un produit utilisé principalement sur mobile affichera une dominance de pointerdown. La même page, le même score INP, la même correction appliquée à 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 courants dans les données CoreDash, représentant environ 75 % des événements avec le pire INP. Sur ordinateur, click représente le relâchement d'un bouton de souris. Sur mobile, une pression déclenche toute la chaîne : pointerdown se déclenche d'abord lorsque le doigt touche l'écran, puis pointerup lorsqu'il se lève, et enfin click. CoreDash enregistre l'événement de cette chaîne qui a eu le gestionnaire le plus long.

Les gestionnaires de clics sont le lieu principal des travaux JavaScript synchrones lourds. Un simple clic sur un élément de navigation peut déclencher des mises à jour de gestion d'état, des mutations DOM, des événements d'analyse et un nouveau rendu, le tout dans la même tâche. Chaque milliseconde de travail synchrone dans un gestionnaire de clic est une milliseconde ajoutée à 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 laisser le navigateur effectuer le rendu entre elles. Déplacez les travaux non critiques comme les appels d'analyse dans un setTimeout avec un délai de zéro, ou différez-les entièrement avec requestIdleCallback. Le navigateur n'a besoin de terminer que le travail qui affecte la réponse visuelle avant le prochain rendu. Tout le reste peut attendre.

keydown

L'entrée au clavier représente environ 15 % des pires cas d'INP dans les données CoreDash, mais elle produit certains des scores les plus flagrants. La raison en est la fréquence : un utilisateur tapant dans un champ de recherche déclenche keydown à chaque frappe. Si votre gestionnaire prend 200 ms, l'utilisateur subit 200 ms de décalage après chaque caractère tapé. Une requête de recherche de 10 caractères devient 2 secondes de temps de blocage accumulé.

Les coupables habituels sont les implémentations de recherche instantanée qui déclenchent des requêtes API synchrones ou exécutent des comparaisons DOM coûteuses à chaque frappe, ainsi que la validation de formulaire qui revérifie l'intégralité du formulaire à chaque pression de touche. Ces modèles fonctionnent bien à petite échelle mais s'effondrent dans des conditions d'utilisation réelles.

Les corrections standard sont le "debouncing" et le déchargement. Appliquez un "debounce" à votre gestionnaire de recherche pour qu'il ne se déclenche qu'après une pause de l'utilisateur, généralement de 200 à 300 millisecondes. Pour les traitements plus complexes comme la recherche floue sur un large ensemble de données locales, déplacez le calcul vers un Web Worker afin que le thread principal reste libre de rendre l'image suivante après chaque événement keydown.

pointerup

Les événements de relâchement du pointeur (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 utilisateur 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 apparaît comme le type d'entrée dominant, l'investigation est la même que pour les gestionnaires de clics : trouvez quel JavaScript s'exécute dans le gestionnaire et séparez le travail qui doit bloquer le prochain rendu du travail qui peut être différé. La distinction par rapport à click est généralement une décision au niveau du framework, et non au niveau de l'application, la correction peut donc impliquer d'ajuster la manière dont la bibliothèque de composants gère les liaisons d'interaction.

Flux de travail de débogage
  1. Filtrez par type d'entrée dans CoreDash : ouvrez le détail de l'INP pour une URL en échec et vérifiez quel type d'entrée domine les pires interactions. Si un type représente plus de la moitié de vos mauvais événements INP, commencez par là. La répartition vous indique où consacrer votre temps de profilage.
  2. Reproduisez avec la bonne interaction : ouvrez les Chrome DevTools, activez le profilage des performances et effectuez exactement le type d'interaction indiqué dans CoreDash. Une page dominée par keydown doit être testée en tapant au clavier. Une page dominée par click doit être testée avec des clics de souris sur les éléments avec lesquels vos utilisateurs interagissent. Enregistrez la trace et identifiez les tâches longues dans le thread principal qui se déclenchent immédiatement après l'événement d'entrée.
  3. Appliquez la correction spécifique au type et vérifiez : pour les problèmes de keydown, ajoutez du debouncing et profilez à nouveau. Pour les problèmes de click, ajoutez des appels à scheduler.yield() aux points d'arrêt logiques du gestionnaire. Déployez dans un environnement de test, utilisez WebPageTest avec script d'interaction ou le panneau Performance des Chrome DevTools, et confirmez que la durée de la tâche diminue avant la mise en production.

    Règle d'or pour les ingénieurs