Pour améliorer l’INP, partez d’une interaction qui répond mal : ouverture de menu, filtre, bouton ou formulaire. Observez ce qui se passe avant la réaction visible, identifiez le travail qui retarde cette réponse, puis vérifiez une correction sur le même parcours. Un bon chargement initial ne garantit pas une interface réactive après plusieurs actions. Les données de terrain et les traces de diagnostic sont complémentaires ; le TBT d’un rapport de chargement ne doit pas être présenté comme une mesure interchangeable avec l’INP.
Relier la métrique à une action précise
L’utilisateur ne voit pas une métrique : il clique, touche un élément ou saisit une information, puis attend un effet. Commencez donc par décrire ce qu’il essaie de faire et le moment où l’interface paraît bloquée. « Le filtre reste figé après sélection » est plus exploitable que « le site manque de performance », parce que le parcours peut être reproduit.
Choisissez une page et un état précis. Un menu au premier affichage, après navigation ou après ouverture d’un panneau peut se comporter différemment. Notez le contenu présent, le profil de l’appareil et les actions précédentes. Une trace sans ces informations peut être difficile à reproduire, même pour le développeur qui connaît l’application.
La documentation d’optimisation de l’INP sur web.dev décrit la réactivité en distinguant plusieurs moments autour de l’interaction. Retenez cette structure pour votre enquête : attente avant traitement, traitement lui-même et délai avant le retour visuel. Elle aide à éviter une correction centrée sur le mauvais endroit.
Distinguer un indicateur de terrain d’un test de chargement
Les visiteurs réels utilisent différents appareils, contenus et parcours. Une mesure de terrain peut refléter des situations que votre essai local n’a pas rencontrées. À l’inverse, une trace locale permet d’examiner un événement concret avec davantage de détails. Les deux approches répondent à des questions complémentaires et ne doivent pas être fusionnées comme si elles observaient la même série.
Dans Onde, l’intégration CrUX peut afficher un INP agrégé lorsque la configuration et les données disponibles le permettent. L’interface doit préciser la période, le profil et le périmètre URL ou origine. Une donnée à l’échelle de l’origine ne prouve pas que toutes les pages ont le même comportement. Notre guide laboratoire et terrain développe cette distinction.
Le rapport Lighthouse de chargement peut apporter des pistes sur le travail du navigateur, mais son TBT n’est pas un remplacement automatique de l’INP réel. Présentez chaque métrique avec son nom et sa méthode. Une amélioration d’un indicateur de laboratoire constitue une observation à confirmer, pas une garantie immédiate pour tous les parcours des visiteurs.
Reproduire les interactions qui comptent
Établissez une courte liste d’actions importantes : ouvrir la navigation, choisir un filtre, ajouter un élément ou valider une étape. Pour chacune, notez le résultat attendu et l’état initial. Cette liste devient un scénario de recette. Elle évite de tester seulement l’action la plus facile à reproduire alors que la gêne se situe ailleurs.
Utilisez aussi un contenu représentatif. Un filtre sur trois éléments ne met pas nécessairement en évidence le même problème qu’un filtre sur une liste réellement utilisée. Il ne faut pas inventer une charge extrême sans rapport avec le service, mais il faut éviter un exemple tellement simplifié qu’il masque la difficulté présente dans le produit.
Réalisez plusieurs passages sans changer toutes les conditions. Conservez les traces et les versions de l’application. Si le comportement varie, cherchez ce qui distingue les essais : contenu, action précédente, composant tiers ou activité locale. Une variation est une information à examiner, pas une raison de retenir uniquement le passage qui confirme l’hypothèse initiale.
Identifier le travail associé au retard
Avec les outils de diagnostic du navigateur, examinez ce qui se produit autour de l’action. Cherchez les traitements coûteux, les mises à jour importantes de l’interface et les ressources ou composants impliqués. Une liste de fichiers JavaScript ne suffit pas : il faut relier le travail observé à l’événement utilisateur et au résultat visible attendu.
Si un service tiers intervient, vérifiez sa fonction et son moment d’exécution. Le guide JavaScript et services tiers aide à organiser cette revue. La suppression d’un composant ne doit pas être décidée uniquement sur son poids ; une fonction essentielle peut nécessiter une autre approche, tandis qu’une fonction secondaire peut être déplacée dans le parcours.
Évitez de proposer une solution universelle avant d’avoir trouvé le mécanisme. Réduire un téléchargement ne résout pas forcément un traitement coûteux après un clic. De même, un affichage immédiat qui cache une opération échouée ne constitue pas une meilleure interaction. La correction doit préserver l’action attendue et rendre son état compréhensible.
Corriger avec une hypothèse vérifiable
Formulez une hypothèse limitée : « cette action reconstruit une liste trop large » ou « ce composant lance un travail secondaire avant le retour visible ». Le développeur peut alors examiner une modification ciblée. Conservez une version de référence et évitez d’appliquer simultanément plusieurs refontes qui empêcheraient d’attribuer l’effet observé.
Une intervention peut consister à réduire le travail inutile, à mieux organiser les mises à jour ou à reporter une tâche non essentielle, selon le diagnostic. Ces pistes ne sont pas des recettes automatiques. Vérifiez les dépendances et la cohérence fonctionnelle : un calcul nécessaire ne peut pas être simplement supprimé parce qu’il apparaît dans une trace.
Dans un exemple fictif, un filtre provoque une mise à jour de toute la page alors que seule une zone doit changer. L’équipe prépare une modification limitée, puis compare le même scénario. L’intérêt du cas ne réside pas dans un pourcentage inventé, mais dans le lien explicite entre l’action, le travail observé et la correction testée.
Vérifier l’accessibilité et les états de l’interface
Une interface réactive doit aussi rester compréhensible. Si une opération demande du temps, l’utilisateur doit pouvoir comprendre son état sans être poussé à cliquer plusieurs fois. Vérifiez les libellés, le focus et le comportement des commandes pendant l’action. Un indicateur visuel seul peut ne pas convenir à tous les modes d’utilisation.
Testez le clavier et les parcours d’erreur, pas seulement le clic qui réussit. Une modification destinée à améliorer la réactivité peut perturber l’ordre de navigation ou masquer un message. Le guide des contrôles d’accessibilité rappelle pourquoi un score automatique ne remplace pas cette recette humaine.
Examinez également les actions répétées. Un bouton qui répond bien une fois peut présenter un autre comportement après plusieurs utilisations. Gardez le scénario réaliste et notez les états successifs. La qualité de l’interaction dépend de la continuité du parcours, pas seulement du premier événement enregistré sur une page fraîchement ouverte.
Suivre l’effet sans annoncer une victoire prématurée
Après correction, refaites les traces locales et le parcours fonctionnel. Comparez des conditions proches et conservez la dispersion des essais. Notre protocole avant et après propose une manière de présenter l’observation sans attribuer automatiquement toute différence à la modification ni promettre un gain permanent.
Les données de terrain peuvent évoluer sur une période différente de votre test local. Regardez la date et la fenêtre de collecte, puis suivez le périmètre pertinent. Une mesure agrégée ne doit pas être interprétée comme un retour instantané sur un déploiement effectué quelques minutes auparavant. Documentez le calendrier pour éviter des conclusions prématurées.
Terminez par une décision : conserver la correction, poursuivre l’investigation ou revoir l’hypothèse. L’objectif n’est pas d’obtenir une note à afficher, mais d’améliorer les actions importantes pour les visiteurs. Un budget de performance peut ensuite aider l’équipe à éviter de réintroduire progressivement le travail qui avait été retiré.
FAQ : comprendre et améliorer l’INP
Le TBT de Lighthouse est-il identique à l’INP ?
Non. Les noms, méthodes et contextes diffèrent. Le TBT d’un test de chargement peut fournir une piste sur le travail du navigateur, mais il ne représente pas toutes les interactions réelles d’une visite. Conservez les deux indicateurs séparément et utilisez une trace d’interaction lorsque vous devez expliquer une action précise.
Pourquoi un bon score de chargement n’empêche-t-il pas un menu lent ?
Une interaction peut déclencher un travail qui n’a pas été observé dans le scénario de chargement. Décrivez l’état de la page et les actions précédentes, puis examinez une trace du menu. Une mesure générale ne remplace pas une recette des parcours importants, surtout lorsque l’application évolue après son premier affichage.
Faut-il supprimer tous les scripts tiers ?
Non. Identifiez leur rôle, leur coût observé et leur moment d’utilisation. Certaines fonctions sont nécessaires ; d’autres peuvent être réorganisées. Testez une modification sur une copie et vérifiez le parcours complet. Une amélioration de métrique obtenue en supprimant une fonction attendue ne constitue pas automatiquement une amélioration du service.
Pourquoi CrUX ne montre-t-il pas immédiatement ma correction ?
Les données de terrain affichées correspondent à une période de collecte et à un périmètre. Elles ne sont pas un relevé instantané de votre dernier déploiement. Regardez les dates et complétez l’observation avec des tests locaux contrôlés. Évitez de déclarer une correction inefficace ou réussie sans tenir compte de ce calendrier.
Quelle interaction tester en premier ?
Choisissez une action importante pour le visiteur et associée à une gêne réelle ou à un signal mesuré. Un menu principal, un filtre fréquent ou une étape de formulaire peut être prioritaire selon le site. Définissez l’état initial et le résultat attendu afin que l’équipe puisse reproduire et vérifier précisément le même parcours.