Trouver et corriger les problèmes d'Interaction to Next Paint (INP)

Trouver et corriger les problèmes d'Interaction to Next Paint (INP)

Dans notre article précédent, nous avons parlé de l'Interaction to Next Paint. Si vous souhaitez en savoir plus sur les bases, c'est un excellent point de départ !

Dans cet article, je me concentrerai sur l'identification des différents problèmes d 'Interaction To Next Paint, puis j'expliquerai comment les résoudre !

CONSEIL INP : la plupart du temps, l'INP sera bien pire lorsque un utilisateur interagit avec la page pendant la phase de démarrage (startup stage) du chargement de la page. C'est pourquoi, lors du débogage de l'INP, il est judicieux de journaliser toutes les interactions ainsi que l'état de chargement de la page !

Étape 1 : Vérifier l'INP dans la Search Console

« La première étape vers la guérison est d'admettre que vous avez un problème ». Donc, avant de faire quoi que ce soit pour corriger l'Interaction to Next Paint, assurons-nous que nous avons vraiment un problème avec l'Interaction to Next Paint.

Connectez-vous à votre Google Search Console. Dans le menu de gauche, cliquez sur Core Web Vitals et sélectionnez Mobile ou Desktop (conseil : la plupart du temps, les problèmes INP se situent sur mobile, commencez donc par là)

Vous verrez ici un aperçu de tous les problèmes liés aux Core Web Vitals actuellement présents sur votre site. Si l'un de ces problèmes est lié à l'INP, nous avons confirmé qu'il y a un problème !

Étape 2 : Identifier les problèmes d'Interaction to Next Paint

La Google Search Console ne vous donne aucune information, à part des groupes d'URL, pour comprendre ce qui cause les problèmes avec l'Interaction to Next Paint. C'est pourquoi, la plupart du temps, je vois les développeurs y aller à l'aveuglette. Ils commencent par supprimer le JavaScript inutilisé (toujours une excellente idée) et décomposer le main thread (aussi une excellente idée), mais cela corrige rarement l'INP complètement.

C'est pourquoi, pour améliorer l'INP, nous devons savoir exactement ce qui se passe.

Quels éléments, lorsqu'on interagit avec eux, causent un mauvais score INP. Habituellement, un mauvais score INP n'est pas causé par un seul élément, mais par une combinaison de problèmes. Nous devons les aborder un par un, en commençant par les pires et en remontant.
Quand ces interactions se produisent-elles ? Se produisent-elles pendant la phase de démarrage du chargement de la page ou même lorsque la page principale est chargée ?
Où ces interactions se produisent-elles ? Se produisent-elles sur chaque page ou seulement sur quelques pages sélectionnées ?
Comment pouvons-nous répliquer ces interactions ? Vous avez peut-être découvert maintenant qu'il est difficile de répliquer les problèmes INP. C'est pourquoi nous devons nous donner les moyens de réussir en imitant les caractéristiques des appareils avec un mauvais score INP.

Mettre en place le suivi RUM

Pour répondre à toutes ces questions, nous devons commencer à suivre les utilisateurs réels et journaliser tous les problèmes qui pourraient survenir avec l'Interaction to Next Paint. Il existe plusieurs façons d'activer le suivi RUM. La première consiste à utiliser la bibliothèque Web Vitals et à envoyer les résultats à votre propre backend d'analyse. L'avantage de cette méthode est qu'elle est bon marché et flexible. L'inconvénient est que cela peut représenter beaucoup de travail supplémentaire.

Une bonne alternative à l'envoi de vos données Core Web Vitals vers votre propre backend est d'utiliser l'un des nombreux outils RUM disponibles. Nous avons développé Core/Dash pour ces cas d'utilisation. Core/Dash est un outil RUM peu coûteux, rapide et efficace qui fait simplement le travail ! Bien sûr, il existe de nombreuses solutions RUM et elles feront également l'affaire (à un prix plus élevé cependant).

Trouver les interactions lentes par élément causant un INP élevé

La première chose à faire est de trouver les interactions les plus « lentes » qui causent les pires scores de Time to First Byte. Listez simplement vos pages par « INP metric by Elements » dans CoreDash et vous obtiendrez vos interactions les plus lentes. Cliquez sur la première ligne pour filtrer vos métriques par ces interactions.

Trouver quand les mauvaises interactions INP se produisent

Ensuite, triez les URL filtrées par état de chargement. Cela vous donnera plus d'informations sur la cause profonde de l'INP. Dans ce cas, l'INP élevé se produit lorsque le contenu DOM a été chargé. Cela signifie que les scripts ont été analysés mais que les scripts async et les sous-ressources de la page n'ont pas encore été chargés. Dans ce cas, l'INP est causé par des clics précoces alors que le chargement de la page n'est pas complètement terminé !

Continuez en cliquant sur l'état de chargement ayant l'impact le plus élevé pour créer un autre filtre !

Trouver les URL responsables des scores INP élevés

Enfin, lorsque nous avons filtré les éléments avec l'interaction la plus lente et l'état de chargement correct, nous allons examiner les URL où l'INP est au pire. Dans ce cas, cela se produit clairement sur un ensemble spécifique de pages.

Trouver les caractéristiques des appareils

Enfin, lorsque nous avons identifié les interactions lentes, l'état de chargement et les URL qui causent une Interaction to Next Paint élevée, nous allons examiner quels types de visiteurs causent les pires scores INP. Nous examinerions la mémoire de l'appareil (Device Memory), la bande passante (Bandwidth), la taille de l'écran (Screen size), etc. Une fois que nous avons identifié ces caractéristiques, nous pouvons passer à la réplication et à la journalisation du problème !

Étape 3 : Répliquer et déboguer les interactions causant un score INP élevé

Une fois que nous avons toutes les informations dont nous avons besoin, nous pouvons commencer à creuser les problèmes sous-jacents de l'Interaction to Next Paint.

Mettez toutes les chances de votre côté : répliquez les circonstances d'échec de l'INP

La chose suivante à faire est d'essayer de recréer l'INP défaillant. Nous faisons cela en imitant les circonstances où l'INP pourrait échouer.

Utilisez le panneau Chrome Performance : Ouvrez les outils de développement Chrome (Ctrl-Shift-i) et sélectionnez le panneau Performance. Dans la barre supérieure, vous pouvez sélectionner le CPU Throttle (ralentissez-le à 4x pour émuler un appareil mobile normal), le Network Throttle (sélectionnez le préréglage fast 3g pour imiter votre appareil mobile moyen) et réglez la hardware concurrency sur 4 ou 8 pour imiter votre mobile moyen.

Pour charger Chrome avec moins de mémoire disponible (bien que la diminution des paramètres réseau et CPU fasse souvent l'affaire !), démarrez Chrome dans un conteneur docker et assignez moins de mémoire.

Recharger la page, interagir et vérifier l'INP avec le visualiseur Core Web Vitals

L'étape suivante pour trouver la cause des mauvais scores INP est de simuler les conditions et de confirmer que les scores INP sont effectivement aussi mauvais que rapporté.

Rechargez la page et cliquez sur le bon élément au bon moment

Déboguer l'INP avec une trace de performance

C'est le moment auquel vous vous êtes préparé lors des étapes précédentes. Il est temps de découvrir pourquoi une certaine interaction cause un mauvais score d'Interaction To Next Paint.

Ouvrez à nouveau la Chrome Developer Console (Ctrl-Shift-i), naviguez vers le panneau Performance et cette fois cliquez sur l'icône de flèche circulaire pour recharger la page et commencer l'enregistrement (ou utilisez le raccourci Ctrl-Shift-E).

Ouvrez à nouveau la Chrome Developer Console (Ctrl-Shift-i), naviguez vers le panneau Performance et cette fois cliquez sur l'icône de flèche circulaire pour recharger la page et commencer l'enregistrement (ou utilisez le raccourci Ctrl-Shift-E).

Étape 3 : Corriger les problèmes INP

Nous sommes maintenant à un point où nous savons quelle interaction cause notre mauvais INP et nous avons analysé exactement ce qui se passe pendant cette interaction lente. Cela signifie qu'il est temps de commencer à corriger l'Interaction to Next Paint. L'Interaction to Next Paint peut être décomposée en 3 phases : « input delay », « processing time » et « presentation delay ».

Chaque phase de l'Interaction to Next Paint doit être traitée différemment !

Minimiser l'Input Delay :

Input delay est le temps entre l'interaction avec la page et le moment où le rappel de l'événement commence à s'exécuter. Bien qu'il y ait toujours un certain input delay (même les navigateurs ont besoin de temps pour planifier les rappels), il y a quelques points à considérer :

1. Évitez les longues tâches (long tasks). Chaque fois qu'une tâche s'exécute, elle bloque le main thread et laisse les rappels d'événements en attente. C'est particulièrement important lors de l'optimisation des clics précoces (puisque la plupart des scripts s'exécuteront à ce moment-là). 
2. Soyez prudent lors de la création de nouvelles tâches. Par exemple, des tâches récurrentes via setTimeout() ou des tâches qui se produiront probablement avant l'événement INP comme les rappels sur l'événement mouseover.
3. Mesurez et évaluez l'interaction précoce. Lorsqu'un élément interactif est présenté tôt (par exemple un élément de recherche sur le site) et est contrôlé par du JavaScript qui se charge plus tard, toute interaction avec l'élément ne déclenchera pas une mise à jour immédiate de la mise en page. Priorisez la fonctionnalité ou masquez/désactivez l'élément avant qu'il ne fonctionne correctement.
4. Utilisez des web workers pour exécuter du JavaScript hors du main thread du navigateur. Les web workers permettent au script de s'exécuter hors du main thread. Cela empêchera le main thread de se bloquer et de causer des problèmes d'input delay INP
   
5. Chargez les scripts tiers non essentiels pendant le temps d'inactivité (idle time) du navigateur.  Certains scripts sont plus critiques que d'autres. Il est logique de prioriser ces scripts et de charger les scripts moins importants pendant le temps d'inactivité du navigateur. Par exemple un script de chat

Minimiser le processing time

1. Supprimez le code inutile. Le code inutile est soit du code plus ancien qui s'exécute encore, soit du nouveau code qui n'est pas nécessaire sur cette page spécifique mais qui prend quand même du temps CPU. C'est de loin le moyen le plus simple d'améliorer immédiatement l'INP.
2. Différez le code qui n'a pas besoin de s'exécuter avant le prochain paint. Séparez le code en code critique qui doit s'exécuter avant l'INP et en code non critique (par exemple l'envoi d'analyses) et planifiez cela après l'événement INP avec la méthode requestIdleCallback(). 
3. Optimisez le code qui doit s'exécuter avant le paint. Vérifiez votre code et réécrivez les parties lentes ou inefficaces.
4. Fournissez un retour immédiat. Pour les tâches compliquées ou potentiellement lentes, fournissez un retour immédiat avant d'exécuter le code principal.

Minimiser le Presentation Delay

1.  Gardez le DOM petit et simple. Fondamentalement, il sera beaucoup plus facile pour un navigateur de rendre une page avec peu de nœuds DOM simples et non imbriqués (nœuds html) que de rendre une page avec de nombreux nœuds DOM imbriqués.
   
2. Utilisez content-visibility pour le rendu paresseux (lazy-render) du contenu hors écran.  Content-visibility accélérera le rendu des parties visibles de la page en retardant le rendu du contenu hors écran en rendant ce contenu hors écran juste à temps (just-in-time).