Réduire le délai d’entrée pour améliorer l’INP

Le délai d’entrée correspond au temps qui s’écoule entre le moment où l’utilisateur interagit avec la page (toucher, clic, frappe au clavier) et le moment où les rappels d’événement commencent réellement à s’exécuter. Chaque interaction démarre par un certain délai d’entrée. Une partie est inévitable, car le système d’exploitation doit transmettre l’événement au navigateur, mais cette part est souvent imperceptible. Ce sont les autres causes, liées à l’activité de la page, qui posent problème.

Réduire le délai d’entrée est un levier direct pour améliorer l’INP (Interaction to Next Paint), et donc l’expérience perçue de votre site. Pour resituer cette phase dans la métrique complète, voyez comment comprendre et mesurer l’INP. En SEO, une page qui répond vite aux actions inspire confiance et limite les frustrations qui font fuir les visiteurs. L’objectif n’est pas d’éliminer totalement le délai, mais d’éviter de surcharger le thread principal au moment précis où l’utilisateur cherche à interagir.

Pour respecter le seuil Bon de l’INP, chaque partie d’une interaction doit être aussi courte que possible, quel que soit l’appareil utilisé. Le délai d’entrée n’est qu’une de ces parties, mais il se contrôle. Tant que vous évitez un travail excessif sur le thread principal pendant que les utilisateurs interagissent, votre délai d’entrée devrait rester suffisamment faible pour ne pas poser de problème. Une fois ce délai maîtrisé, il reste à traiter les autres phases pour optimiser l’INP dans son ensemble.

Il faut donc accepter qu’un délai d’entrée nul soit impossible, tout en traquant les causes évitables. La plupart d’entre elles tiennent à des tâches qui occupent le thread principal au mauvais moment : minuteurs récurrents, tâches longues ou interactions qui se chevauchent.

Trois familles de causes reviennent le plus souvent. Les minuteurs récurrents peuvent déclencher du travail juste avant une interaction, les tâches longues bloquent le thread le temps de se terminer, et les interactions qui se chevauchent ajoutent du délai à l’action suivante. Le tableau ci-dessous résume ces causes et les leviers associés.

Deux fonctions de minuteur contribuent souvent au délai d’entrée. setTimeout planifie un rappel après un délai donné, tandis que setInterval l’exécute toutes les n millisecondes de façon perpétuelle, jusqu’à un éventuel clearInterval. Par sa nature récurrente, setInterval est nettement plus susceptible de gêner une interaction. setTimeout n’est pas problématique en soi : il peut même servir à éviter les tâches longues, mais tout dépend du moment où son rappel s’exécute et du travail qu’il effectue. Le détail des stratégies de fractionnement est traité dans notre guide pour optimiser les longues tâches.

Voici comment réduire le travail d’un rappel récurrent et le différer hors d’une interaction critique.

Le chevauchement d’interactions survient lorsqu’un utilisateur déclenche une nouvelle action avant que la précédente ait eu le temps d’afficher son frame suivant. C’est fréquent dans les champs de formulaire, où de nombreuses frappes s’enchaînent sur une courte période. Si le travail lié à un événement clavier est coûteux, comme une requête réseau pour de l’autocomplétion, plusieurs options existent.

Vous pouvez débouncer les entrées pour limiter le nombre d’exécutions du rappel, et utiliser AbortController pour annuler les requêtes fetch sortantes afin de ne pas surcharger le thread principal. Les animations coûteuses pilotées par JavaScript aggravent aussi le problème en multipliant les appels requestAnimationFrame : privilégiez les animations CSS, en veillant à ce qu’elles soient composées pour s’exécuter sur le GPU plutôt que sur le thread principal.