Optimiser l'interaction avec Next Paint : un guide étape par étape

Cet article a été sponsorisé par DebugBear. Les opinions exprimées dans cet article sont celles du sponsor.

Garder votre site Web rapide est important pour l’expérience utilisateur et le référencement.

L'initiativeCore Web Vitals de Google fournit un ensemble de mesures pour vous aider à comprendre les performances de votre site Web.

Les trois métriques Core Web Vitals sont :

• La plus grande peinture de contenu (LCP)
• Changement de mise en page cumulatif (CLS)
• Interaction avec la peinture suivante (INP)

Cet article se concentre sur la métrique INP récemment introduite et sur ce que vous pouvez faire pour l'améliorer.

Comment l’interaction avec la prochaine peinture est-elle mesurée ?

INP mesure la rapidité avec laquelle votre site Web répond aux interactions des utilisateurs – par exemple, un clic sur un bouton. Plus précisément, INP mesure le temps en millisecondes entre la saisie de l'utilisateur et le moment où le navigateur a fini de traiter l'interaction et est prêt à afficher toutes les mises à jour visuelles sur la page.

Votre site Web doit terminer ce processus en moins de 200 millisecondes pour obtenir un score « Bon ». Les valeurs supérieures à une demi-seconde sont considérées comme « médiocres ». Un mauvais score dans une métrique Core Web Vitals peut avoir un impact négatif sur votre classement dans les moteurs de recherche .

Google collecte les données INP de vrais visiteurs sur votre site Web dans le cadre du rapport sur l'expérience utilisateur Chrome (CrUX). Ces données CrUX sont ce qui a finalement un impact sur les classements.

Comment identifier et corriger les temps d'INP lents

Les facteurs à l’origine d’une mauvaise interaction avec Next Paint peuvent souvent être complexes et difficiles à comprendre. Suivez ce guide étape par étape pour comprendre les interactions lentes sur votre site Web et trouver des optimisations potentielles.

1. Comment identifier une page avec des temps d'INP lents

Différentes pages de votre site Web auront des scores Core Web Vitals différents. Vous devez donc identifier une page lente, puis rechercher la cause de sa lenteur.

Utiliser la console de recherche Google

Un moyen simple de vérifier vos scores INP consiste à utiliser la section Core Web Vitals dans Google Search Console , qui rapporte des données basées sur les données Google CrUX dont nous avons déjà discuté.

Par défaut, les URL des pages sont regroupées en groupes d'URL qui couvrent de nombreuses pages différentes. Soyez prudent ici : toutes les pages peuvent ne pas présenter le problème signalé par Google. Au lieu de cela, cliquez sur chaque groupe d'URL pour voir si des données spécifiques à l'URL sont disponibles pour certaines pages, puis concentrez-vous sur celles-ci.

Utilisation d'un service de surveillance des utilisateurs réels (RUM)

Google ne rapportera pas les données Core Web Vitals pour chaque page de votre site Web et ne fournit que les mesures brutes sans aucun détail pour vous aider à comprendre et à résoudre les problèmes. Pour l'obtenir, vous pouvez utiliser un outil de surveillance d'utilisateurs réels comme DebugBear.

La surveillance des utilisateurs réels fonctionne en installant un extrait d'analyse sur votre site Web qui mesure la vitesse à laquelle votre site Web est présenté à vos visiteurs. Une fois cela configuré, vous aurez accès à un tableau de bord Interaction avec Next Paint comme celui-ci :

Vous pouvez identifier les pages que vous souhaitez optimiser dans la liste, survoler l'URL et cliquer sur l'icône en forme d'entonnoir pour consulter uniquement les données de cette page spécifique.

2. Déterminez quelles interactions entre éléments sont lentes

Différents visiteurs sur la même page vivront des expériences différentes. Cela dépend en grande partie de la façon dont ils interagissent avec la page : s'ils cliquent sur une image d'arrière-plan, il n'y a aucun risque que la page se fige soudainement, mais s'ils cliquent sur un bouton qui démarre un traitement lourd, c'est plus probable. Et les utilisateurs de ce deuxième scénario connaîtront un INP beaucoup plus élevé.

Pour vous aider, les données RUM fournissent une ventilation des éléments de page avec lesquels les utilisateurs ont interagi et de l'ampleur des retards d'interaction.

La capture d'écran ci-dessus montre différentes interactions INP triées en fonction de la fréquence de ces interactions utilisateur. Pour rendre les optimisations aussi simples que possible, vous souhaiterez vous concentrer sur une interaction lente qui affecte de nombreux utilisateurs.

Dans DebugBear, vous pouvez cliquer sur l'élément de page pour l'ajouter à vos filtres et poursuivre votre enquête.

3. Identifiez quel composant INP contribue le plus à ralentir les interactions

Les délais INP peuvent être décomposés en trois composantes différentes :

• Délai d'entrée : code d'arrière-plan qui bloque le traitement de l'interaction.
• Temps de traitement : temps passé à gérer directement l'interaction.
• Retard de présentation : affichage des mises à jour visuelles à l'écran.

Vous devez vous concentrer sur le composant INP qui contribue le plus à la lenteur du temps INP et vous assurer de garder cela à l’esprit lors de votre enquête.

Dans ce scénario, le temps de traitement est le principal contributeur à la lenteur du temps d'INP pour l'ensemble de pages que vous consultez, mais vous devez creuser plus profondément pour comprendre pourquoi.

Un temps de traitement élevé indique qu'un code intercepte l'interaction de l'utilisateur et exécute un code lent. Si, au contraire, vous constatez un délai d'entrée élevé, cela suggère qu'il existe des tâches en arrière-plan qui bloquent le traitement de l'interaction, par exemple en raison de scripts tiers.

4. Vérifiez quels scripts contribuent à ralentir l'INP

Parfois, les navigateurs signalent des scripts spécifiques qui contribuent à une interaction lente. Votre site Web contient probablement des scripts propriétaires et tiers, qui peuvent tous deux contribuer à ralentir les temps d'INP.

Un outil RUM comme DebugBear peut collecter et faire apparaître ces données. La principale chose que vous souhaitez vérifier est de savoir si vous voyez principalement le code de votre propre site Web ou celui de tiers.

Astuce : Lorsque vous voyez un script ou une fonction de code source marqué comme « N/A », cela peut indiquer que le script provient d'une origine différente et comporte des restrictions de sécurité supplémentaires qui empêchent les outils RUM de capturer des informations plus détaillées.

Cela commence maintenant à raconter une histoire : il semble que les scripts d'analyse/tiers soient les plus grands contributeurs à la lenteur des temps INP.

5. Identifiez pourquoi ces scripts sont exécutés

À ce stade, vous soupçonnez maintenant fortement que la majeure partie du retard INP, du moins sur les pages et les éléments que vous consultez, est due à des scripts tiers. Mais comment savoir s’il s’agit de scripts de suivi généraux ou s’ils jouent réellement un rôle dans la gestion de l’interaction ?

DebugBear propose une analyse qui permet de comprendre pourquoi le code est en cours d'exécution, appelée analyse INP Primary Script Invoker. C'est un peu long : plusieurs scripts différents peuvent être impliqués dans le ralentissement d'une interaction, et ici vous ne voyez que le plus gros contributeur. Le « Invoker » est simplement une valeur que le navigateur rapporte sur la cause de l'exécution de ce code.

Les noms d'invocateurs suivants sont des exemples de gestionnaires d'événements à l'échelle de la page :

• sur clic
• sur la souris
• surpointerup

Vous pouvez les voir beaucoup dans la capture d'écran ci-dessus, qui vous indique que le script d'analyse suit les clics n'importe où sur la page.

En revanche, si vous voyiez des noms d'invocateurs comme ceux-ci qui indiqueraient des gestionnaires d'événements pour un élément spécifique sur la page :

• .load_more.onclick
• #logo.onclick

6. Examiner les pages vues spécifiques

Une grande partie des données que vous avez vues jusqu’à présent sont agrégées. Il est maintenant temps d'examiner les événements INP individuels, pour tirer une conclusion définitive sur la cause du ralentissement de l'INP dans cet exemple.

Les vrais outils de surveillance des utilisateurs comme DebugBear offrent généralement un moyen d'examiner les expériences utilisateur spécifiques. Par exemple, vous pouvez voir quel navigateur ils ont utilisé, quelle est la taille de leur écran et quel élément a conduit à l'interaction la plus lente.

Comme mentionné précédemment, plusieurs scripts peuvent contribuer à un INP globalement lent. La section Scripts INP vous montre les scripts qui ont été exécutés lors de l'interaction INP :

Vous pouvez examiner chacun de ces scripts plus en détail pour comprendre pourquoi ils s’exécutent et pourquoi ils prennent plus de temps à se terminer.

7. Utilisez le profileur DevTools pour plus d'informations

Les véritables outils de surveillance des utilisateurs ont accès à de nombreuses données, mais pour des raisons de performances et de sécurité, ils ne peuvent accéder à aucune donnée disponible. C'est pourquoi c'est une bonne idée d'utiliser également Chrome DevTools pour mesurer les performances de votre page.

Pour déboguer INP dans DevTools, vous pouvez mesurer la façon dont le navigateur traite l'une des interactions lentes que vous avez identifiées auparavant. DevTools vous montre ensuite exactement comment le navigateur passe son temps à gérer l'interaction.

Comment résoudre ce problème

Dans cet exemple, vous ou votre équipe de développement pourriez résoudre ce problème en :

• Travailler avec le fournisseur de script tiers pour optimiser son script.
• Supprimer le script s'il n'est pas essentiel au site Web, ou trouver un fournisseur alternatif.
• Ajuster la façon dont votre propre code interagit avec le script

Comment enquêter sur un délai d'entrée élevé

Dans l’exemple précédent, la majeure partie du temps INP était consacrée à l’exécution du code en réponse à l’interaction. Mais souvent, le navigateur est déjà occupé à exécuter un autre code lorsqu'une interaction utilisateur se produit. Lorsque vous étudiez les composants INP, vous verrez alors une valeur de retard d'entrée élevée.

Cela peut arriver pour diverses raisons, par exemple :

• L'utilisateur a interagi avec le site Web alors qu'il était encore en cours de chargement.
• Une tâche planifiée est en cours d'exécution sur la page, par exemple une animation en cours.
• La page charge et affiche du nouveau contenu.

Pour comprendre ce qui se passe, vous pouvez consulter le nom de l'invocateur et la section des scripts INP des expériences utilisateur individuelles.

Dans cette capture d'écran, vous pouvez voir qu'un minuteur exécute du code qui coïncide avec le début d'une interaction utilisateur.

Le script peut être ouvert pour révéler le code exact exécuté :

Le code source affiché dans la capture d'écran précédente provient d'un script de suivi des utilisateurs tiers exécuté sur la page.

À ce stade, vous et votre équipe de développement pouvez poursuivre le workflow INP présenté plus haut dans cet article. Par exemple, déboguer avec le navigateur DevTools ou contacter le fournisseur tiers pour obtenir de l'aide.

Comment enquêter sur un retard de présentation élevé

Le délai de présentation a tendance à être plus difficile à déboguer que le délai d’entrée ou le temps de traitement. Cela est souvent dû au comportement du navigateur plutôt qu'à un script spécifique. Mais comme auparavant, vous commencez toujours par identifier une page spécifique et une interaction spécifique.

Vous pouvez voir un exemple d'interaction avec un délai de présentation élevé ici :

Vous voyez que cela se produit lorsque l'utilisateur saisit du texte dans un champ de formulaire. Dans cet exemple, de nombreux visiteurs ont collé de grandes quantités de texte que le navigateur a dû traiter.

Ici, le correctif consistait à retarder le traitement, à afficher un message « En attente… » à l'utilisateur, puis à terminer le traitement plus tard. Vous pouvez voir comment le score INP s'améliore à partir du 3 mai :

Obtenez les données dont vous avez besoin pour améliorer l’interaction avec Next Paint

La mise en place d’une véritable surveillance des utilisateurs vous aide à comprendre comment les utilisateurs perçoivent votre site Web et ce que vous pouvez faire pour l’améliorer. Essayez DebugBear maintenant en vous inscrivant pour un essai gratuit de 14 jours .

Les données CrUX de Google sont agrégées sur une période de 28 jours, ce qui signifie qu'il faudra un certain temps avant de remarquer une régression. Grâce à la surveillance des utilisateurs réels, vous pouvez voir immédiatement l'impact des modifications du site Web et être automatiquement alerté en cas de changement important.

DebugBear surveille les données de laboratoire, les données CrUX et les données utilisateur réelles. De cette façon, vous disposez de toutes les données dont vous avez besoin pour optimiser vos Core Web Vitals en un seul endroit.

Cet article a été sponsorisé par DebugBear et les points de vue présentés ici représentent le point de vue du sponsor.

Prêt à commencer à optimiser votre site Web ? Inscrivez-vous à DebugBear et obtenez les données dont vous avez besoin pour offrir d'excellentes expériences utilisateur.

---

Crédits images

Image en vedette : Image de Redesign.co. Utilisé avec autorisation.