Interaction to Next Paint - Temps de traitement

Problèmes d'Interaction to Next Paint (INP) causés par le temps de traitement

Dans notre article précédent, nous avons parlé de l'Interaction to Next Paint et de 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 vais me concentrer sur le 'temps de traitement'. Comment cela affecte les problèmes d 'Interaction To Next Paint et ensuite expliquer comment minimiser le temps de traitement 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 la page. Cet INP peut être décomposé en 3 composants : 'délai d'entrée', 'temps de traitement' et 'délai de présentation'. Le temps de traitement est un contributeur majeur à l'INP total, représentant environ 40% du délai en moyenne.  Cela signifie que l'optimisation de votre code JavaScript, en particulier les gestionnaires d'événements, peut avoir un impact significatif sur le score INP de votre site web.

CONSEIL INP : le temps de traitement peut être optimisé en exécutant immédiatement le code important qui précède la mise à jour de la mise en page et en planifiant tout autre code pour qu'il s'exécute après cela.

Qu'est-ce que le temps de traitement ?

L'Interaction to Next Paint (INP) peut être décomposé en 3 sous-parties : 'Input Delay' (Délai d'entrée), 'Processing Time' (Temps de traitement) et 'Presentation Delay' (Délai de présentation)

Le temps de traitement fait référence au temps nécessaire au navigateur pour traiter le callback d'événement associé après qu'un utilisateur interagit avec une page web (par exemple, en cliquant sur un bouton ou en appuyant sur une touche). Bien qu'il y ait toujours un certain temps de traitement, les problèmes INP surviennent lorsque les callbacks d'événements prennent trop de temps de traitement.

Le temps de traitement et l'INP

Le temps de traitement pourrait être 'la chose' à laquelle vous pensez lorsque vous optimisez l'Interaction To Next Paint. C'est le 'travail qui doit être fait' avant que la mise en page puisse être mise à jour par le navigateur.

De nombreux développeurs pensent à améliorer l'INP en termes d'optimisation de la fonction de callback (optimisation du temps de traitement) et ils ont raison. Mais en termes d'importance, le temps de traitement n'est même pas la partie la plus importante à améliorer, mais il représente tout de même, en moyenne, environ 40% du temps total 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 traitement représente 40% de l'Interaction to Next Paint. Et bien que ce soit beaucoup, optimiser le temps de traitement seul ne suffira probablement pas à résoudre les problèmes INP

Exemple de temps de traitement : Lorsqu'un utilisateur interagit avec une page web, comme en cliquant sur un bouton, le temps nécessaire au gestionnaire d'événements associé à ce clic pour terminer son exécution est connu sous le nom de temps de traitement. Par exemple, si un utilisateur clique sur un bouton pour soumettre un formulaire, le code qui valide les données du formulaire, les envoie au serveur et gère la réponse contribuerait au temps de traitement. Plus ces opérations prennent du temps, plus le temps de traitement est long, et potentiellement plus le score INP est mauvais.

Qu'est-ce qui cause un temps de traitement élevé ?

Pour commencer à corriger les problèmes INP causés par un temps de traitement élevé, nous devons comprendre quelles peuvent en être les causes possibles.  Un temps de traitement élevé, le temps nécessaire aux callbacks d'événements pour s'exécuter jusqu'à la fin, peut être causé par du code inutile, du code non optimisé, des callbacks groupés (clustered) et le layout thrashing. Examinons de plus près ces 4 domaines.

1. Code inutile. Le vieux code inutilisé ou le code sans pertinence immédiate pour l'interaction utilisateur peut prolonger le temps d'exécution du callback.
   
2. Code non optimisé. Un code inefficace (généralement des boucles ou des recherches DOM inefficaces) peut ralentir l'exécution des callbacks d'événements plus que nécessaire.
   
3. Callbacks groupés (Clustered callbacks) : Plusieurs callbacks d'événements planifiés de manière rapprochée créent une file d'attente. Si un callback déclenché par l'interaction utilisateur reste bloqué dans cette file d'attente, la réponse semble retardée.
   
4. Layout thrashing : Les manipulations DOM fréquentes qui déclenchent des recalculs de mise en page peuvent solliciter le navigateur et entraîner des régressions de performance.

Minimiser le temps de traitement

Pour minimiser le temps de traitement, nous devons faire en sorte que le code responsable de la mise à jour ultérieure de la mise en page s'exécute aussi vite que possible. Nous pouvons le faire en optimisant le code existant (supprimer le code inutile et optimiser le code actuel) et en distinguant le code qui doit s'exécuter avant et après la mise à jour de la mise en page. Fondamentalement, le code critique pour la mise à jour de la mise en page doit s'exécuter avant, et tout autre code peut s'exécuter après la mise à jour de la mise en page.

1. Supprimer le code inutilisé.  Bien que la suppression du code inutilisé puisse sembler évidente, sur la plupart des sites, il y a au moins du vieux code inutilisé qui s'exécute sans vraiment ajouter quoi que ce soit à la page ni à l'UX (User Experience).  Cela signifie que la première chose à faire est de s'assurer qu'aucun code non nécessaire ne s'exécute. Cela peut être fait de plusieurs manières. Par exemple par un processus appelé tree shaking ou code splitting. Ou manuellement en inspectant votre couverture de code dans Chrome et aussi en utilisant un bon IDE qui signalera le code inutilisé. (Conseil pro : jetez aussi un œil critique aux ressources chargées par votre Tag Manager)
2. Minimiser le temps d'exécution des callbacks : Utilisez un profileur JavaScript pour identifier les goulots d'étranglement dans votre code et ciblez ces zones pour l'optimisation. Envisagez des techniques comme la mémoïsation, le pré-calcul et la mise en cache pour éviter les calculs redondants. (Conseil : vous pouvez utiliser le panneau Performance de Chrome pour trouver les scripts avec un long temps d'exécution !)
   
3. Prioriser le code critique et planifier le reste : Une fois le code du callback optimisé, divisez le code en code qui doit s'exécuter immédiatement et code qui peut être différé. Jetez un œil à cet exemple concret :
   
   Dans cet exemple, les callbacks de Google Tag Manager et des événements Facebook sont exécutés avant le code (REACT) qui a précédé la mise à jour de la mise en page. La solution aurait été de planifier les callbacks GTM lorsque le navigateur est inactif (idle)
4. Éviter le Layout Thrashing ou reflow. Le layout thrashing se produit lorsque les mises à jour de style et les lectures de style sont mélangées dans une boucle, obligeant le navigateur à recalculer la mise en page de nombreuses fois. 
   Pour éviter le layout thrashing, effectuez tous les changements de style (les "sets") avant de demander des valeurs de style (les "gets"). Cette approche minimise la fréquence des mises à jour de mise en page, conduisant à une page web plus rapide.
   Par instance, dans une boucle qui définit la largeur de chaque paragraphe pour correspondre à la largeur d'un élément, lisez la largeur de l'élément une fois avant la boucle et utilisez cette valeur pour mettre à jour les largeurs des paragraphes à l'intérieur de la boucle.

Comment prioriser le code critique

Le dernier point 'Prioriser le code critique et planifier le reste' peut être un peu abstrait pour beaucoup d'entre vous. Nous pouvons prioriser le Code Critique en utilisant requestIdleCallback() et en faisant un yielding au main thread.

Nous utilisons requestIdleCallback pour les tâches moins importantes qui n'ont pas besoin de s'exécuter immédiatement : Voici un exemple avant et après de planification d'un événement GTM.

/* avant :: code s'exécutant immédiatement  */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* après :: exécute le même code pendant l'inactivité du navigateur */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

L'inconvénient de requestIdleCallback est que le code peut ne pas s'exécuter aussi vite que vous le souhaiteriez. Dans ce cas, nous pouvons 'céder au main thread' (yield to main thread) après l'exécution du code le plus important et, ce faisant, donner au navigateur un moment pour exécuter les mises à jour de mise en page. Voici un exemple sur la façon de diviser les tâches en cédant au main thread

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

async function handleClick(){
 // faire les mises à jour de mise en page les plus importantes ici
 await yieldToMain();
 // faire les autres tâches qui doivent s'exécuter dès que possible après la mise à jour de mise en page
}

À l'avenir, nous pourrions faire beaucoup plus avec window.scheduler que simplement céder au main thread. Nous pourrions également prioriser les tâches en utilisant l'API scheduler (voir Tableau de support).

L'API scheduler fournit la fonction postTask() pour une planification plus fine des tâches en définissant des priorités, ce qui aide le navigateur à prioriser le travail afin que les tâches de faible priorité cèdent la place au main thread. 

La fonction postTask() accepte trois paramètres de priorité : 'background' pour les tâches de priorité la plus basse, 'user-visible' pour les tâches de priorité moyenne, et 'user-blocking' pour les tâches critiques nécessitant une haute priorité. 

En priorisant les tâches critiques avec 'user-blocking', les développeurs peuvent s'assurer qu'elles sont exécutées avec une priorité plus élevée, permettant au navigateur de gérer les interactions utilisateur de manière plus réactive. L'API scheduler fournit la fonction postTask() pour une planification plus fine des tâches en définissant des priorités, ce qui aide le navigateur à prioriser le travail afin que les tâches de faible priorité cèdent au main thread. 

Implications Pratiques

Venons-en à la question la plus importante : 'Qu'est-ce que tout cela signifie pour mon site'. Décomposons cela pour WordPress & REACT et voyons comment vous pouvez améliorer l'Interaction to Next Paint en ce qui concerne le temps de traitement.

WordPress

WordPress offre très peu de contrôle en ce qui concerne les scripts. De nombreux scripts sont ajoutés via des plugins. La plupart du temps, ces scripts ajouteront des 'event listeners' à la page qui ne font rien d'autre que retarder l'Interaction to Next Paint (INP).  Si votre site WordPress rencontre des problèmes avec l'Interaction to Next Paint causés par un long temps de traitement, prenez les mesures suivantes :

• Vérifiez les paramètres du thème. Décochez toutes les options inutiles comme 'smooth scroll' ou 'menu animé'. Des paramètres comme ceux-ci ont tendance à causer des problèmes INP.
• Vérifiez quels scripts sont responsables du long temps de traitement (conseil : utilisez le panneau Performance de Chrome). Si ces scripts sont liés à des plugins, envisagez de trouver un autre plugin qui fait à peu près la même chose
• Souvent, il y a des scripts personnalisés qui s'exécutent sur la page. Vérifiez ces scripts et assurez-vous qu'ils cèdent souvent au main thread et enveloppez les callbacks moins importants dans une fonction requestIdleCallback
• Déchargez les scripts inutilisés page par page (conseil : utilisez wp_deregister_script). Certains plugins ont tendance à injecter des scripts sur chaque page même lorsque la fonctionnalité n'est pas nécessaire.
• Vérifiez votre Tag Manager et supprimez les tags inutilisés ou non nécessaires.
• Utilisez des thèmes légers et propres. Souvent, les thèmes multi-usages qui 'font tout' ont tendance à avoir plus de scripts
• Évitez les constructeurs de pages (page builders) car ils dépendent souvent fortement du JavaScript pour présenter les pages à l'utilisateur final

REACT / NextJS

Les hooks et fonctionnalités de React permettent de réduire le temps de traitement INP :

Prioriser l'Interaction Utilisateur avec les Fonctionnalités de Concurrence de React :

Les fonctionnalités de concurrence de React introduites dans les versions 16 et 18 fournissent des hooks et des mécanismes pour optimiser le rendu pour une expérience utilisateur plus fluide, en particulier lors de la saisie (input).

• useTransition & startTransition : Marquez les mises à jour non critiques pour un rendu ultérieur. Cela empêche les mises à jour importantes de bloquer l'interaction utilisateur.
• useDeferredValue : Divisez votre interface utilisateur en sections essentielles et moins critiques. React peut interrompre le rendu des parties moins critiques pour une expérience plus réactive.
• useOptimistic : Affichez un état temporaire et optimiste pendant que les opérations asynchrones (comme les requêtes réseau) sont en cours. Cela maintient l'interface utilisateur réactive même pendant la récupération des données.

Suspense pour la Récupération de Données (React 18+):

Suspense dans React 18 peut être utilisé pour améliorer l'INP (Interaction to Next Paint) en permettant au navigateur de prioriser les interactions utilisateur et d'optimiser le rendu. Alors que React 16 a introduit Suspense pour le code splitting, React 18 étend cette fonctionnalité pour englober la récupération de données.

• Un composant de repli (fallback), comme un indicateur de chargement, s'affiche pendant que les données chargent.
  
• Une fois les données arrivées, React reprend le rendu du composant suspendu.
• Suspense, combiné au rendu interruptible dans Concurrent React, priorise les interactions utilisateur. Si un utilisateur interagit avec un composant suspendu, React priorise le rendu de ce composant, maintenant la réactivité.

Dans l'ensemble, ces fonctionnalités fonctionnent ensemble pour garantir que React priorise les interactions utilisateur et évite de bloquer l'interface utilisateur pendant les mises à jour ou la récupération de données.