Optimiser l'INP : le guide pour éliminer la latence d'interaction (Long Tasks, JS)

Depuis mars 2024, l’INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) dans les Core Web Vitals de Google. Beaucoup de sites qui affichaient un excellent score FID découvrent, une fois passés à l’INP, que leur page devient franchement pénible à utiliser dès que le visiteur clique sur un menu, ouvre un filtre ou remplit un formulaire. Ce guide explique pourquoi, et surtout comment diagnostiquer précisément la cause dans votre propre code.

Ce que l’INP mesure réellement

Contrairement au FID, qui ne regardait que le délai avant que le navigateur commence à traiter un événement, l’INP couvre l’intégralité du cycle d’une interaction, en trois phases distinctes :

1. Input Delay — le temps entre l’action physique du visiteur (clic, tap, touche) et le moment où le navigateur commence réellement à exécuter le gestionnaire d’événement correspondant. Ce délai grimpe quand le thread principal est déjà occupé par autre chose.
2. Processing Time — le temps que met votre code JavaScript à s’exécuter en réponse à cette interaction (mise à jour d’état, appels API, manipulation du DOM).
3. Presentation Delay — le temps entre la fin du traitement et le moment où le navigateur peint effectivement le résultat visuel à l’écran.

Google retient la pire interaction (ou proche de la pire, statistiquement) observée sur l’ensemble de la session du visiteur - pas seulement la première. C’est ce qui rend l’INP beaucoup plus représentatif de l’expérience réelle qu’un simple chiffre de démarrage.

Bande	Seuil INP
Good	Moins de 200 ms
Needs Improvement	Entre 200 ms et 500 ms
Poor	Plus de 500 ms

La cause n°1 : les Long Tasks

Une “Long Task” est une tâche JavaScript qui occupe le thread principal du navigateur pendant plus de 50 millisecondes sans interruption. Pendant qu’une Long Task s’exécute, le navigateur ne peut traiter aucune interaction utilisateur - le clic est bien enregistré par le système d’exploitation, mais votre page ne peut littéralement pas y répondre tant que la tâche en cours ne rend pas la main.

Les causes les plus fréquentes de Long Tasks :

• Bundles JavaScript volumineux exécutés d’un seul bloc au chargement, souvent des frameworks front-end entiers hydratés en une seule passe.
• Scripts tiers non contrôlés — widgets de chat, pixels de tracking, pop-ups d’exit-intent - qui s’exécutent quand ils veulent, sur le thread principal, sans que vous en ayez la main.
• Recalculs de style et reflows en cascade, typiquement causés par des manipulations DOM en boucle qui forcent le navigateur à recalculer la mise en page à chaque itération.
• Traitement de données côté client — tri, filtrage ou transformation de grosses listes en JavaScript pur plutôt que déléguées au serveur ou découpées en morceaux.

Comment diagnostiquer les Long Tasks dans votre propre code

Le diagnostic se fait en deux temps : d’abord identifier qu’un problème d’interactivité existe, ensuite localiser précisément la ligne de code responsable.

Étape 1 — Confirmer le problème avec des données réelles. Un audit Core Web Vitals basé sur des données de terrain (field data, via le Chrome UX Report) montre l’INP réel mesuré chez de vrais visiteurs, pas une estimation en laboratoire. Notre outil d’audit gratuit affiche cette donnée directement, avec le seuil Google exact, plutôt qu’un score opaque.

Étape 2 — Localiser la Long Task avec les DevTools. Ouvrez l’onglet Performance de Chrome DevTools, enregistrez une session pendant laquelle vous cliquez sur les éléments interactifs de la page (menu, filtre, bouton d’ajout au panier), puis repérez les blocs marqués en rouge dans la timeline - ce sont vos Long Tasks. Chrome affiche directement la pile d’appels JavaScript responsable, ce qui vous amène droit au fichier et à la ligne fautive, sans deviner.

Étape 3 — Découper le travail. Une fois la fonction fautive identifiée, la correction la plus fiable consiste à découper le traitement en morceaux plus petits à l’aide de scheduler.yield() (ou, en fallback, setTimeout(fn, 0)) pour rendre régulièrement la main au thread principal entre chaque morceau, au lieu d’exécuter tout le calcul d’un seul bloc ininterrompu.

Réduire l’Input Delay : reprendre le contrôle du thread principal

Même un code de traitement rapide ne sert à rien si l’Input Delay est déjà élevé parce que le thread principal était occupé ailleurs au moment du clic. Les leviers concrets :

• Découper les bundles JavaScript avec du code-splitting par route, pour ne charger et exécuter que le code réellement nécessaire à la page affichée.
• Différer l’exécution des scripts tiers non critiques avec defer ou un chargement paresseux déclenché après l’interaction initiale, plutôt qu’au chargement de la page.
• Limiter le travail au chargement initial aux éléments réellement visibles et interactifs immédiatement - le reste peut s’hydrater après.
• Éviter les gestionnaires d’événements trop lourds attachés directement aux éléments à fort trafic d’interaction (listes longues, tableaux), en préférant la délégation d’événements.

Réduire le Processing Time : optimiser le code qui répond au clic

Une fois le contrôle du thread principal repris, la deuxième cible est le code qui s’exécute réellement en réponse à l’interaction :

• Débouncer ou throttler les gestionnaires déclenchés à haute fréquence (saisie dans un champ de recherche, scroll, redimensionnement) pour éviter de ré-exécuter un traitement lourd à chaque frappe.
• Mémoïser les calculs coûteux qui ne changent pas d’un rendu à l’autre, plutôt que de les recalculer à chaque interaction.
• Réduire les manipulations DOM redondantes — regrouper les lectures et les écritures du DOM séparément évite de déclencher plusieurs cycles de reflow inutiles pour une seule interaction.

Diagnostiquer votre propre INP

L’INP est une métrique de terrain par nature - elle ne peut être mesurée qu’à partir d’interactions réelles de visiteurs, contrairement au LCP ou au CLS qui peuvent être simulés en laboratoire de façon fiable. C’est précisément pourquoi beaucoup d’outils d’audit l’ignorent ou l’approximent mal.

Lancez un audit Core Web Vitals gratuit de votre site →

Notre outil affiche les métriques Core Web Vitals disponibles directement, avec les seuils Google exacts, pour vous donner un point de départ concret plutôt qu’un score anxiogène.

Besoin d’un diagnostic approfondi ?

Identifier la ligne de code exacte responsable d’une Long Task récurrente sur un site en production demande souvent un profilage ciblé, page par page. C’est le type d’intervention que nous menons dans le cadre de nos services de SEO technique, avec des mesures avant/après réelles plutôt qu’une simple recommandation générique.

Demandez un audit technique gratuit →

---

Publié par l’équipe Ingénierie Runkexpert. Dernière mise à jour le 15 juillet 2026.