Comment optimiser l’INP et l’interactivité des pages ?

Guide pour optimiser l’INP et l’interactivité des pages

Il s'agit de la dernière mesure de Google dans le domaine des performances web, elle mesure la réactivité, de manière similaire mais plus précise que le First Input Delay (FID), et elle est déjà candidate pour entrer parmi les Core Web Vitals : nous parlons de l'INP, Interaction to Next Paint, qui mesure la rapidité avec laquelle une page répond à l'entrée d'un utilisateur, mais cette fois-ci nous nous concentrons sur des conseils pour optimiser les performances de nos pages et ainsi dépasser les seuils optimaux. En bref, nous allons chercher comment intervenir techniquement pour améliorer la métrique INP et, surtout, offrir toujours de bonnes performances à nos utilisateurs.

L’importance de la métrique INP

L'article de Jeremy Wagner et Philip Walton paru sur web.dev nous guide vers cet objectif. Ils expliquent tous les détails utiles sur ce qui pourrait devenir l'une des mesures clés également en termes de référencement et de positionnement.

Bien qu'il soit encore défini comme expérimental, l'INP promet en fait de fournir une mesure beaucoup plus précise de la réactivité d'une page que le First Input Delay, car il prend en compte toutes les interactions de la page et la latence complète de l'interaction, alors que le FID mesure la première interaction et uniquement le délai d'entrée de cette interaction (avec des mesures donc plus rapides, avec des seuils plus bas), et il ne serait donc pas trop surprenant qu'il soit inclus dans la liste des Core Web Vitals, qui, comme nous le savons, sont un facteur de classement officiel pour Google, inclus dans le Page Experience System.

Il est donc utile de commencer à se familiariser avec cette métrique dès le départ, en se rappelant d'abord ce qu'elle signifie et ce qu'elle mesure avant de se pencher sur les interventions techniques nécessaires pour optimiser nos pages.

Comme le rappellent Wagner et Walton, Interaction to Next Paint (INP) est une métrique expérimentale qui évalue la réactivité, c'est-à-dire la réactivité globale d'une page aux interactions de l'utilisateur, en examinant la latence de toutes les interactions de type clic, tapotement ou frappe au clavier qui se produisent pendant la visite d'une page par un utilisateur. La valeur finale de l'INP correspond à l'interaction la plus longue observée, en ignorant les valeurs aberrantes : en pratique, l'INP commence au toucher et se termine lorsque l'utilisateur voit quelque chose de différent sur l'écran, recevant un retour d'information indiquant que son interaction a déclenché le changement, et mesurant ainsi la rapidité avec laquelle la page répond à l'entrée de l'utilisateur.

Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir une Interaction to Next Paint de 200 millisecondes ou moins ; pour s'assurer que nous atteignons cet objectif pour la majorité de nos utilisateurs, un bon seuil à mesurer est le 75e percentile des chargements de pages, segmenté entre les appareils mobiles et de bureau.

Selon le site web, il peut y avoir peu ou pas d'interaction, par exemple des pages composées principalement de texte et d'images avec peu ou pas d'éléments interactifs. À l'inverse, dans le cas de sites web tels que des éditeurs de texte ou des jeux intégrés au navigateur, les interactions peuvent se compter par centaines, voire par milliers. Dans les deux cas, si l'INP est élevé, l'expérience de l'utilisateur est menacée.

Comment optimiser l’INP sur les pages du site

Améliorer l'INP demande du temps et des efforts, affirment les Googlers, mais la récompense est une meilleure expérience utilisateur et il existe un chemin pour améliorer l'INP.

Toutefois, avant d'aborder les aspects techniques, une autre prémisse est nécessaire : toutes les interactions ne peuvent pas être attribuées à un élément spécifique, et il n'est donc pas toujours facile ou possible d'identifier l'élément à l'origine de la latence. Cela est dû, selon l'article, à une limitation de l'API Event Timing, selon laquelle la cible d'un événement peut être absente si l'élément responsable de l'interaction a été déconnecté du DOM ou si l'élément se trouve dans le DOM fantôme.

La première étape pour améliorer les performances de nos pages consiste précisément à identifier la cause d'un mauvais INP en essayant de découvrir quelles interactions tendent à être responsables de l'INP de la page, dans le nombre total d'interactions des utilisateurs avec la page. Pour ce faire, nous commençons par travailler sur des données recueillies sur le terrain et ne nous appuyons qu'ensuite sur des tests en laboratoire pour déterminer ce qui rend réellement une interaction lente.

Méthodes pour trouver des interactions lentes sur le terrain

Ainsi, les données recueillies sur le terrain devraient être le premier point de départ pour trouver les interactions lentes à l'origine d'un mauvais INP. La bibliothèque JavaScript web-vitals est un moyen de trouver ces interactions, principalement grâce à sa capacité à attribuer des valeurs INP à des éléments spécifiques via sa construction d'attribution, que nous voyons ici dans l'image (qui, comme les autres, provient du même article).

Lorsque nous exécutons cet extrait de code (qui est un exemple simpliste d'utilisation de la bibliothèque web-vitals) et que nous interagissons avec une page, la console peut afficher quelque chose comme le suivant.

Dans ce cas, on constate que l'INP de la page est dû à l'appui sur un bouton du menu de navigation, qui a pris 248 millisecondes. Avec 248 millisecondes, l'INP de cette page entre dans la catégorie "à améliorer".

Reproduire les interactions lentes en laboratoire

Une fois que les éléments responsables des interactions lentes ont été identifiés sur le terrain, nous pouvons passer aux outils de laboratoire pour commencer à les profiler, en utilisant par exemple un profileur de performances tel que celui disponible dans DevTools de Chrome.

Le processus décrit par Wagner et Walton se compose de six étapes :

1. Visitez la page qui héberge l'interaction que nous souhaitons tester.
2. Ouvrez les DevTools de Chrome en appuyant sur Cmd+Option+I (Ctrl+Alt+I sous Windows et Linux).
3. Allez dans l'onglet Performance de DevTools.
4. Cliquez sur le bouton d'enregistrement dans le coin supérieur gauche du profileur de performance vide pour commencer l'enregistrement.
5. Testez l'interaction souhaitée sur la page.
6. Cliquez à nouveau sur le bouton d'enregistrement pour arrêter l'enregistrement.

Lorsque le profileur est alimenté en valeurs, nous pouvons commencer à voir le type de travail nécessaire pour conduire l'interaction.

Dans le profileur, il y a quelques indices utiles sur l'endroit où l'interaction s'est produite, en particulier dans la trace de l'interaction située au-dessus de la trace du thread principal.

La figure montre une interaction profilée dans le profileur de performance de Chrome's DevTools : la trace d'interaction rapporte une série d'événements qui sont équivalents à une interaction de clic, et les entrées dans la trace d'interaction couvrent toutes les tâches responsables de l'interaction.

Là encore, les Googlers lancent un avertissement : il ne faut pas croire que nous sommes capables de reproduire les conditions exactes dans lesquelles un INP élevé a été signalé lorsque nous essayons de reproduire les problèmes rencontrés sur le terrain avec des outils de laboratoire. Il existe en fait de nombreux facteurs susceptibles de ralentir les réponses des appareils et il est impossible de les reproduire tous. Toutefois, si certaines interactions sont constamment lentes pour de nombreux utilisateurs, il devrait être possible de reproduire ces problèmes récurrents en imitant les conditions communes à ces utilisateurs.

Comment établir le profil de la page en l'absence de données de terrain ?

Tout le monde ne collecte pas les données de terrain des utilisateurs de son site web, mais Google suggère d'inclure la collecte de données de terrain dans nos "plans d'optimisation des performances à long terme", car cela facilitera grandement le diagnostic des problèmes. Dans tous les cas, il est toujours possible de profiler les pages et de rechercher les interactions qui pourraient être lentes, afin d'optimiser l'INP.

La première étape consiste à diagnostiquer les flux d'utilisateurs communs : par exemple, si nous avons une boutique de commerce électronique, certains flux d'utilisateurs communs peuvent être l'ajout d'articles au panier, la recherche de produits et le passage en caisse.

Lorsque nous testons ces flux d'utilisateurs en laboratoire, nous devons suivre ces directives :

• Réglez le CPU à une vitesse de 4x ou 6x pour refléter plus fidèlement les vitesses d'interaction des utilisateurs sur les appareils bas de gamme.
• Activez l'émulation mobile et choisissez un appareil mobile bas de gamme. Lorsque vous utilisez l'émulation mobile dans DevTools, la chaîne de l'agent utilisateur est remplacée par celle de l'appareil émulé, ce qui peut affecter la façon dont le balisage de la page est servi.
• Si nous en avons la possibilité, nous envisageons d'acheter un téléphone Android moins cher (comme un Moto E) aux capacités réduites et de profiler les interactions dans le laboratoire en utilisant le débogage à distance.

Après avoir évalué les flux d'utilisateurs potentiels, nous notons les interactions les plus lentes pour commencer à comprendre par où commencer l'optimisation.

Diagnostiquer et gérer les longs délais d’entrée

Le délai d'entrée est la première phase d'une interaction : c'est la période de temps entre la réception de l'action de l'utilisateur par le système d'exploitation et le début du traitement par le navigateur du premier événement généré par cette entrée.

Le délai d'entrée se termine juste au moment où les rappels d'événements d'interaction commencent à être exécutés.

L'identification du retard d'entrée dans le profileur de performance de Chrome se fait d'abord en trouvant le début d'une interaction dans le panneau d'interaction, puis en recherchant le point où l'exécution des rappels d'événements pour cette interaction commence.

Dans cette image, par exemple, nous voyons un retard d'entrée causé par une tâche lancée par le minuteur d'un script tiers, qui s'exécute pendant que l'utilisateur tente d'interagir avec la page et prolonge ainsi le retard d'entrée. La prolongation du délai d'entrée affecte la latence de l'interaction et peut donc affecter l'INP de la page.

Selon l'article, il y aura toujours un certain délai d'entrée, car le système d'exploitation prend toujours un certain temps pour transmettre l'événement d'entrée au navigateur, mais nous pouvons toujours avoir un certain contrôle sur la durée du délai d'entrée : la clé est de réaliser si un travail en cours dans le thread principal empêche l'exécution des callbacks.

Corriger les longs délais d'entrée

Lorsque les délais de saisie sont excessivement longs - on parle littéralement de longs délais de saisie - ils détériorent évidemment l'expérience de l'utilisateur, et le processus de correction du problème dépend de la situation en question.

Par exemple, s'il existe une tâche de première partie gourmande en ressources qui pourrait affecter le délai d'entrée d'une interaction, la réponse est quadruple :

• Travaillez aussi peu que possible sur toutes les tâches initiées par le code.
• Répartissez les tâches les plus longues.
• Utilisez l'API Scheduler pour hiérarchiser les tâches critiques et reporter les tâches non critiques.
• Pensez à utiliser isInputPending pour vérifier si une entrée utilisateur est en attente. Si c'est le cas, il peut être transmis au thread principal afin que les rappels d'événements pour cette entrée puissent être exécutés plus tôt qu'ils ne le seraient autrement.

Lorsque c'est le code tiers qui pose problème, il y a beaucoup d'autres éléments à prendre en compte, comme par exemple :

• Faites un inventaire complet de tous les scripts tiers présents sur le site web.
• Vérifiez si les fonctionnalités de plus d'un script tiers se chevauchent de manière significative avec les autres.
• Éliminez les scripts tiers redondants ou à faible valeur ajoutée.
• Conservez les scripts tiers restants afin qu'ils affectent le moins possible les performances.

Cela est d'autant plus difficile que le JavaScript tiers crée son propre problème dans l'environnement de travail ; par exemple, les gestionnaires de balises permettent même aux employés non techniques d'une entreprise d'ajouter très facilement des scripts tiers à l'insu de l'équipe de développement.

Travailler à l’optimisation des appels d’événements

Le délai d'entrée n'est que la première partie de ce que l'INP mesure, car nous devons également vérifier les callbacks d'événements qui sont exécutés en réponse à une interaction de l'utilisateur, qui doit être terminée aussi rapidement que possible - dans l'image, nous pouvons voir par exemple les callbacks d'événements exécutés en réponse à une simple interaction par tapotement, comme le montre le profileur de performance Chrome DevTools.

La meilleure façon de s'assurer que les rappels d'événements sont exécutés rapidement est de limiter l'exécution à la seule logique requise pour appliquer les mises à jour visuelles de la prochaine image, en reportant tout le reste à une activité ultérieure.

Par exemple, imaginons que nous utilisons un éditeur de texte qui met en forme le texte au fur et à mesure que nous le tapons, mais qui met également à jour d'autres aspects de l'interface utilisateur en fonction de ce que nous tapons, comme le nombre de mots, les erreurs d'orthographe, etc. En outre, l'application peut avoir besoin de sauvegarder ce que nous avons écrit, de sorte que si nous quittons l'application et la réintroduisons, nous ne perdons pas le travail que nous avons fait.

Dans ce cas, il y a quatre choses qui doivent se produire en réponse aux caractères tapés par l'utilisateur. Toutefois, seul le premier élément doit être exécuté avant que la trame suivante ne soit présentée :

• Mettez à jour la zone de texte avec les caractères saisis par l'utilisateur et appliquez la mise en forme requise.
• Mettre à jour la partie de l'interface utilisateur qui affiche le nombre actuel de mots.
• Exécuter la logique qui vérifie les erreurs d'orthographe.
• Sauvegarder les modifications les plus récentes (localement ou dans une base de données distante).

Le code pour ce faire pourrait ressembler à ce qui est montré dans la capture d'écran. La visualisation ci-dessous explique toutefois pourquoi le report des mises à jour non critiques après la trame suivante peut réduire le temps de traitement, et donc la latence globale de l'interaction.

Bien que l'utilisation de setTimeout() dans le cadre d'un appel à requestAnimationFrame() dans l'exemple de code ci-dessus soit quelque peu ésotérique, il s'agit d'un moyen efficace et inter-navigateurs de s'assurer que le code non critique ne bloque pas l'image suivante.

À l'avenir, avec la standardisation et la mise en œuvre de nouvelles API de planification telles que scheduler.postTask() et scheduler.yield(), il sera plus facile pour les développeurs d'écrire du code qui pourra être automatiquement priorisé sans avoir à connaître en profondeur le cycle des événements du navigateur.

Minimiser le délai de présentation (Presentation elay)

La dernière phase d'une interaction est le délai de présentation, qui commence lorsque les rappels d'événements ont fini de s'exécuter et se termine lorsque le navigateur est en mesure de présenter l'image suivante à l'écran de l'utilisateur.

Malheureusement, les retards de présentation sont ceux sur lesquels nous avons le moins de contrôle, mais il y a quelques éléments à surveiller si nous constatons que des cadres sont retardés :

1. N'abusez pas de requestAnimationFrame() pour des travaux sans rendu. Les rappels de requestAnimationFrame() sont exécutés pendant la phase de rendu de la boucle d'événement et doivent être terminés avant que la trame suivante puisse être présentée. Si nous utilisons requestAnimationFrame() pour effectuer des opérations qui n'impliquent pas de modifications de l'interface utilisateur, nous devons garder à l'esprit que nous pouvons retarder la prochaine image.
2. Faites attention à async et await et à nos hypothèses sur leur fonctionnement. Ce n'est pas parce que vous utilisez ces fonctions (ou les promesses en général) que le travail qu'elles effectuent ne bloque pas le rendu. Il est tout à fait possible qu'une fonction asynchrone - même si elle décompose le travail en un rappel dans une tâche distincte - puisse encore bloquer le rendu si le navigateur choisit de l'exécuter avant la présentation de l'image suivante. Pour cette raison, il est important que toutes les tâches soient courtes.
3. Faites attention aux rappels de ResizeObserver. Ces rappels sont exécutés avant le rendu et peuvent retarder la présentation de la trame suivante si le travail qu'ils effectuent consomme des ressources, comme dans le cas des rappels d'événements : pour éviter cette situation, il est suggéré de reporter toute logique inutile à la trame suivante.

Les cas de chevauchement d'interactions

L'article des Googlers traite également de la façon dont les interactions peuvent se chevaucher : par exemple, s'il y a de nombreuses interactions sur une courte période, il est possible que le temps de traitement ou le retard de présentation d'une interaction soit une source de retard d'entrée pour une interaction ultérieure.

Cette image nous montre la visualisation technique du problème, avec deux interactions simultanées résultant du profileur de performance DevTools de Chrome : le travail de rendu lors de l'interaction initiale par clic entraîne un retard de saisie pour l'interaction suivante par clavier.

Ces chevauchements sont difficiles à diagnostiquer sur le terrain, en partie parce qu'il est difficile de dire si la source d'un INP élevé est due à de multiples interactions interférant les unes avec les autres. La meilleure façon de réduire la mauvaise réactivité des interactions est de faire le moins de travail possible dans les rappels d'événements d'interaction et de garder les tâches courtes. Cela permet de réduire les conflits entre les interactions et donne au fil principal un peu plus d'espace pour respirer.

L’optimisation de l’INP exige de la persévérance

L'amélioration de l'INP d'un site est un processus itératif, concluent Jeremy Wagner et Philip Walton : après avoir résolu une interaction lente sur le terrain, il est très probable que (surtout si notre site web offre des tonnes d'interactivité) nous commencerons à trouver d'autres interactions lentes que nous devons également optimiser.

La clé pour améliorer l'INP est donc la persévérance. Ce n'est qu'avec la bonne patience qu'il sera possible, au fil du temps, d'amener la réactivité de notre page à un point où les utilisateurs seront satisfaits de l'expérience que nous leur offrons.

Il est également probable que, lorsque nous développerons de nouvelles fonctionnalités pour les utilisateurs, nous devrons suivre le même processus d'optimisation des interactions spécifiquement pour eux.

En bref, l'optimisation de l'INP demandera du temps et des efforts, mais ce temps et ces efforts seront bien employés, promettent les Googlers.