Interaction to Next Paint - Délai de présentation

Problèmes d'Interaction to Next Paint (INP) causés par le délai de présentation

Dans notre série d'articles précédents, nous avons abordé l'Interaction to Next Paint et comment identifier les problèmes d'Interaction to Next Paint. Si vous souhaitez revoir les bases, c'est un excellent point de départ !

Dans cet article, je me concentrerai sur le « délai de présentation ». Comment cela affecte l 'Interaction To Next Paint et j'expliquerai ensuite comment optimiser le délai de présentation pour améliorer l'Interaction to Next Paint !

En bref : L'Interaction to Next Paint (INP) mesure le temps nécessaire pour voir un changement visuel sur une page après qu'un utilisateur a interagi avec celle-ci. Cet INP peut être décomposé en 3 composantes : « input delay » (délai d'entrée), « processing time » (temps de traitement) et « presentation delay » (délai de présentation). Le délai de présentation est le principal contributeur à l'INP total, représentant environ 42 % du délai d'entrée en moyenne.  Cela signifie que l'optimisation de votre présentation et la simplification du HTML peuvent avoir un impact significatif sur le score INP de votre site web.

Délai de présentation : Avez-vous déjà cliqué sur un bouton et vous êtes-vous demandé pourquoi il fallait une fraction de seconde de trop pour voir le résultat ? C'est l'Interaction To Next Paint (INP) en action. Le délai de présentation est la dernière étape du processus d'interaction, intervenant après le traitement de votre clic mais avant que vous ne voyiez des changements visuels. 

Comprendre le délai de présentation

La présentation est la phase finale d'une interaction, le délai de présentation représente le temps nécessaire au navigateur pour effectuer le rendu des mises à jour visuelles qui suivent l'interaction. Le délai de présentation commence lorsque les gestionnaires d'événements pour l'interaction ont fini de s'exécuter et se termine lorsque la frame suivante (contenante les changements visuels) est peinte. Le délai de présentation peut être affecté par divers facteurs, notamment la complexité de la mise en page, la taille du DOM et la quantité de travail de rendu requise.

L'Interaction to Next Paint (INP) peut être décomposée en 3 sous-parties : « Input Delay », « Processing Time » et « Presentation Delay »

Délai de présentation et l'INP

La présentation est la dernière phase de l'INP. En moyenne, le délai de présentation représente environ 42 % du temps total de l'INP.

Chez CoreDash, nous collectons des millions de points de données Core Web Vitals chaque heure. Sur la base de ces données, le temps de délai de présentation représente 42 % de l'Interaction to Next Paint. 

Délai de présentation : Imaginez que vous êtes sur votre téléphone et que vous naviguez sur un site e-commerce pour une nouvelle paire de chaussures. Vous appuyez sur une image de produit pour voir plus de détails. Cependant, votre téléphone est un peu ancien et a du mal à suivre. Dans cette situation, vous pourriez rencontrer une mauvaise métrique d'Interaction to Next Paint (INP). Voici ce qui se passe : Vous appuyez sur l'image (Interaction). Le téléphone prend un certain temps pour traiter la demande et mettre à jour l'affichage (Processing Time). Le site web doit récupérer les informations supplémentaires sur le produit et effectuer le rendu de la nouvelle page avec l'image plus grande et les détails (cela peut être plus lent en raison de facteurs tels qu'une connexion Internet lente ou une page produit complexe avec de nombreux éléments). Enfin, il faut un temps perceptible pour que les nouveaux détails du produit et l'image apparaissent sur votre écran (Délai de présentation). Ce retard dans l'INP peut être frustrant pour les utilisateurs et c'est pourquoi il est important de le corriger.

Réduire le délai de présentation

Minimiser le délai de présentation est souvent nécessaire pour valider la métrique Interaction to Next Paint (INP) et garder votre page réactive. Une stratégie efficace consiste à minimiser la taille du Document Object Model (DOM). Un DOM plus petit conduit généralement à des temps de rendu plus rapides, car le navigateur a moins de contenu à traiter et à mettre à jour. Les développeurs doivent s'efforcer de garder le DOM petit et simple, en utilisant des techniques telles que le chargement différé (lazy loading) du contenu hors écran avec la propriété content-visibility. De plus, il est important d'être attentif à la quantité de travail de mise en page déclenchée par une interaction. Un travail de mise en page excessif peut augmenter considérablement le délai de présentation, conduisant à une expérience utilisateur moins réactive.

Le rendu côté client du HTML peut également avoir un impact sur le délai de présentation, en particulier dans les Single Page Applications (SPAs). Lorsque le HTML est créé dynamiquement côté client à l'aide de JavaScript, cela peut entraîner de longues tâches qui bloquent le thread principal, retardant potentiellement la présentation de la frame suivante. Les développeurs doivent examiner attentivement les implications en termes de performances du rendu côté client et s'efforcer de minimiser la quantité de HTML généré dynamiquement.

Identifier les longs délais de présentation

Pour identifier les longs délais de présentation, vous pouvez utiliser le profileur de performances de Chrome. Ouvrez les devtools (Ctrl-shift-i), naviguez vers l'onglet performance, appuyez sur enregistrer et interagissez avec la page.,

Vous pouvez maintenant analyser la chronologie d'une interaction et visualiser les différentes phases, y compris le délai de présentation. En examinant les mises à jour de rendu qui se produisent après la fin de l'exécution des gestionnaires d'événements, vous pouvez identifier les goulots d'étranglement contribuant à un long délai de présentation. 

Identifier le délai de présentation avec les données RUM

Plus d'informations sur les causes du délai de présentation avec les Long Animation Frames

L'API Long Animation Frames (LoAF) fournit des informations détaillées sur les causes des retards de rendu, y compris ceux survenant lors des interactions utilisateur. Cette API met en évidence les délais et autres données qui peuvent aider les développeurs à identifier les causes spécifiques des interactions lentes et à optimiser leur code en conséquence. Les outils RUM comme CoreDash prennent en charge LoAF et offrent des informations supplémentaires sur les long animation frames, telles que les données d'attribution de script. Ces outils peuvent aider les développeurs à comprendre quels scripts contribuent aux retards de rendu et à optimiser leur base de code pour une meilleure réactivité.