L'INP (Interaction to Next Paint) mesure le délai entre une interaction utilisateur (clic, tap, frappe clavier) et le prochain rafraîchissement visuel, sur l'ensemble de la visite. C'est la métrique de réactivité des Core Web Vitals, qui a officiellement remplacé le FID le 12 mars 2024. Le seuil "Bon" de Google est inférieur à 200 millisecondes au 75e percentile des visites réelles. Un mauvais INP est presque toujours un problème de JavaScript qui bloque le thread principal.
Ce guide détaille comment fonctionne l'INP, comment identifier les interactions lentes en field et en lab, et les leviers concrets - fractionnement des tâches longues, allègement des handlers, maîtrise des scripts tiers - pour passer sous 200 ms.
Qu'est-ce que l'INP, concrètement ?
L'INP répond à la question : "la page répond-elle quand je clique ?". Selon la définition officielle sur web.dev, il observe la latence de toutes les interactions d'une visite (clics, taps, saisies clavier - le scroll est exclu) et retient une valeur proche de la pire, de sorte qu'un bon INP garantit que la quasi-totalité des interactions ont été fluides.
Chaque interaction se décompose en trois phases :
- Input delay : le temps d'attente avant que le gestionnaire d'événement puisse s'exécuter, typiquement parce qu'une autre tâche occupe le thread principal.
- Processing time : l'exécution des gestionnaires d'événements eux-mêmes.
- Presentation delay : le temps pour recalculer la mise en page et peindre le prochain frame.
C'est ce qui rend l'INP bien plus exigeant que le FID, qu'il a officiellement remplacé en mars 2024 : le FID ne mesurait que l'input delay de la première interaction. Beaucoup de sites "verts" sous FID sont passés au rouge avec l'INP.
Quel est un bon score INP en 2026 ?
Les seuils officiels, identiques sur mobile et desktop, à atteindre au 75e percentile des visites réelles :
| Statut | Seuil INP |
|---|---|
| Bon | < 200 ms |
| À améliorer | 200 - 500 ms |
| Mauvais | > 500 ms |
Le mobile est le vrai champ de bataille : un handler qui s'exécute en 40 ms sur votre machine de développement peut en prendre 300 sur un Android d'entrée de gamme. C'est exactement ce que capture le 75e percentile de la donnée field.
Comment mesurer et diagnostiquer l'INP ?
Particularité de l'INP : Lighthouse ne peut pas le mesurer directement, puisqu'un audit lab charge la page sans interagir. Son proxy lab est le Total Blocking Time (TBT), corrélé mais imparfait. Le diagnostic complet combine donc field et lab, comme le recommande le guide de dépannage INP de web.dev :
- En field : PageSpeed Insights et le rapport CrUX donnent l'INP réel au 75e percentile. La librairie web-vitals avec attribution identifie l'élément et le script responsables sur vos vrais visiteurs - c'est la donnée la plus précieuse.
- En lab : l'onglet Performance de Chrome DevTools, avec un ralentissement CPU 4x-6x, permet de reproduire les interactions lentes. Les tâches longues (plus de 50 ms) apparaissent marquées en rouge dans la timeline.
Ciblez en priorité les interactions les plus fréquentes de vos parcours critiques : ouverture de menu, ajout au panier, validation de formulaire, filtres de listing.
Comment optimiser l'INP ? Les leviers par phase
Le guide d'optimisation officiel organise les correctifs selon la phase dominante.
Réduire l'input delay : fractionner les tâches longues
Toute tâche de plus de 50 ms bloque le thread principal et retarde les interactions qui surviennent pendant son exécution. Les leviers, détaillés dans le guide des tâches longues de web.dev :
- Céder le thread régulièrement avec
scheduler.yield()(ousetTimeouten fallback), documenté sur MDN, pour découper les traitements lourds en tranches interruptibles. - Différer le JavaScript non critique au chargement : moins de JS exécuté au démarrage, c'est moins de tâches longues pendant les premières interactions.
- Auditer les scripts tiers : tag manager surchargé, widgets de chat, scripts publicitaires sont des générateurs notoires de tâches longues. Chargez-les après l'interactivité, supprimez ceux qui ne servent plus.
Réduire le processing time : alléger les gestionnaires d'événements
Dans un handler, ne faites de façon synchrone que ce qui est nécessaire au retour visuel immédiat ; reportez le reste (analytics, calculs secondaires, appels réseau) après le prochain frame via requestAnimationFrame puis setTimeout, ou scheduler.yield(). L'utilisateur doit voir la page réagir d'abord ; le travail de fond peut suivre.
Réduire le presentation delay : limiter le coût de rendu
Un DOM volumineux (plusieurs milliers de nœuds) renchérit chaque recalcul de style et de layout. Réduisez la taille du DOM, utilisez content-visibility pour exclure du rendu les zones hors écran, et évitez le layout thrashing (lectures et écritures de propriétés géométriques entrelacées dans une boucle) qui force des recalculs synchrones.
Quelles erreurs font échouer l'INP le plus souvent ?
Dans les audits, quatre patterns dominent : le tag manager qui exécute des dizaines de balises au moindre clic, le handler de clic qui déclenche un re-render complet de l'interface (fréquent sur les SPA), l'hydratation JavaScript massive qui bloque le thread pendant les premières secondes, et le listener global posé sur document qui s'exécute à chaque interaction. Commencez par mesurer, puis traitez le script exact que l'attribution field désigne.
Comment suivre l'INP dans le temps ?
L'INP est la métrique la plus sensible aux régressions : un simple script tiers ajouté par le marketing peut la faire basculer au rouge sans aucun déploiement de votre part. Pour un suivi continu, WebCoreFlow interroge CrUX et PageSpeed Insights de façon programmée et historise l'INP de vos pages réelles, ce qui permet de rattacher une dégradation à un changement précis.
Combien de temps pour voir un résultat ?
Comptez 28 jours sur la donnée field, la durée de la fenêtre glissante de CrUX. Entre-temps, validez la correction en lab : les interactions ciblées doivent repasser sous 200 ms avec un CPU ralenti, et le TBT doit chuter. Si la donnée lab est bonne mais que le field ne bouge pas après un cycle complet, l'attribution field vous dira quelle interaction résiste.
Sources et références
Analysez votre site en 30 secondes.
Obtenez votre score Core Web Vitals et un plan d'action concret pour grimper dans Google. Sans carte bancaire.
Questions fréquentes
- Qu'est-ce que l'INP (Interaction to Next Paint) ?
- L'INP mesure le délai entre une interaction utilisateur (clic, tap, frappe clavier) et le prochain rafraîchissement visuel de la page. Il prend en compte toutes les interactions de la visite et retient l'une des pires. C'est la métrique officielle de réactivité des Core Web Vitals de Google.
- Quel est un bon score INP ?
- Un bon INP est inférieur à 200 millisecondes, mesuré au 75e percentile des visites réelles (données CrUX). Entre 200 et 500 ms, le statut est \"À améliorer\" ; au-delà de 500 ms, il est \"Mauvais\".
- Quelle est la différence entre INP et FID ?
- Le FID (First Input Delay) ne mesurait que le délai d'entrée de la première interaction. L'INP, qui l'a remplacé comme Core Web Vital le 12 mars 2024, mesure la latence complète (input delay + traitement + rendu) de toutes les interactions de la visite. Il est beaucoup plus exigeant.
- Pourquoi mon INP est-il mauvais alors que mon score Lighthouse est bon ?
- Parce que l'INP nécessite des interactions réelles : Lighthouse charge la page sans interagir et ne peut donc pas le mesurer directement. Son proxy lab est le Total Blocking Time (TBT). Seule la donnée field (CrUX) reflète l'INP réel de vos visiteurs, et c'est elle que Google utilise.
- Quelles sont les causes principales d'un mauvais INP ?
- Presque toujours le JavaScript : tâches longues (plus de 50 ms) qui bloquent le thread principal, gestionnaires d'événements trop lourds, scripts tiers (tag manager, chat, publicité) et rendus DOM trop volumineux après interaction.
- Comment reproduire un problème d'INP en local ?
- Ouvrez l'onglet Performance de Chrome DevTools, activez un ralentissement CPU (4x-6x) pour simuler un mobile d'entrée de gamme, enregistrez, puis interagissez avec la page. Les interactions lentes et les tâches longues responsables apparaissent dans la timeline.