Interaction to Next Paint (INP)

Ce que mesure l’INP, et ce qu’il ne mesure pas

L’INP observe chaque interaction utilisateur d’une page : un click, un tap, une frappe clavier. Pour chacune, le navigateur chronomètre le temps écoulé entre le moment où l’événement est déclenché et le moment où le prochain rendu visuel est effectivement peint à l’écran. À la fin de la vie de la page, ce n’est ni la moyenne ni la première interaction qui est retenue, mais la plus lente, ou une valeur proche du pire quand la page compte beaucoup d’interactions. Ce choix change tout : une page peut répondre en 60 ms quarante-neuf fois et perdre son score sur la cinquantième.

La différence avec le First Input Delay, que l’INP a remplacé dans les trois signaux d’expérience de page, n’est pas cosmétique. Le FID ne mesurait que le délai avant que le premier gestionnaire d’événement puisse démarrer, et s’arrêtait là. Tout ce qui se passait ensuite, le travail JavaScript, le recalcul de style, le rendu, sortait du champ. Résultat : des sites affichaient un FID excellent alors que leur menu mettait une demi-seconde à s’ouvrir. L’INP ferme cette faille en allant jusqu’au paint, et en couvrant toutes les interactions plutôt qu’une seule.

Ce que l’INP ne mesure pas mérite d’être dit aussi clairement. Il ignore le scroll, considéré comme géré par le compositeur et non par le thread principal. Il ignore le survol. Il ignore le chargement initial, qui relève du temps d’affichage du plus grand élément, et les sauts de mise en page, qui relèvent du décalage cumulé. Une page peut donc être lente à charger et impeccable en INP, ou instantanée au chargement et pénible dès le premier click. Ce sont trois défauts distincts, avec trois causes distinctes.

Jeremy Wagner, qui a écrit la documentation de référence de la métrique, en donne l’exposé le plus propre disponible :

Sur une page purement éditoriale sans formulaire ni filtre, l’INP peut même ne jamais être calculé : sans interaction, pas de valeur. C’est le premier réflexe de diagnostic quand une URL n’affiche aucune donnée INP dans les rapports de terrain.

Mécanique, seuils et outils de mesure en 2026

Chaque interaction se décompose en trois segments, et savoir lequel domine détermine le correctif. Le premier est le délai d’entrée : le temps pendant lequel le thread principal est occupé ailleurs et ne peut pas encore exécuter votre gestionnaire. Le deuxième est le temps de traitement, l’exécution effective du code attaché à l’événement. Le troisième est le délai de présentation, entre la fin du traitement et le prochain frame peint, où se logent le recalcul de style, la mise en page et la peinture. Un site React qui recalcule un arbre entier sur chaque frappe empile du temps de traitement. Un site saturé de tags publicitaires empile du délai d’entrée. Les deux affichent le même chiffre final et demandent des interventions opposées.

Les seuils publiés par Google sont stables : bon en dessous de 200 ms, à améliorer entre 200 et 500 ms, mauvais au-delà de 500 ms, évalués au 75e centile des pages vues sur 28 jours. Une précision qui évite des heures perdues : les données CrUX sont agrégées par tranches de 25 ms, comme le rappelle l’analyse mondiale de DebugBear publiée en 2025. Traquer un gain de 10 ms dans CrUX n’a donc aucun sens, le rapporteur n’a pas cette résolution. La même analyse situe l’INP typique autour de 75 ms en Corée du Sud et de 100 ms aux États-Unis, en Allemagne et au Japon : le mix d’appareils et le pays pèsent lourd dans toute comparaison entre sites.

Le piège le plus coûteux reste la confusion entre laboratoire et terrain. Un outil synthétique simule une interaction sur une machine froide, souvent au pire moment du chargement, et produit un chiffre qui n’a pas de raison de coïncider avec l’expérience réelle. DebugBear a documenté un cas de démonstration où seulement 4 URLs sur 22 atteignaient un INP synthétique de 150 ms ou moins, alors que 15 sur 22 affichaient un bon INP CrUX sous 200 ms, avec Discord comme exemple extrême : plus de 3 secondes de Total Blocking Time pour 81 ms d’INP mesuré sur le terrain. Le TBT est un indicateur de risque, pas un proxy de l’INP.

Côté outillage, deux évolutions comptent pour qui maintient un dashboard. PageSpeed Insights et son API sont passés à Lighthouse 13.0 le 20 octobre 2025 d’après les notes de version publiées par Google le 27 octobre 2025, qui documentent aussi la suppression du champ déprécié ruleScore au profit de ruleImpact : un dashboard qui lit des identifiants d’audit anciens casse en silence. Et le 16 décembre 2025, web.dev annonçait que l’INP et le LCP atteignaient le statut Baseline Newly available après l’ajout des API nécessaires dans Safari 26.2. La mesure sort donc de Chrome, même si CrUX reste chromocentré et que seul un dispositif RUM couvre réellement les autres navigateurs.

En pratique, la chaîne de mesure sérieuse tient en trois étages : CrUX et Search Console pour l’état officiel vu par Google, la bibliothèque web-vitals avec attribution pour comprendre quelle interaction et quel élément posent problème, le panneau performances de Chrome DevTools et les Long Animation Frames pour remonter jusqu’au script fautif.

INP et SEO : l’arbitrage honnête

Prenons la question de front, parce que c’est celle qui décide d’un budget. Aucune annonce Google vérifiée sur les douze derniers mois n’a donné à l’INP un nouveau seuil, une pondération particulière ou un traitement algorithmique spécifique. Les mises à jour core de décembre 2025 (11 au 29 décembre), de mars 2026 (27 mars au 8 avril) et de mai 2026 (21 mai au 2 juin) ont été présentées par Google comme des mises à jour larges ordinaires, sans consigne liée aux Core Web Vitals. La volatilité observée sur la mise à jour de mars, avec les chiffres relayés par SE Ranking sur la rotation du top 3, décrit un mouvement de classement global : l’attribuer à l’INP serait une reconstruction a posteriori.

La position officielle de Google n’a pas bougé non plus : les Core Web Vitals sont utilisés par ses systèmes de classement, mais un bon score ne garantit aucune position. Ce qui départage deux pages également rapides reste la pertinence, la qualité, l’autorité et le graphe de liens. Un site qui passe de 480 ms à 180 ms d’INP gagne un taux de rebond et un taux de conversion, pas trois positions. Vendre l’inverse à un client relève du folklore.

La conséquence opérationnelle est un arbitrage de budget, pas une opposition de principe. Corriger un INP catastrophique sur un tunnel d’achat se justifie par le chiffre d’affaires. Passer de 190 à 150 ms sur un blog relève de l’occupation d’ingénieur. À enveloppe constante, l’argent qui achète 40 ms théoriques sur des pages déjà correctes produit plus de résultat en achetant quelques liens éditoriaux au tarif public. Quand on opère un parc de médias éditoriaux en propre comme nous le faisons, l’INP se traite d’ailleurs au niveau du gabarit, jamais page par page : une correction dans le composant de navigation se propage à l’ensemble du parc, et c’est le seul rapport effort/effet acceptable à cette échelle. Pour qui compare des supports, la réactivité d’un site fait partie de ce qu’on peut vérifier soi-même sur le catalogue de médias consultable sans inscription, au même titre que le trafic ou la thématique.

Le contexte général aide à calibrer l’effort. Le Web Almanac 2025, sur des données CrUX de juin et juillet 2025, relève 77 % de pages mobiles avec un bon INP contre 74 % en 2024, 21 % à améliorer et 3 % mauvaises, face à 97 % sur desktop. Chez les 1 000 sites les plus visités, la proportion de bon INP est passée de 53 % à 63 %. Surtout, 62 % des pages mobiles passaient le LCP, 77 % l’INP et 81 % le CLS, mais seulement 48 % les trois ensemble. L’INP n’est donc pas le goulot d’étranglement principal du web mobile, le LCP l’est davantage. C’est un argument pour prioriser, pas pour ignorer.

Corriger un INP dégradé

La règle qui résout la majorité des cas tient en une phrase : rendez la main au navigateur. Une tâche JavaScript qui monopolise le thread principal plus de 50 ms bloque toute interaction pendant sa durée. Découper le travail et céder explicitement entre les morceaux, avec scheduler.yield là où il est disponible ou une bascule sur setTimeout en repli, transforme une tâche de 300 ms en six tâches de 50 ms au milieu desquelles un click peut passer. Le total de travail ne change pas, la latence perçue s’effondre.

Le deuxième réflexe consiste à séparer ce qui doit être visible tout de suite de ce qui peut attendre. Dans le gestionnaire d’événement, ne faites que le strict nécessaire au retour visuel : changer une classe, afficher un état actif, ouvrir le panneau. Tout le reste, l’envoi analytics, la synchronisation d’état, le calcul de recommandations, part après le prochain rendu. Sur React, cela passe par startTransition et useDeferredValue pour marquer une mise à jour comme non urgente, et par la suppression des rendus en cascade sur chaque frappe. Sur Vue et Angular, la logique est la même : la question n’est pas le framework, c’est ce qu’on exécute de façon synchrone dans le handler.

Cette vidéo officielle de Chrome for Developers déroule les techniques concrètes, avec le profilage qui va avec :

Le troisième front est le délai de présentation. Un DOM énorme, des sélecteurs CSS coûteux, une animation qui touche la géométrie plutôt que transform et opacity : chacun rallonge le rendu après l’exécution du code. La propriété content-visibility sur les blocs hors écran et le confinement CSS réduisent le travail de mise en page à chaque frame. Enfin, l’hydratation d’un site rendu côté serveur crée une fenêtre pendant laquelle la page est visible mais sourde, et c’est là que se logent les pires interactions mesurées. Hydrater par îlots, ou différer l’hydratation des composants sous la ligne de flottaison, supprime cette fenêtre.

Les erreurs les plus fréquentes que nous voyons en audit sont toujours les mêmes : optimiser le temps d’exécution alors que le délai d’entrée domine, chasser des millisecondes sur la page d’accueil alors que l’INP se dégrade sur la page de recherche interne, et déclarer victoire sur un test synthétique sans attendre les 28 jours de fenêtre glissante nécessaires pour que le terrain confirme.

Diagnostiquer les cas tordus et surveiller en production

Les cas résistants ont presque toujours une cause tierce. Une bannière de consentement qui recalcule tout le DOM à l’acceptation, un tag manager qui injecte huit scripts à la première interaction, un slot publicitaire qui redimensionne un conteneur au moment précis où l’utilisateur clique : ces trois-là expliquent la majorité des INP au-dessus de 500 ms que nous rencontrons sur des sites média. Aucun n’apparaît dans le code de l’équipe front, tous s’exécutent sur le même thread principal. La mise à jour de DebugBear du 27 octobre 2025, qui a ajouté les données Long Animation Frames dans son débogueur INP ainsi que le scan d’URL CrUX et la mesure synthétique de l’INP, sert précisément à remonter du frame lent au script responsable, y compris quand ce script est chargé depuis un domaine tiers.

Un piège plus subtil concerne l’attribution d’URL. L’interaction est comptabilisée sur la page où elle se produit, ce qui, sur une application à navigation côté client, peut la rattacher à l’URL précédente. Un tunnel qui affiche un mauvais INP sur la page panier alors que le code fautif vit dans la fiche produit est un classique. Le même mécanisme fausse les diagnostics sur les sites où le routage est entièrement géré en JavaScript.

La surveillance continue est ce qui manque le plus souvent, et c’est l’angle que les guides sur le sujet traitent le moins bien. Un audit ponctuel donne une photo, l’INP est une série temporelle : il se dégrade au fil des déploiements, à mesure qu’un composant grossit ou qu’une régie ajoute un partenaire. Collecter web-vitals avec attribution vers votre propre point de collecte, segmenter par gabarit plutôt que par URL, et poser une alerte sur le 75e centile par gabarit donne un signal exploitable dès la mise en production, sans attendre que CrUX bouge un mois plus tard.

Cette démonstration du RUM appliqué à l’INP montre bien le passage du chiffre agrégé à l’interaction incriminée :

Sur le coût de cet outillage, les grilles publiées varient selon l’unité facturée. Un comparatif de novembre 2025 situait SpeedCurve à 15 dollars par mois pour 100 000 pages vues RUM et 15 dollars par mois pour 5 000 tests synthétiques, tandis qu’un comparatif publié en 2026 rapportait environ 15 dollars pour le synthétique et 83 dollars pour le RUM. Des annuaires tiers plaçaient l’entrée payante de DebugBear entre 49 et 125 dollars par mois. À ce niveau de prix, l’argument budgétaire contre la surveillance continue ne tient pas : ce qui coûte cher, c’est de découvrir six mois plus tard qu’un tag ajouté un mardi a doublé la latence du bouton d’achat.