INP Input Delay : Causes, diagnostic et correctifs

Problèmes d'Interaction to Next Paint (INP) causés par l'input delay

Cette page fait partie de notre série sur l'Interaction to Next Paint (INP). L'INP mesure le temps total écoulé entre une interaction de l'utilisateur et la mise à jour visuelle suivante. L'input delay est la première des trois phases qui composent l'INP, suivie du processing time et du presentation delay. Si vous découvrez l'INP, lisez d'abord notre guide sur la façon d'identifier et corriger les problèmes d'INP.

CONSEIL INP : la plupart du temps, l'input delay se produit pendant les premières étapes de chargement de la page web. C'est à ce moment-là que le navigateur est le plus occupé à analyser et à exécuter des scripts.

Qu'est-ce que l'input delay ?

L'input delay fait référence au temps nécessaire 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 input delay (même les navigateurs ont besoin de temps pour planifier les rappels), un input delay excessif 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.

Pendant l'input delay, l'utilisateur a déjà effectué son action (clic, tapotement ou pression de touche) mais le navigateur n'a pas encore commencé à exécuter le gestionnaire d'événements (event handler) associé. L'utilisateur ne voit aucune réponse. C'est différent du processing time, où l'event handler est activement en cours d'exécution, et du presentation delay, où le navigateur effectue le rendu de la mise à jour visuelle. L'input delay est un pur temps d'attente causé par un main thread encombré.

L'input delay et l'INP

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

Vous remarquerez peut-être des similitudes de dénomination entre l'Input Delay et l'ancien Core Web Vital « First Input Delay » (FID). L'Interaction to Next Paint a remplacent le FID en tant que Core Web Vital en mars 2024. Le First Input Delay mesurait uniquement le temps entre la première interaction et l'event callback. Même si le FID a été retiré, l'input delay compte toujours car il est à la base de chaque mesure d'Interaction to Next Paint.

L'importance de l'input delay

Comme de nombreux développeurs pensent à améliorer l'INP en optimisant les fonctions de rappel (optimisation du processing time), l'input delay est souvent négligé. Certes, l'input delay n'est généralement pas la partie la plus importante de l'INP, mais si nous optimisons l'input delay, nous optimiserons souvent toutes les interactions INP en même temps. La réduction de l'input delay profite à chaque interaction sur la page, et pas seulement à la pire.

Chez CoreDash, nous collectons des millions de points de données Core Web Vitals chaque heure. Sur la base de ces données, l'input delay représente environ 18 % de l'Interaction to Next Paint. C'est moins que le processing time ou le presentation delay, mais l'input delay est souvent la phase la plus facile à réduire car la cause profonde est presque toujours « trop de JavaScript s'exécutant au mauvais moment ».

Causes de l'input delay

L'input delay se produit lorsque le 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. Ce sont les sources les plus courantes d'input delay car elles s'exécutent pendant la fenêtre critique de démarrage lorsque les utilisateurs sont les plus susceptibles d'interagir avec la page.
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 input delay. Par exemple, les scripts qui s'exécutent après l'événement window.onload ou les scripts retardés par des plugins dits d'optimisation. En savoir plus sur quand utiliser async vs defer pour le JavaScript.
3. Tâches répétitives. Tâches récurrentes via setInterval() qui prennent un temps relativement long à s'exécuter et coïncident avec l'INP.
4. Chevauchement de rappels. Le chevauchement de rappels est une cause fréquente d'input delay. Plusieurs rappels planifiés de manière rapprochée peuvent créer une file d'attente, retardant le traitement de l'interaction suivante. Par exemple, un gestionnaire mouseover qui se déclenche juste avant un gestionnaire click peut repousser le traitement du clic de la durée de la tâche mouseover.

Minimiser l'input delay

1. Décomposer les longues tâches précoces en plusieurs tâches plus petites. Pendant les tâches longues, le navigateur ne peut pas répondre aux entrées de l'utilisateur, alors qu'après chaque tâche courte, le navigateur peut y répondre. Décomposez les tâches longues avec scheduler.yield() ou en enveloppant chaque fonction dans un timeout de 0 avec setTimeout(callback, 0).
2. Gérer les éléments interactifs. Envisagez de ne pas présenter d'éléments interactifs (like a search bar) 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 de ce modèle, vous pouvez soit donner la priorité au chargement du JavaScript nécessaire, soit masquer/désactiver temporairement l'élément jusqu'à ce qu'il soit fonctionnel.
3. Exécution de scripts en temps d'inactivité. Planifiez l'exécution de scripts non critiques pendant les périodes d'inactivité du navigateur avec requestIdleCallback(). Cette fonction s'exécute lorsque le navigateur est inactif et n'a pas besoin de traiter les entrées de l'utilisateur.
4. Utiliser les web workers pour exécuter le JavaScript en dehors du main thread du navigateur. Les web workers permettent aux scripts de s'exécuter en dehors du main thread. Cela empêchera le blocage du main thread et évitera les problèmes d'input delay de l'INP.
5. Vérifier si une entrée est en attente pendant les tâches répétitives. Avant d'exécuter un ensemble de tâches planifiées, vérifiez s'il y a une entrée en attente avant de commencer les tâches. S'il y a une entrée en attente, cédez d'abord le passage au main thread.
6. Supprimer le code inutile. Auditez régulièrement vos scripts et supprimez tout code inutile ou même des scripts entiers, car chaque ligne de code peut potentiellement causer un input delay qui affecte l'Interaction to Next Paint. Consultez notre guide sur les 14 méthodes pour différer le JavaScript pour des techniques pratiques.

Décomposer les tâches avec scheduler.yield()

L'API scheduler.yield() est la méthode recommandée pour décomposer les tâches longues. Contrairement à setTimeout(callback, 0), qui place la continuation à la fin de la file d'attente des tâches, scheduler.yield() préserve la priorité de la tâche. Cela signifie que le navigateur reprendra votre code dès que possible après avoir traité toute entrée utilisateur en attente. Voici une fonction d'aide réutilisable :

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  \/\/ Repli pour les navigateurs sans scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

\/\/ Exemple : décomposer une longue séquence d'initialisation
async function initializeApp() {
  loadCriticalFeatures();
  await yieldToMain();  \/\/ Laisser le navigateur traiter toute entrée en attente

  loadSecondaryFeatures();
  await yieldToMain();

  loadAnalytics();
  await yieldToMain();

  loadNonEssentialWidgets();
}

Pour en savoir plus sur le fonctionnement interne de scheduler.yield(), consultez le blog Chrome Developers.

Prioriser les tâches avec scheduler.postTask()

Alors que scheduler.yield() décompose les tâches, scheduler.postTask() vous donne un contrôle précis sur la priorité des tâches. L'API accepte trois niveaux de priorité : "user-blocking" pour les tâches critiques nécessitant la priorité la plus élevée, "user-visible" pour les tâches de priorité moyenne, et "background" pour les tâches de priorité la plus faible qui doivent s'exécuter pendant le temps d'inactivité.

En utilisant postTask(), vous pouvez vous assurer que le travail non essentiel ne bloque pas les interactions des utilisateurs. Voici un exemple pratique qui planifie le travail d'analyse avec une priorité background tout en maintenant les mises à jour de l'UI à la priorité la plus élevée :

\/\/ Priorité élevée : le retour visuel de l'UI s'exécute en premier
scheduler.postTask(() => {
  showLoadingSpinner();
}, { priority: 'user-blocking' });

\/\/ Priorité moyenne : récupération des données
scheduler.postTask(async () => {
  const data = await fetchSearchResults(query);
  renderResults(data);
}, { priority: 'user-visible' });

\/\/ Basse priorité : les analyses peuvent attendre
scheduler.postTask(() => {
  trackSearchEvent(query);
  sendToAnalytics('search', { query });
}, { priority: 'background' });

Consultez le tableau de support des navigateurs pour scheduler.postTask() avant de l'utiliser en production. Pour les navigateurs qui ne supportent pas l'API, utilisez requestIdleCallback() pour les tâches d'arrière-plan et queueMicrotask() pour les tâches de priorité élevée.

Implications pratiques

Qu'est-ce que cela signifie pour votre site ? Voici des recommandations spécifiques pour WordPress et React/Next.js.

WordPress

WordPress, en raison de son architecture basée sur les extensions (plugins), est souvent livré avec un thème et un grand nombre de plugins. Les plugins et les thèmes reposent souvent sur le JavaScript pour leurs fonctionnalités. Comme ces plugins et thèmes sont maintenus par des développeurs tiers, vous n'avez aucun contrôle sur leur contenu. Cela signifie que vous ne pouvez pas modifier les fichiers et optimiser le « mauvais code ». Même si les scripts se comportent bien aujourd'hui, rien ne garantit qu'ils le feront après la prochaine mise à jour.

Pour minimiser l'input delay et optimiser l'Interaction to Next Paint (INP) sur WordPress, suivez ces étapes :

• É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 input delay qui impactera l'INP. Pour chaque plugin, demandez-vous : puis-je obtenir la même fonctionnalité avec du code personnalisé ou une solution côté serveur ?
• 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 consomment un temps CPU précieux.
• Évitez les constructeurs de pages (page builders). Les page builders comme Elementor ou WPBakery vous offrent une interface visuelle conviviale pour créer des mises en page. Malheureusement, ils reposent souvent sur des scripts lourds 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 un thème enfant et désinscrivez les scripts inutiles par type de page :

function my_deregister_scripts() {
  if ( ! is_page( 'contact' ) ) {
    \/\/ Désinscrire le script du formulaire de contact sur les pages autres que contact
    wp_dequeue_script( 'contact-form-script' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts' );

• Auditez votre Tag Manager. Les conteneurs Google Tag Manager accumulent souvent des balises au fil du temps. Chaque balise qui se déclenche pendant le chargement de la page ajoute une tâche au main thread. Supprimez les balises inutilisées, définissez des déclencheurs appropriés (par exemple, ne déclenchez les balises marketing que sur les pages de conversion) et utilisez les rapports de timing intégrés du Tag Manager pour identifier les balises lentes.
• Retardez les scripts tiers non essentiels. Les widgets de chat, les outils de feedback et les intégrations de réseaux sociaux n'ont pas besoin d'être chargés immédiatement. Utilisez requestIdleCallback() ou un déclencheur basé sur le défilement (scroll) pour ne les charger que lorsque l'utilisateur est susceptible d'en avoir besoin. Pour des stratégies détaillées, lisez notre guide sur les 14 méthodes pour différer le JavaScript.

React / Next.js

Les sites React et Next.js sont principalement alimentés par le JavaScript. L'exécution des scripts de démarrage, l'hydratation des composants et le traitement du DOM virtuel prennent tous du temps et peuvent causer un input delay pour l'Interaction to Next Paint (INP). La bonne nouvelle est que React et Next.js fournissent tous deux des outils pour gérer cela efficacement.

• Utilisez les composants serveur (React Server Components dans Next.js App Router). Les composants serveur sont rendus sur le serveur et n'envoient aucun JavaScript au client, ce qui réduit directement la quantité de code en compétition pour le temps du main thread.
• Chargez les scripts tiers avec la bonne stratégie. Dans Next.js, utilisez le composant next/script avec strategy="afterInteractive" pour les scripts nécessaires après l'hydratation, ou strategy="lazyOnload" pour les scripts qui peuvent être chargés pendant le temps d'inactivité du navigateur. Consultez notre guide async vs defer JavaScript pour les principes sous-jacents.
• Implémentez un modèle « idle-until-urgent ». Ce modèle donne la priorité aux interactions de l'utilisateur sur les tâches d'arrière-plan en utilisant requestIdleCallback() pour l'initialisation non critique tout en conservant un repli synchrone qui s'active lorsque le composant est réellement nécessaire.
• Chargez les composants en différé (lazy load). Chargez en différé les composants qui ne sont pas immédiatement nécessaires en utilisant React.lazy() ou le dynamic() de Next.js avec { ssr: false } pour les composants client uniquement.
• Utilisez Suspense pour les composants interactifs. Enveloppez les composants interactifs dans des limites <Suspense> afin que le reste de la page puisse être rendu et devenir interactif pendant que les composants lourds se chargent en arrière-plan. Cela empêche un seul composant lent de bloquer le traitement des entrées sur toute la page.
• Utilisez les transitions React pour les mises à jour non urgentes. Enveloppez les mises à jour d'état non critiques dans startTransition() afin que React puisse les interrompre si l'utilisateur effectue une nouvelle interaction. Cela maintient l'UI réactive même lorsque de grands re-rendus sont en cours.

Explorer les autres phases de l'INP

Pour maîtriser votre INP, traitez également les deux autres phases :

• Processing Time : optimisez le code du gestionnaire d'événements qui s'exécute pendant l'interaction. Sur la plupart des pages, c'est là que l'essentiel de vos efforts d'optimisation porte ses fruits.
• Presentation Delay : réduisez le travail de rendu et de peinture qui suit le traitement des événements. Sur les pages complexes avec de grands DOM, c'est souvent la phase la plus importante.

Pour un workflow de diagnostic complet, consultez notre guide sur la façon de trouver et corriger les problèmes d'INP, et revenez à la page d'accueil INP pour une vue d'ensemble complète.