Thread principal bloqué : input delay élevé avant même l'exécution du gestionnaire

Ce qui se passe

L'input delay est le temps entre le clic de l'utilisateur et le moment où votre gestionnaire d'événement démarre. Le gestionnaire lui-même peut être parfaitement rapide — mais si le thread principal est au milieu d'une tâche longue (hydratation, init d'analytics, un timer qui parse des données), l'événement attend dans la file jusqu'à la fin de cette tâche.

C'est la seule phase de l'INP que votre gestionnaire ne peut pas corriger, car le coupable est un autre code qui se trouvait être en cours d'exécution.

Comment le reconnaître

• L'input delay domine la décomposition de l'INP ; le processing time est court.
• Le problème est intermittent : le même bouton est rapide ou lent selon le moment du clic.
• C'est pire juste après le chargement de la page, quand le code d'init, l'hydratation et les scripts tiers se disputent le thread principal.

Comment corriger

• Repérez les tâches longues dans DevTools Performance (blocs signalés en rouge de plus de 50 ms) — le correctif les vise, pas le gestionnaire.
• Découpez le travail d'init en morceaux avec scheduler.yield(), ou différez les parties non critiques avec requestIdleCallback.
• Initialisez les fonctionnalités à la demande au premier usage plutôt qu'au chargement ; chargez les scripts tiers avec async/defer.

Problème

// at page load: one 800 ms task — every click during it waits
initAnalytics()
buildSearchIndex(allProducts)
prefetchRecommendations()

Correctif

initAnalytics()
await scheduler.yield()                  // events can run between steps
buildSearchIndex(allProducts)
requestIdleCallback(() => prefetchRecommendations())