Interaction to Next Paint (INP) : définition, seuils et améliorations

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

L'Interaction to Next Paint (INP) est un Core Web Vital qui mesure la rapidité avec laquelle une page réagit aux actions de l'utilisateur. Il observe chaque clic, toucher et frappe au clavier pendant une visite, chronomètre chacun depuis l'action jusqu'à l'affichage de l'image suivante et retient le plus lent. Une page est jugée bonne lorsque l'INP est de 200 millisecondes ou moins au 75e centile des chargements réels.

Le 12 mars 2024, l'INP a remplacé le First Input Delay (FID) comme Core Web Vital. Le FID ne mesurait que le délai avant la prise en charge de la première interaction. L'INP couvre toutes les interactions et le temps complet jusqu'au prochain affichage : il décrit ce que l'on ressent en utilisant la page, pas seulement au chargement.

Seuils de l'INP

Les seuils s'appliquent aux données de terrain, séparées entre mobile et ordinateur. Une page est validée lorsqu'au moins 75 % des chargements respectent la limite.

Comment fonctionne l'INP

Chaque interaction se décompose en trois phases, et un retard dans l'une d'elles augmente l'INP :

• Délai d'entrée : le temps avant que les gestionnaires d'événements puissent démarrer, souvent parce que le fil principal est occupé.
• Temps de traitement : la durée d'exécution de vos gestionnaires d'événements.
• Délai de présentation : le temps entre la fin des gestionnaires et l'affichage de l'image suivante par le navigateur.

Seuls les clics, touchers et frappes comptent. Le survol, le zoom et le défilement ne sont pas des interactions pour l'INP. L'interaction la plus lente est retenue, sauf que sur les pages très interactives une valeur aberrante est ignorée par tranche de 50 interactions. La plupart des pages n'atteignent pas 50, donc en pratique l'INP est la pire interaction de la visite. Le 75e centile de toutes les pages vues est ensuite rapporté, comme pour les autres Core Web Vitals.

Exemple

Une page boutique se charge vite, mais le bouton « Ajouter au panier » exécute un gros script synchrone qui recalcule les prix, met à jour le panier et réaffiche toute la liste de produits. L'utilisateur touche le bouton et rien ne change visiblement pendant 600 ms. LCP et CLS sont corrects, mais l'INP de cette page avoisine 600 ms et est jugé médiocre. En répartissant le travail pour que le bouton affiche d'abord son nouvel état et que le reste s'exécute ensuite, l'interaction repasse sous 200 ms.

Comment mesurer l'INP

L'INP exige de vraies interactions : c'est d'abord une métrique de terrain. Le Chrome UX Report (CrUX) la publie pour les sites ayant assez de trafic Chrome, et la surveillance des utilisateurs réels (RUM) avec la bibliothèque open source web-vitals de Google montre quelle interaction et quel élément sont lents :

import { onINP } from 'web-vitals';
onINP((metric) => navigator.sendBeacon('/rum', JSON.stringify(metric)));

Pour voir rapidement comment une URL se comporte auprès de vrais utilisateurs, utilisez le vérificateur gratuit de Core Web Vitals, qui lit les données CrUX et indique LCP, INP et CLS. En test de laboratoire, aucun clic n'a généralement lieu : on utilise donc souvent le Total Blocking Time (TBT) comme substitut. web.dev le décrit comme un indicateur de laboratoire raisonnable, mais pas comme un remplacement de la mesure de l'INP sur le terrain.

Comment améliorer l'INP

• Découpez les tâches longues. Toute tâche de plus de 50 ms sur le fil principal peut retarder la saisie. Cédez la main entre deux blocs de travail pour que le navigateur puisse afficher.
• Faites moins dans le gestionnaire. Mettez d'abord à jour ce que l'utilisateur doit voir, puis différez l'analytique, les journaux et l'état non urgent.
• Réduisez le coût des scripts tiers. Gestionnaires de balises, widgets de chat et publicités s'exécutent sur le même fil principal que votre code.
• Sortez les calculs lourds du fil principal avec un web worker.
• Surveillez l'hydratation. Un clic qui arrive pendant que le framework s'hydrate doit attendre.
• Gardez un DOM léger. Les gros réaffichages après un clic allongent le délai de présentation.

Erreurs courantes

• Ne regarder que le score Lighthouse. Un test de laboratoire au vert en dit peu sur les interactions qui n'ont pas eu lieu pendant le test.
• Tester uniquement sur un ordinateur rapide. Les mobiles milieu de gamme sont généralement bien plus lents qu'un portable de développeur avec le même JavaScript.
• N'optimiser que le chargement. L'INP se joue surtout après le chargement, selon ce qui se passe au clic.
• Attendre un effet immédiat. Le CrUX est un jeu de données de terrain glissant sur 28 jours : les progrès apparaissent progressivement.

INP et suivi des performances

L'INP se mesure sur de vrais utilisateurs : un test ponctuel ne suffit pas. Suivez-le dans le temps à côté du LCP et du CLS et repérez les régressions après une mise en production. Le suivi de la vitesse de page de LoadFocus lance des audits Lighthouse planifiés, TBT compris, depuis des régions cloud, ce qui aide à repérer les régressions du fil principal qui précèdent souvent un INP dégradé. Pour un guide d'optimisation pas à pas, lisez How to Optimize Interaction to Next Paint et, pour configurer des alertes, How to monitor Core Web Vitals with alerts and reports (en anglais). La définition de référence se trouve sur web.dev.

Questions fréquentes sur l'Interaction to Next Paint

Quel est un bon INP ?

200 millisecondes ou moins au 75e centile des chargements de page. Entre 200 et 500 ms, il est à améliorer, et au-delà de 500 ms il est médiocre.

L'INP a-t-il remplacé le FID ?

Oui. L'INP est devenu un Core Web Vital à la place du First Input Delay le 12 mars 2024. Le FID ne mesurait que le délai d'entrée de la première interaction.

Pourquoi mon score Lighthouse est bon alors que mon INP de terrain est mauvais ?

Les tests de laboratoire incluent rarement de vrais clics ou frappes et passent donc à côté des interactions lentes. Le Total Blocking Time est un indicateur de laboratoire, mais seules les données de terrain d'utilisateurs réels donnent votre INP réel.

Quelles interactions comptent pour l'INP ?

Les clics, touchers et frappes au clavier. Le survol et le défilement ne comptent pas, même si un geste de défilement peut contenir un toucher ou une frappe qui, lui, compte.

Comment trouver l'interaction lente ?

Collectez l'INP avec la bibliothèque web-vitals dans votre propre RUM, qui peut indiquer l'élément et la phase lente, ou enregistrez une trace dans les outils de développement de Chrome et examinez l'interaction dans le panneau Performances.

L'hydratation influence-t-elle l'INP ?

Oui. L'hydratation est du JavaScript exécuté sur le fil principal : une interaction survenant pendant celle-ci est retardée. Des bundles plus petits, l'hydratation partielle et les composants serveur réduisent l'effet.