Interaction to Next Paint - Délai d'entrée

Problèmes d'Interaction to Next Paint (INP) causés par le délai d'entrée

Dans notre article précédent, nous avons parlé de l'Interaction to Next Paint et de la façon d'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 "délai d'entrée" (Input Delay). Comment cela affecte les problèmes d 'Interaction to Next Paint, puis j'expliquerai comment minimiser les délais d'entrée pour améliorer l'Interaction to Next Paint !

CONSEIL INP : la plupart du temps, le délai d'entrée se produit pendant les premières étapes de chargement de la page web !

Qu'est-ce que le délai d'entrée ?

Le délai d'entrée fait référence au temps qu'il faut au navigateur pour commencer à traiter un rappel d'événement (event callback) après qu'un utilisateur a interagi 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 délai d'entrée (même les navigateurs ont besoin de temps pour planifier les rappels), le délai d'entrée se produit lorsque le navigateur est occupé à effectuer d'autres tâches planifiées et ne peut pas planifier immédiatement les rappels demandés par l'interaction.

Le délai d'entrée et l'INP

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

Vous remarquerez peut-être qu'il y a des similitudes de nom entre le délai d'entrée et l'ancien Core Web Vital "First Input Delay". Pour ceux qui ne le savent pas : l'Interaction to Next Paint est le successeur du "First Input Delay" qui a été retiré. Le First Input Delay mesurait le temps entre la première interaction et le rappel de l'événement. Même si le First Input Delay a été retiré, le "délai d'entrée" joue toujours un rôle important dans l'amélioration de la réactivité du web car le délai d'entrée est à la base de chaque Interaction to Next Paint.

L'importance du délai d'entrée

Étant donné que de nombreux développeurs pensent à améliorer l'INP en termes d'optimisation de la fonction de rappel (optimisation du temps de traitement), le "délai d'entrée" est souvent négligé. Certes, le délai d'entrée n'est généralement pas la plus grande partie de l'INP, mais néanmoins, si nous optimisons le délai d'entrée, nous optimiserons souvent toutes les interactions INP à la fois !

Chez CoreDash, nous collectons des millions de points de données Core Web Vitals chaque heure. Sur la base de ces données, le délai d'entrée ne représente que 18 % de l'Interaction to Next Paint. Et bien que ce ne soit pas autant que le délai de présentation ou le temps de traitement, c'est tout de même une part significative.

Causes du délai d'entrée :

Le délai d'entrée se produit lorsque le fil principal (main thread) est occupé à exécuter d'autres tâches. Ces tâches peuvent provenir de :

1. Tâches précoces. Les scripts normaux, différés (deferred) et asynchrones (async) qui sont mis en file d'attente tôt créeront des tâches précoces
   
2. Tâches planifiées. Certaines tâches ne s'exécutent pas au début du chargement de la page mais peuvent être planifiées pour après le chargement de la page. Ces tâches peuvent également interférer avec l'INP et provoquer un délai d'entrée. Par exemple, les scripts qui s'exécutent après l'événement window.onload ou les scripts qui sont retardés par des plugins dits d'optimisation.
   
3. Tâches répétitives. Les tâches récurrentes via setInterval() qui prennent un temps relativement long à s'exécuter peuvent coïncider avec l'INP
4. Rappels (callbacks) qui se chevauchent : Les rappels qui se chevauchent sont une cause fréquente de délai d'entrée. Plusieurs rappels planifiés très près les uns des autres peuvent créer une file d'attente, retardant le traitement de l'interaction suivante.

Minimiser le délai d'entrée

1. Divisez les longues tâches précoces en plusieurs tâches plus petites. Pendant les longues tâches, le navigateur ne peut pas répondre aux entrées de l'utilisateur, alors qu'après chaque tâche courte, le navigateur peut répondre. Divisez donc les longues tâches avec scheduler.yield() (expérimental) ou en enveloppant chaque fonction dans un délai d'attente de 0 avec setTimeout(callback,0)
2. Gérez les éléments interactifs. Envisagez de ne pas présenter d'éléments interactifs (comme une barre de recherche) avant que le code JavaScript qui les contrôle ne soit entièrement chargé. Cela empêchera les clics précoces sur des éléments qui ne sont pas prêts à recevoir des clics. Pour optimiser l'UX pour ce modèle, vous pouvez soit prioriser le chargement du JavaScript nécessaire, soit masquer/désactiver temporairement l'élément jusqu'à ce qu'il soit fonctionnel.
3. Exécution de scripts pendant le temps d'inactivité : Planifiez l'exécution des scripts non critiques pendant les périodes d'inactivité du navigateur avec requestIdleCallback(). RequestIdleCallback s'exécute lorsque le navigateur est inactif et n'a pas besoin de traiter les entrées de l'utilisateur.
4. Utilisez des Web Workers pour exécuter JavaScript hors du fil principal du navigateur. Les Web Workers permettent au script de s'exécuter hors du fil principal. Cela empêchera le fil principal de bloquer et de causer des problèmes de délai d'entrée INP.
5. Vérifiez les entrées en attente pendant les tâches répétitives. Avant d'exécuter un ensemble ou des tâches planifiées, vérifiez les entrées en attente avant de démarrer les tâches. S'il y a une entrée en attente, cédez (yield) d'abord au fil principal.
6. Supprimez le code inutile. Auditez régulièrement vos scripts et supprimez tout code inutile ou même des scripts car chaque ligne de code peut potentiellement causer un délai d'entrée qui affecte l'Interaction to Next Paint.

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

Implications pratiques

Passons à la question la plus importante : "Qu'est-ce que tout cela signifie pour mon site". Décomposons cela pour WordPress & REACT.

WordPress

WordPress, de par sa nature, est souvent livré avec un thème et un grand nombre de plugins. Les plugins et les thèmes dépendent souvent de JavaScript pour la fonctionnalité. Étant donné que ces plugins et thèmes sont maintenus par des développeurs tiers, nous n'avons aucun contrôle sur le contenu. Cela signifie que nous ne pouvons pas modifier les fichiers et optimiser le "mauvais code". Même si les scripts se comportent bien, rien ne garantit qu'ils le feront à l'avenir.

Donc, pour minimiser le délai d'entrée et optimiser l'Interaction to Next Paint (INP), faites ce qui suit :

• Évitez d'utiliser des plugins autant que possible. Bien que les plugins soient un moyen facile d'ajouter des fonctionnalités, ils ajoutent souvent des scripts à la page. Ces scripts provoqueront un délai d'entrée qui impacte l'INP. Pour chaque plugin, demandez-vous : puis-je obtenir la même fonctionnalité avec du code personnalisé ?
• Choisissez des thèmes légers. De nombreux thèmes WordPress "offrent tout". Bien que cela semble être une excellente idée, cela signifie qu'ils sont probablement remplis de fonctionnalités qui ne sont pas utilisées mais qui prennent un temps CPU précieux.
• Évitez les constructeurs de pages (Page builders). Les constructeurs de pages comme Elementor ou WPBakery vous donnent une interface visuelle conviviale pour construire des mises en page. Malheureusement, ils dépendent souvent de scripts pour présenter cette mise en page aux visiteurs.
• Ne chargez les scripts que lorsqu'ils sont nécessaires. WordPress a tendance à charger tous les scripts sur toutes les pages. Pour corriger cela, créez simplement un thème enfant et désenregistrez les scripts inutiles par type de page. Par exemple :

function my_deregister_scripts() {
  if ( ! is_page( 'contact' ) ) { 
    // Example: Deregister contact form script on non-contact pages
    wp_dequeue_script( 'contact-form-script' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts' );

REACT / NextJS

Les sites React ou NextJS sont principalement propulsés par JavaScript. L'exécution de ces scripts prendra du temps et causera un délai d'entrée pour l'Interaction to Next Paint (INP)

• Utilisez des composants serveur (Server components). Les composants serveur sont rendus sur le serveur et non sur le client, ce qui conduira à une quantité réduite de JavaScript
• Chargez les scripts tiers avec la bonne stratégie. Chargez les scripts tiers après l'hydratation ou même pendant le temps d'inactivité du navigateur
• Implémentez un modèle "inactif jusqu'à urgent" (idle until urgent) : Ce modèle priorise les interactions de l'utilisateur sur les tâches d'arrière-plan et crée des états temporaires pendant que le navigateur utilise requestIdleCallback pour effectuer des tâches non critiques pendant les périodes d'inactivité du navigateur.
• Chargement paresseux (Lazy load) des composants. Chargez paresseusement les composants qui ne sont pas immédiatement nécessaires en utilisant React.lazy() ou NextJS dynamic()
• Utilisez Suspense pour les composants interactifs. Envisagez de ne rendre côté client que les composants interactifs qui ont besoin d'hydratation pour devenir interactifs.