Comment Interaction to Next Paint note votre pire clic

Qu'est-ce que l'INP (Interaction to Next Paint) ?

Chrome mesure Interaction to Next Paint comme la durée de la pire interaction d'une page, chronométrée du moment où un visiteur clique, appuie ou presse une touche jusqu'au moment où le navigateur peint la frame qui affiche le résultat. La métrique couvre tout l'aller-retour : l'attente avant le démarrage d'un gestionnaire d'événement, le temps d'exécution du gestionnaire lui-même et le travail de rendu qui suit. Instrumentez-la avec la bibliothèque web-vitals ou n'importe quel collecteur terrain, puis lisez-la par route.

Chrome compte les clics de souris, les appuis sur écran tactile et les frappes au clavier physique ou à l'écran, et le défilement, le survol et le zoom ne produisent aucun échantillon INP, selon la définition de la métrique publiée par l'équipe Chrome sur web.dev (consultée en septembre 2026). L'INP est le seul des trois Core Web Vitals à noter la réactivité une fois la page chargée, et il ne remonte rien tant que de vraies personnes ne cliquent pas, donc le chiffre sur lequel Google agit vient du real user monitoring, la mesure sur de vrais utilisateurs, au p75.

Quelles sont les trois phases d'une interaction ?

Chaque interaction se divise en input delay (l'attente avant le gestionnaire), processing duration (l'exécution du gestionnaire) et presentation delay (le rendu jusqu'à la frame), et l'INP est la somme des trois. Chaque phase a un propriétaire différent dans le navigateur, donc un chiffre INP seul ne vous apprend rien tant que vous ne le décomposez pas.

Phase	Commence quand	Se termine quand	Ce qui consomme le temps
Input delay	Le visiteur clique, appuie ou presse une touche	Le premier callback d'événement démarre	Thread principal déjà occupé par l'évaluation de scripts, des timers, d'autres gestionnaires
Processing duration	Le premier callback d'événement démarre	Le dernier callback se termine	Votre propre code de gestionnaire, les mises à jour d'état du framework, le travail synchrone
Presentation delay	Le dernier callback se termine	Le navigateur peint la frame suivante	Recalcul de style, layout, paint, taille du DOM

La formule est une simple somme :

INP = input delay + processing duration + presentation delay

Prenons un exemple. Un visiteur appuie sur une puce de filtre dans une liste de produits et attend 620ms que la grille change :

620ms = 180ms input delay + 90ms processing duration + 350ms presentation delay

Le réflexe est d'optimiser le gestionnaire, et le gestionnaire est la plus petite part avec 90ms. Le presentation delay pèse 56 % de l'interaction, donc le correctif est dans le rendu : le filtre re-rend 3 000 nœuds de grille et force un recalcul de style complet. Réduisez le DOM que l'interaction touche et les 350ms s'effondrent. Réécrire le gestionnaire économise 90ms au mieux et ne passe pas sous 200ms tout seul.

Un clic, trois délais

Délai d'entrée180ms

Durée de traitement90ms

Délai de présentation350ms

Qu'est-ce qu'un bon score INP ?

Les seuils de Chrome placent le bon à 200ms ou moins et le mauvais au-dessus de 500ms, mesurés au 75e centile des pages vues et séparés entre mobile et ordinateur. L'équipe Chrome publie ces seuils sur web.dev, inchangés en septembre 2026.

INP au p75	Verdict
200ms ou moins	Bon
Au-dessus de 200ms jusqu'à 500ms	À améliorer
Au-dessus de 500ms	Mauvais

Deux cents millisecondes, c'est un budget serré une fois divisé en trois, et la phase qui fait sauter sa part en premier est celle à attaquer. Mesurez la répartition avant de toucher au code : une barre de recherche échoue sur le processing, une grille à défilement infini échoue sur la presentation.

Pourquoi l'INP a-t-il remplacé le FID, et pourquoi le FID flattait-il les sites ?

Google a fait de l'INP un Core Web Vital le 12 mars 2024, en remplacement de First Input Delay, et le support du FID a pris fin le 9 septembre 2024 (web.dev, équipe Chrome). Le FID mesurait une seule chose étroite : le délai d'entrée avant que le premier gestionnaire d'événement de la page puisse démarrer. Il n'a jamais chronométré le gestionnaire, et il n'a jamais chronométré le paint qui suivait.

	First Input Delay	Interaction to Next Paint
Quelle interaction	La première seulement	La pire de la page
Quelles phases	Input delay uniquement	Input delay, processing, presentation
Bon au p75	100ms ou moins	200ms ou moins
Statut	Retiré le 9 septembre 2024	Core Web Vital depuis le 12 mars 2024

Le FID flattait les sites pour deux raisons. La première interaction sur une page est bon marché pour la plupart des visiteurs : fermer une bannière de cookies, placer le curseur dans un champ de recherche, appuyer sur accepter dans une fenêtre de consentement. Les interactions coûteuses viennent plus tard, une fois que le visiteur s'est engagé dans la page, et le FID ne les a jamais regardées.

Le FID arrêtait aussi son chronomètre avant l'exécution de votre code, donc un gestionnaire de filtre qui bloquait le thread principal pendant 900ms obtenait un FID parfait tant que le navigateur pouvait entrer vite dans le gestionnaire. web.dev dit explicitement que compter le temps de traitement dans le FID aurait pu pousser les développeurs à emballer la logique du gestionnaire dans un callback asynchrone, la sortant de la tâche mesurée sans aider la personne qui attend. L'INP bouche les deux trous.

Quelle interaction l'INP remonte-t-il quand une page en compte des centaines ?

Chrome remonte la pire interaction de la page, avec une tolérance pour les valeurs aberrantes sur les pages très sollicitées. Pour les pages comptant 50 interactions ou moins, la plus élevée devient l'INP de la page. Au-dessus de 50, Chrome met de côté une interaction élevée pour chaque tranche de 50 enregistrées, donc une session avec 130 interactions écarte les deux plus élevées et remonte la suivante.

Deux agrégations s'empilent ici, et les confondre est une erreur de triage courante : la règle de la pire interaction choisit un chiffre par page vue, puis le 75e centile sur l'ensemble des pages vues choisit un chiffre par URL. Lisez cette distribution comme vous lisez Largest Contentful Paint, avec le p75 à côté du p90 et le nombre d'échantillons.

Qu'est-ce qui cause un INP lent, et qu'est-ce qui corrige chaque cause ?

Un INP lent a trois familles de causes, une par phase, et chacune demande un correctif différent.

L'input delay vient d'un thread principal déjà occupé quand le clic arrive : évaluation de scripts pendant le chargement, timers et gestionnaires de fetch qui se disputent le même thread. Réduisez la quantité de JavaScript qui s'exécute, et découpez toute long task, toute tâche longue, au-delà de 50ms pour que le navigateur ait un créneau où accepter l'entrée.

La processing duration vient de gestionnaires qui font trop de choses d'un coup. Rendez la main au thread principal avec scheduler.yield() ou setTimeout() pour que le navigateur puisse peindre une frame intermédiaire, et repoussez tout ce dont le visiteur n'a pas besoin immédiatement derrière requestAnimationFrame() plus un yield. Peignez le retour visuel d'abord, faites le travail ensuite.

Le presentation delay vient du rendu. Les gros DOM coûtent plus cher à rendre que les petits, donc aplatissez l'arbre et ajoutez les éléments pendant l'interaction au lieu de les livrer d'avance. Réduisez la portée du recalcul de style et utilisez content-visibility pour sauter le travail hors écran. Chassez d'abord le layout thrashing : écrire un style et le relire dans la même tâche force un layout synchrone, et regrouper toutes les lectures avant toutes les écritures le supprime. Le même travail de rendu déplace Cumulative Layout Shift, donc vérifiez les deux après le correctif.

Comment trouver l'interaction qui tire l'INP vers le bas ?

Regardez les sessions où un visiteur a cliqué et où rien ne s'est passé. Un INP de 640ms au p75 dit que la page est lente ; il ne dit pas quel contrôle, quelle route ni quel appareil.

Flowsery enregistre la session et signale automatiquement les rage clicks, les dead clicks et les erreurs JavaScript, ce à quoi ressemble une interaction bloquée côté visiteur : le même bouton pressé quatre fois parce qu'aucune frame n'a jamais été peinte. Les sessions qui correspondent se regroupent en un problème, les problèmes se classent par le nombre d'utilisateurs touchés, et chacun arrive dans Slack, Linear ou Jira avec le replay et les étapes de reproduction. La collecte tourne sur un seul script de moins de 10 KB, sans cookie et hébergé dans l'UE, sans échantillonnage des données, donc les interactions lentes ne sont pas celles qui sortent de l'échantillon.

Foire aux questions

L'INP mesure-t-il le défilement ?

Non. Chrome compte les clics de souris, les appuis tactiles et les frappes au clavier, et exclut le défilement, le survol et le zoom. Un défilement saccadé est une vraie plainte qui ne produit aucun échantillon INP, diagnostiquez-le plutôt par le frame timing et les long tasks.

Pourquoi mon INP est-il bon dans Lighthouse et mauvais sur le terrain ?

Lighthouse exécute une interaction scriptée sur un appareil configuré, et l'INP note la pire interaction que de vrais visiteurs ont faite sur leur propre matériel. Votre passage en labo clique le bouton que vous lui avez indiqué ; vos visiteurs cliquent le filtre coûteux sur un téléphone Android de quatre ans. Traitez le labo comme un contrôle de régression et le terrain comme le verdict.

Dois-je encore suivre First Input Delay ?

Non. Le FID a cessé d'être un Core Web Vital le 12 mars 2024, et le support a pris fin le 9 septembre 2024, il n'apparaît donc plus dans la Search Console et ne pèse rien dans l'évaluation. Basculez le panneau du tableau de bord sur l'INP et gardez la série FID seulement pour relire d'anciens incidents.

Un seul clic lent peut-il faire échouer toute la page ?

Pas à lui seul. La pire interaction devient l'INP de cette page vue, puis Google lit le 75e centile de ces valeurs sur toutes les pages vues de l'URL. Un clic de 3 secondes dans une session ne bouge rien ; le même contrôle lent rencontré par un quart de vos sessions fait échouer l'URL.

Comment l'INP est-il mesuré dans une single-page app ?

L'INP s'accumule sur toute la vie de la page, donc les interactions d'une route restent dans la même fenêtre de mesure que la suivante jusqu'à ce qu'une navigation dure la réinitialise. Un clic lent sur un écran de réglages peut être remonté sur l'URL où le visiteur a atterri. Le support des soft navigations par Chrome pour découper ces fenêtres est expérimental, segmentez donc par route dans vos propres données terrain.

Quel budget par phase maintient l'INP sous 200ms ?

Cinquante millisecondes d'input delay, 50ms de processing duration et 100ms de presentation delay est une répartition tenable. Mesurez la répartition réelle par route avant de choisir quoi corriger, parce qu'une barre de recherche lourde en gestionnaires et une grille produit lourde en rendu échouent au même seuil pour des raisons opposées.

Qu'est-ce qu'une long task, et pourquoi compte-t-elle pour l'INP ?

Une long task est tout bloc ininterrompu de travail sur le thread principal de plus de 50ms, le même seuil que visent les corrections du délai d'entrée. Pendant qu'une long task s'exécute, le navigateur ne peut démarrer aucun gestionnaire d'événement, donc ce temps s'ajoute directement au délai d'entrée. Découper la long task en morceaux plus petits donne au navigateur une ouverture pour accepter le clic et démarrer le gestionnaire plus tôt.

Comment stopper le layout thrashing qui allonge le délai de présentation ?

Le layout thrashing survient quand le code écrit un style puis le relit dans la même tâche, ce qui force un layout synchrone que le navigateur aurait autrement différé. Regrouper toutes les lectures avant toutes les écritures dans la même tâche fait disparaître ce layout forcé et le délai qu'il ajoutait. C'est le premier point à vérifier dans le délai de présentation, avant la taille du DOM et content-visibility.

Quel outil mesure vraiment l'INP sur son propre site ?

L'INP s'instrumente avec la librairie web-vitals ou un autre collecteur de terrain, lu par route. Comme l'INP ne remonte rien tant que de vrais visiteurs n'ont pas cliqué, touché ou tapé, ce chiffre doit venir du real user monitoring plutôt que d'une seule exécution Lighthouse. Le résultat se lit au 75e percentile, exactement comme Chrome le note.

Pourquoi Chrome écarte-t-il certaines interactions sur les pages à fort volume de clics ?

Au-delà de 50 interactions enregistrées, Chrome met de côté une valeur haute pour chaque tranche de 50, pour qu'une poignée de cas extrêmes ne décide pas du score de toute la page. Une page avec 130 interactions écarte les deux plus hautes et remonte la suivante comme son INP. Les pages avec 50 interactions ou moins sautent cette étape et utilisent directement la pire interaction.