Interaction to Next Paint (INP) répond à une question simple, mais souvent mal comprise : combien de temps un utilisateur attend-il avant de voir qu’une page a réagi à son action ? C’est une métrique de réactivité. Pas un score universel de vitesse. Pas un verdict global sur l’UX.
Cette nuance compte en production. Une page peut afficher son contenu principal assez vite, puis devenir pénible dès qu’on ouvre un menu, qu’on lance un filtre produit ou qu’on valide un formulaire. C’est exactement la zone que l’INP aide à objectiver, avec une lecture plus fidèle que les anciens raccourcis centrés sur le seul chargement.
Interaction to Next Paint (INP), définition simple
L’Interaction to Next Paint, ou INP, mesure le temps entre une interaction utilisateur et le moment où le navigateur peut afficher le prochain changement visuel lié à cette interaction. L’idée clé tient en une phrase : l’INP mesure la rapidité du premier retour visible après action.
En pratique, les interactions prises en compte sont les clics, les taps et les frappes clavier. Le scroll, le zoom ou le simple survol ne font pas partie de la métrique. Et s’il n’y a aucune interaction éligible sur la page, il n’y a pas de valeur INP à analyser.
Que mesure exactement l’INP ?
Le mot important dans INP, c’est next paint. La métrique ne cherche pas à savoir quand tout le travail métier est terminé. Elle cherche à savoir quand l’utilisateur voit enfin un signe visuel que la page a répondu. Pour un menu mobile, cela peut être l’ouverture du panneau. Pour un bouton d’ajout au panier, cela peut être le changement d’état du bouton ou l’apparition d’un compteur. Pour un formulaire, cela peut être l’affichage immédiat d’un état de chargement.
Une interaction regroupe parfois plusieurs événements techniques, mais l’utilisateur, lui, n’en voit qu’un geste logique. L’INP retient la latence de cette interaction et la décompose en trois parties. C’est ce découpage qui aide à comprendre d’où vient la friction.
Input delay
L’input delay correspond au temps d’attente avant que le navigateur commence vraiment à traiter l’interaction. En clair, l’utilisateur a déjà cliqué, mais le thread principal est occupé ailleurs. C’est souvent le symptôme de tâches longues, de JavaScript trop lourd, ou d’une page qui tente de faire trop de choses en même temps.
Processing time
Le processing time couvre l’exécution des handlers et de la logique déclenchée par l’interaction. Si un filtre produit déclenche beaucoup de calculs, si un composant React relance trop de rendu, ou si un script tiers accroche l’événement, cette partie gonfle vite. Le clic a bien été pris en compte, mais le traitement prend trop de temps.
Presentation delay
Le presentation delay mesure le temps restant avant l’affichage du prochain frame. Même après le traitement JavaScript, le navigateur doit encore calculer le rendu, la mise en page et la peinture. C’est une zone souvent sous-estimée. Un DOM complexe, des recalculs de layout ou des changements visuels coûteux peuvent dégrader cette étape sans que le problème vienne du réseau.
Voilà le point à garder en tête : l’INP ne mesure pas la fin complète d’une action métier. Si une page affiche immédiatement un spinner après un clic, puis attend 800 ms une réponse API, l’INP peut rester correct alors que l’attente métier reste perceptible. La métrique lit le premier feedback visuel, pas tout le cycle fonctionnel.
Quels sont les seuils d’un bon score INP ?
Google classe l’INP selon trois seuils de lecture :
- bon : 200 ms ou moins ;
- à améliorer : plus de 200 ms et jusqu’à 500 ms ;
- médiocre : plus de 500 ms.
La bonne lecture ne se fait pas sur une moyenne globale. Google regarde le 75e percentile des visites réelles, séparément sur mobile et sur desktop. L’objectif n’est donc pas d’avoir quelques sessions très rapides. Il faut que la majorité haute des visites reste réactive dans la vraie vie.
Sur les pages très interactives, un autre détail compte. L’INP ne retient pas naïvement chaque pire pic isolé. Pour éviter qu’un incident très ponctuel fausse toute la lecture, une interaction très lente est ignorée par tranche de 50 interactions. C’est une manière pragmatique de limiter le bruit sans nier les vrais problèmes.
Pourquoi l’INP remplace le FID
Le FID, First Input Delay, rendait service pour mesurer une première impression de réactivité au chargement. Mais sa portée était trop courte. Il ne regardait que la première interaction, et uniquement son délai de départ. Il ne voyait ni le traitement complet, ni le délai avant le rendu visuel, ni les interactions suivantes qui comptent souvent davantage sur une page applicative ou e-commerce.
L’INP corrige cette faiblesse. Il observe l’ensemble des interactions éligibles sur la durée de visite, puis retient la plus lente, hors outliers extrêmes. Depuis mars 2024, il a remplacé le FID dans les Core Web Vitals pour représenter la réactivité. C’est un changement important, car il pousse à analyser l’usage réel d’une interface, pas seulement son premier contact.
| Indicateur | Ce qu'il mesure | Ce qu'il couvre mal | Quand l'utiliser |
|---|---|---|---|
| INP | Le délai entre une interaction et le prochain rendu visible | La qualité UX globale, la fin d’une opération asynchrone, le scroll et le zoom | Pour juger la réactivité perçue sur l’ensemble de la visite |
| FID | Le délai avant le début du traitement de la première interaction | Les interactions suivantes, le temps de traitement et le rendu visuel | Pour lire un ancien historique, pas pour piloter la réactivité actuelle |
| TTFB | Le temps avant réception du premier octet côté navigateur | La réactivité après clic, la fluidité d’interface, le rendu après action | Pour analyser la réponse initiale serveur et le début de chargement |
Ce que l’INP ne mesure pas
C’est la partie la plus utile pour éviter les contresens. Un bon INP ne veut pas dire que le site est rapide sur tous les plans. Il veut dire que le retour visuel après interaction arrive assez vite. C’est plus précis, et plus limité.
- l’INP ne mesure pas la vitesse globale du site, ni le chargement initial complet ;
- il ne mesure pas le temps de réponse initial du serveur, sujet plus proche du TTFB ;
- il ne mesure pas la pertinence d’un parcours, la clarté du contenu ou l’accessibilité d’une interface ;
- il ne mesure pas la qualité UX globale, qui dépend aussi de la compréhension, des états d’erreur, de la cohérence fonctionnelle et du design d’interaction ;
- il ne mesure pas la fin réelle d’une opération réseau déclenchée après un premier feedback ;
- il ne mesure pas le scroll ni le zoom, qui relèvent d’autres contraintes de fluidité.
Point clé
Il faut aussi résister à un autre raccourci, courant en SEO comme en webperf. Bon INP ne veut pas dire site performant au sens large. Et bon INP ne veut pas dire site éco-conçu. Une métrique de réactivité ne remplace ni un cadre de performance complet, ni une démarche de développement éco-conçu, ni une vraie revue produit.
Pourquoi une page peut avoir un mauvais INP
Les causes sont rarement mystérieuses. Elles s’accumulent souvent côté front. Les plus fréquentes sont connues :
- JavaScript volumineux ou mal découpé, qui monopolise le thread principal ;
- tâches longues déclenchées au clic, au tap ou à la saisie ;
- scripts tiers qui ajoutent des écouteurs, du tracking ou des recalculs inutiles ;
- recalculs de layout et invalidations de rendu après modification du DOM ;
- arbres DOM trop lourds ou composants UI trop coûteux à réafficher ;
- enchaînement d’états visuels trop tardifs, par exemple un bouton qui ne change qu’après un long traitement.
Sur un site B2B, on retrouve souvent la même scène. L’équipe optimise le chargement d’une landing page, puis ajoute ensuite des tags, un chat, un script de personnalisation, un formulaire riche, parfois une recherche instantanée. Chaque ajout paraît raisonnable seul. Ensemble, ils détériorent la réactivité. Le problème n’est pas abstrait, il est structurel.
Comment utiliser l’INP dans un pilotage de performance web
L’INP devient vraiment utile quand on le relie aux décisions. Pour une équipe produit, il aide à repérer les gabarits et les interactions qui dégradent la perception de qualité. Pour une équipe marketing, il évite de lire un bon score de chargement comme une garantie de fluidité. Pour une direction technique, il rend visible le coût réel de certains scripts tiers, composants lourds ou arbitrages de stack.
- Mesurez l’INP sur les pages qui portent un enjeu métier réel, pas seulement sur la page d’accueil.
- Regardez quelles interactions pèsent le plus, menu, filtre, recherche, ajout au panier, validation de formulaire.
- Distinguez ce qui relève de l’input delay, du traitement JavaScript, ou du rendu visuel.
- Priorisez ensuite les corrections qui améliorent à la fois l’expérience, la conversion et la sobriété de l’interface.
Un autre point mérite d’être dit franchement. L’INP n’est pas un KPI à piloter seul. Une équipe qui poursuit uniquement le vert sur cette métrique peut masquer un traitement métier lent derrière un feedback visuel rapide, ou ignorer des problèmes de compréhension et d’accessibilité. Le bon usage consiste à s’en servir comme signal de réactivité, puis à l’articuler avec d’autres mesures et des revues de parcours.
INP, Core Web Vitals, budget de performance et TTFB, comment les articuler
L’INP est une pièce du système, pas le système entier. Il s’inscrit dans le cadre des Core Web Vitals, aux côtés du LCP pour le chargement perçu et du CLS pour la stabilité visuelle. Ensemble, ces métriques donnent une lecture de l’expérience perçue. Elles ne remplacent pas une lecture d’architecture ou de gouvernance.
Le budget de performance web intervient plus en amont. Il fixe des limites sur le poids, les scripts, les requêtes ou certains composants. En clair, le budget aide à éviter les dérives. L’INP, lui, constate le résultat sur la réactivité réelle.
Le Time to First Byte, ou TTFB, répond encore à une autre question : à quelle vitesse le serveur commence-t-il à répondre ? Confondre TTFB et INP est une erreur classique. Le premier parle de démarrage de réponse. Le second parle de réaction visible après action utilisateur. Pour piloter sérieusement la performance web, il faut lire ces signaux ensemble, puis les relier aux choix front, aux scripts tiers et aux priorités produit. Quand cette lecture reste floue sur des parcours critiques, un travail de conseil technique aide à relier la métrique aux vraies causes côté architecture front.