Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

Publié le 6 mai 2022, dernière mise à jour le 9 septembre 2025

Les données d'utilisation de Chrome montrent que 90 % du temps passé par un utilisateur sur une page se déroule après son chargement. Il est donc important de mesurer soigneusement la réactivité tout au long du cycle de vie de la page. C'est ce que mesure la métrique INP.

Une bonne réactivité signifie qu'une page répond rapidement aux interactions. Lorsqu'une page répond à une interaction, le navigateur présente un retour visuel dans le prochain frame qu'il peint. Les retours visuels vous indiquent, par exemple, si un article que vous ajoutez à un panier d'achat en ligne est bien ajouté, si un menu de navigation mobile s'est ouvert, si le contenu d'un formulaire de connexion est authentifié par le serveur, etc.

Certaines interactions prennent naturellement plus de temps que d'autres, mais pour les interactions particulièrement complexes, il est important de présenter rapidement un retour visuel initial pour indiquer à l'utilisateur qu'il se passe quelque chose. Le prochain frame que le navigateur affichera est la première occasion de le faire.

L'objectif de l'INP n'est donc pas de mesurer tous les effets éventuels d'une interaction (tels que les récupérations réseau et les mises à jour de l'UI à partir d'autres opérations asynchrones), mais le temps pendant lequel la prochaine peinture est bloquée. En retardant le retour visuel, les utilisateurs peuvent avoir l'impression que la page ne répond pas assez rapidement. L'INP a été développé pour aider les développeurs à mesurer cette partie de l'expérience utilisateur.

Dans la vidéo suivante, l'exemple de droite fournit un retour visuel immédiat indiquant qu'un accordéon s'ouvre. L'exemple de gauche montre une mauvaise réactivité et comment cela peut nuire à l'expérience utilisateur.

Ce guide explique comment fonctionne l'INP, comment le mesurer et fournit des ressources pour l'améliorer.

Qu'est-ce que l'INP ?

L'INP est une métrique qui évalue la réactivité globale d'une page aux interactions des utilisateurs en observant la latence de toutes les interactions (clic, appui et commandes au clavier) survenant au cours de la visite d'un utilisateur sur la page. La valeur INP finale correspond à l'interaction la plus longue observée, en ignorant les anomalies.

Une interaction est un groupe de gestionnaires d'événements qui se déclenchent lors du même geste logique de l'utilisateur. Par exemple, les interactions "appuyer" sur un appareil à écran tactile incluent plusieurs événements, tels que pointerup, pointerdown et click. Une interaction peut être déclenchée par JavaScript, CSS, des commandes de navigateur intégrées (telles que des éléments de formulaire) ou une combinaison de ces éléments.

La latence d'une interaction correspond à la durée la plus longue d'un groupe de gestionnaires d'événements qui pilotent l'interaction, depuis le moment où l'utilisateur commence l'interaction jusqu'au moment où le navigateur peut peindre un frame. Dans de rares cas, il peut n'y avoir aucune frame à peindre, mais l'interaction se termine lorsque le navigateur est en mesure de peindre une frame.

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

Il est difficile d'épingler des libellés tels que "bon" ou "mauvais" sur une métrique de réactivité. D'une part, vous souhaitez encourager les pratiques de développement qui privilégient une bonne réactivité. En revanche, vous devez tenir compte de la grande variabilité des capacités des appareils utilisés par les utilisateurs pour définir des attentes de développement réalisables.

Pour vous assurer d'offrir aux utilisateurs une expérience avec une bonne réactivité, un bon seuil à mesurer est le 75e centile des chargements de page enregistrés sur le terrain, segmentés sur les appareils mobiles et les ordinateurs :

• Un INP inférieur ou égal à 200 millisecondes signifie que la page a une bonne réactivité.
• Un INP supérieur à 200 millisecondes et inférieur ou égal à 500 millisecondes signifie que la réactivité d'une page doit être améliorée.
• Un INP supérieur à 500 millisecondes signifie que la page a une mauvaise réactivité.

Qu'est-ce qu'une interaction ?

L'interactivité est souvent principalement assurée par JavaScript, bien que les navigateurs fournissent une interactivité par le biais de commandes non alimentées par JavaScript, telles que les cases à cocher, les boutons radio et les commandes alimentées par CSS.

Comme l'objectif de l'INP est de mesurer la réactivité, seuls les types d'interaction suivants sont observés :

• Cliquer avec une souris
• Appuyer sur un appareil doté d'un écran tactile
• Appuyer sur une touche d'un clavier physique ou à l'écran

Les interactions ont lieu dans le document principal ou dans les iFrames intégrés au document (par exemple, en cliquant sur le bouton de lecture d'une vidéo intégrée). Les utilisateurs finaux ne savent pas ce qui se trouve dans un iFrame ou non. Par conséquent, l'INP dans les iFrames est nécessaire pour mesurer l'expérience utilisateur de la page de premier niveau. Étant donné que les API Web JavaScript n'ont pas accès au contenu des iFrames, cela peut apparaître comme une différence entre CrUX et RUM.

Les interactions peuvent comporter plusieurs événements. Par exemple, une frappe inclut les événements keydown, keypress et keyup. Les interactions tactiles contiennent des événements pointerup et pointerdown. L'événement ayant la durée la plus longue au sein de l'interaction contribue à la latence totale de l'interaction.

Comme le montre le diagramme, la durée de traitement de l'INP inclut tous les rappels du gestionnaire d'événements dans ce frame. Le délai d'entrée correspond au temps avant que tout rappel d'une interaction soit traité, la durée de traitement correspond au temps nécessaire à l'exécution de tous les rappels et le délai de présentation correspond au temps écoulé après l'exécution des rappels jusqu'à ce que le frame soit présenté sur l'écran de l'utilisateur.

L'INP de la page est calculé lorsque l'utilisateur quitte la page. Le résultat est une valeur unique qui représente la réactivité globale de la page tout au long de son cycle de vie. Un faible INP signifie qu'une page a répondu de manière fiable aux entrées utilisateur.

Quelle est la différence entre l'INP et le First Input Delay (FID) ?

L'INP succède à la métrique First Input Delay (FID). Bien que les deux soient des métriques de réactivité, le FID ne mesurait que le délai d'entrée de la première interaction sur une page. L'INP améliore le FID en observant toutes les interactions sur une page, en commençant par le délai d'entrée, en passant par le temps nécessaire à l'exécution des gestionnaires d'événements et en terminant par le moment où le navigateur a affiché le frame suivant.

Ces différences signifient que l'INP et le FID sont deux types de métriques de réactivité différents. Alors que le FID était une métrique de réactivité au chargement conçue pour évaluer la première impression de la page sur l'utilisateur, l'INP est un indicateur plus fiable de la réactivité globale, quelle que soit la durée de vie des interactions sur une page.

Que se passe-t-il si aucune valeur INP n'est signalée ?

Il est possible qu'une page ne renvoie aucune valeur INP. Plusieurs raisons peuvent expliquer cette situation. Par exemple :

• La page a été chargée, mais l'utilisateur n'a jamais cliqué dessus, ni appuyé sur l'écran ou sur une touche du clavier.
• La page s'est chargée, mais l'utilisateur a interagi avec elle à l'aide de gestes qui ne sont pas mesurés, comme le défilement ou le survol d'éléments.
• Un robot (par exemple, un robot d'exploration ou un navigateur sans interface graphique) accède à la page, mais n'a pas été programmé pour interagir avec elle.

Mesurer l'INP

L'INP peut être mesurée à la fois sur le terrain et en laboratoire, dans la mesure où vous pouvez simuler des interactions utilisateur réalistes.

Sur le terrain

Idéalement, votre parcours d'optimisation de l'INP commencera par les données de terrain. Dans le meilleur des cas, les données de champ issues de la surveillance des utilisateurs réels (RUM) vous fourniront non seulement la valeur INP d'une page, mais aussi des données contextuelles qui mettent en évidence l'interaction spécifique responsable de la valeur INP elle-même, si l'interaction s'est produite pendant ou après le chargement de la page, le type d'interaction (clic, pression sur une touche ou appui) et d'autres timings précieux qui peuvent vous aider à identifier la partie de l'interaction qui affectait la réactivité.

Si votre site Web est éligible à l'inclusion dans le rapport d'expérience utilisateur Chrome (CrUX), vous pouvez obtenir rapidement des données réelles pour l'INP via CrUX dans PageSpeed Insights (et d'autres métriques Core Web Vitals). Vous pouvez au minimum obtenir une image de l'INP de votre site Web au niveau de l'origine, mais dans certains cas, vous pouvez également obtenir des données au niveau de l'URL.

Toutefois, si CrUX peut vous indiquer s'il y a un problème, il ne peut pas vous dire quelle en est la cause. Une solution RUM peut vous aider à obtenir plus de détails sur les pages, les utilisateurs ou les interactions utilisateur qui rencontrent des problèmes de réactivité. La possibilité d'attribuer l'INP à des interactions individuelles permet d'éviter les devinettes et les efforts inutiles.

Au laboratoire

Idéalement, vous devez commencer à effectuer des tests en laboratoire une fois que vous disposez de données de terrain suggérant que les interactions sur une page sont lentes. Les données de terrain faciliteront grandement la reproduction des interactions problématiques en laboratoire.

Toutefois, il est tout à fait possible que vous ne disposiez pas de données de champ. Bien que l'INP puisse être mesuré dans certains outils de laboratoire, la valeur INP obtenue pour une page lors des tests en laboratoire dépendra des interactions effectuées pendant la période de mesure. Les comportements des utilisateurs peuvent être imprévisibles et très variables. Cela signifie que les tests en laboratoire ne permettent pas toujours de détecter les interactions problématiques de la même manière que les données de terrain. De plus, certains outils de test ne signalent pas l'INP d'une page, car ils n'observent que le chargement d'une page sans aucune interaction. Dans ce cas, le temps total de blocage (TTB) peut être une métrique proxy raisonnable pour l'INP, mais il ne peut pas remplacer l'INP en soi.

Même si les outils de laboratoire présentent des limites pour évaluer l'INP d'une page, il existe des stratégies pour reproduire les interactions lentes en laboratoire. Les stratégies incluent le suivi des parcours utilisateur courants et le test des interactions en cours de route, ainsi que l'interaction avec la page lors de son chargement (lorsque le thread principal est souvent le plus occupé) afin d'identifier les interactions lentes pendant cette partie cruciale de l'expérience utilisateur.

Mesurer l'INP en JavaScript

Pour mesurer l'INP en JavaScript, vous devez mesurer les temps d'événement pour toutes les interactions, puis prendre le 98e centile de toutes ces interactions lors du déchargement de la page. Vous pouvez consulter le code source de la bibliothèque JavaScript web vitals, qui contient une implémentation de référence sur la façon dont l'INP est calculé.

Dans la plupart des cas, la valeur INP actuelle au moment où la page est déchargée est la valeur INP finale pour cette page. Toutefois, il existe quelques exceptions importantes, comme indiqué dans la section suivante. La bibliothèque JavaScript web vitals en tient compte autant que possible, dans les limites des API Web.

Différences entre la métrique et l'API

• Les entrées event inférieures à 104 millisecondes ne sont pas signalées par défaut à l'aide d'observateurs de performances. Cette valeur par défaut peut être modifiée lorsqu'un observateur de performances est enregistré à l'aide du paramètre durationThreshold, mais même cette valeur a une valeur minimale de 16 millisecondes. Pour cette raison, il est recommandé d'observer également l'entrée first-input, qui est également une entrée Event Timing, mais qui est garantie d'être observable même lorsque sa durée est inférieure à durationThreshold. Cela permet de s'assurer que les pages avec interactions signalent toujours une valeur INP.
• Techniquement, le calcul parfait des centiles nécessite de conserver tous les échantillons en mémoire, ce qui peut être coûteux. Toutefois, vous pouvez approximer les centiles, en particulier les centiles très élevés comme p98, en conservant simplement une petite liste des N pires interactions. 10 est un choix courant.
• Si une page est restaurée à partir du cache amélioré, sa valeur INP doit être réinitialisée à zéro, car les utilisateurs considèrent qu'il s'agit d'une visite de page distincte.
• L'API ne signale pas les entrées event pour les interactions qui se produisent dans des iFrames, mais la métrique le fait, car elles font partie de l'expérience utilisateur de la page. Cela peut se traduire par une différence entre CrUX et RUM. Pour mesurer correctement l'INP, vous devez les prendre en compte. Les sous-frames peuvent utiliser l'API pour signaler leurs entrées event-timing au frame parent.

En plus de ces exceptions, l'INP est plus complexe, car il mesure toute la durée de vie d'une page :

• Les utilisateurs peuvent laisser un onglet ouvert pendant très longtemps (jours, semaines, mois). En effet, un utilisateur peut ne jamais fermer un onglet.
• Sur les systèmes d'exploitation mobiles, les navigateurs n'exécutent généralement pas les rappels de déchargement de page pour les onglets en arrière-plan, ce qui rend difficile la communication de la valeur "finale".

Pour gérer de tels cas, l'INP doit être signalé chaque fois qu'une page est en arrière-plan, en plus de chaque fois qu'elle est déchargée (l'événement visibilitychange couvre ces deux scénarios). Les systèmes d'analyse qui reçoivent ces données devront ensuite calculer la valeur INP finale sur le backend.

Plutôt que de mémoriser et de gérer tous ces cas vous-même, les développeurs peuvent utiliser la bibliothèque JavaScript web-vitals pour mesurer l'INP, qui tient compte de tout ce qui a été mentionné précédemment, à l'exception du cas de l'iframe :

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

Améliorer l'INP

Une collection de guides sur l'optimisation de l'INP est disponible pour vous aider à identifier les interactions lentes sur le terrain et à utiliser les données de laboratoire pour identifier les causes et les optimiser.

Journal des modifications

Il arrive que des bugs soient découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Par conséquent, des modifications doivent parfois être apportées. Elles peuvent apparaître comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.

Pour vous aider à gérer cela, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront indiquées dans ce journal des modifications.

Si vous avez des commentaires sur ces métriques, veuillez les envoyer dans le groupe Google web-vitals-feedback.

Tester vos connaissances