
Qu'est-ce que l'INP (Interaction to Next Paint) ? Le Core Web Vital expliqué
- vuetelemetry
- Guides
- 7 min de lecture
L'INP a remplacé le FID en tant que Core Web Vital en mars 2024. Ce que mesure Interaction to Next Paint, les seuils good, needs-improvement et poor, pourquoi il est plus strict que le FID, et comment corriger un score INP lent.
L'INP, abréviation d'Interaction to Next Paint, est l'un des Core Web Vitals de Google, les métriques que Google utilise pour évaluer à quel point une page est agréable à utiliser. L'INP mesure la réactivité : lorsque vous cliquez, tapotez ou appuyez sur une touche, combien de temps la page met-elle à répondre visiblement ? Il est devenu un Core Web Vital officiel le 12 March 2024, en remplacement de l'ancien First Input Delay (FID).
Le nom décrit exactement ce qu'il mesure. À partir du moment où vous interagissez, l'INP chronomètre le temps nécessaire jusqu'à ce que la prochaine image soit peinte, c'est-à-dire jusqu'à ce que vous voyiez réellement quelque chose changer à l'écran. Un INP faible signifie que la page réagit presque instantanément ; un INP élevé signifie que vous appuyez sur un bouton et qu'il semble figé un instant avant que quoi que ce soit ne se produise.
Les seuils de Google, mesurés au 75th percentile des interactions réelles des utilisateurs, sont simples. Un INP de 200 milliseconds ou moins est Good. Entre 200 et 500 milliseconds, c'est Needs improvement. Au-dessus de 500 milliseconds, c'est Poor. La partie 75th percentile compte : votre page doit être réactive pour la plupart des interactions, pas seulement en moyenne.
Le FID, la métrique que l'INP a remplacée, mesurait uniquement le délai avant que le navigateur ne puisse commencer à traiter votre première interaction, le délai d'entrée, et seulement pour cette première interaction. Cela rendait facile de le réussir alors qu'une page semblait encore lente. L'INP est plus strict car il examine les interactions sur l'ensemble de la visite, et il mesure la durée complète : le délai d'entrée, le temps d'exécution de vos gestionnaires d'événements et le temps nécessaire pour présenter la prochaine image.
En d'autres termes, le FID demandait à quelle vitesse la page pouvait commencer à répondre, une seule fois. L'INP demande à quelle vitesse la page répond réellement, à chaque fois. Cela correspond bien mieux à la façon dont la réactivité est réellement ressentie par un utilisateur.
Presque tous les problèmes d'INP viennent du main thread qui est occupé. Le JavaScript s'exécute sur un seul main thread, et pendant qu'une tâche longue est en cours, le navigateur ne peut pas répondre à un clic ni peindre une nouvelle image. Les coupables habituels sont les tâches JavaScript longues, les gestionnaires d'événements lourds qui font trop de travail d'un coup, les mises à jour du DOM volumineuses ou complexes, et les frameworks qui effectuent plus de re-rendu que nécessaire.
Corriger l'INP consiste surtout à ne pas bloquer le main thread. Découpez les tâches longues en morceaux plus petits et rendez la main au navigateur entre elles pour qu'il puisse gérer les entrées. Déplacez le travail lourd et non urgent hors de l'interaction, par exemple avec requestIdleCallback ou un web worker. Gardez les gestionnaires d'événements légers, appliquez un debounce aux événements bruyants comme input et scroll, et évitez de forcer un travail de layout ou de re-rendu synchrone volumineux en réponse directe à un tapotement.
L'INP se juge le mieux sur des données de terrain, des utilisateurs réels sur des appareils réels, que vous pouvez consulter dans le Chrome User Experience Report et dans le rapport Core Web Vitals de Google Search Console. Pour le débogage en laboratoire, la bibliothèque JavaScript web-vitals, le panneau Performance des Chrome DevTools et Lighthouse vous aident tous à repérer les interactions lentes. Sur ce site, notre outil de vérification des web vitals vous permet de saisir vos valeurs mesurées et de voir instantanément si elles passent les seuils de Google.
Il vaut la peine de clarifier la portée. L'INP concerne uniquement la réactivité. C'est l'un des trois Core Web Vitals, aux côtés du Largest Contentful Paint (chargement) et du Cumulative Layout Shift (stabilité visuelle). Une page peut se charger rapidement et avoir tout de même un mauvais INP si son JavaScript bloque le main thread lorsque les gens commencent à interagir.
En résumé : l'INP récompense les pages qui restent réactives tout au long d'une visite, pas seulement au premier tapotement. Si votre site expédie beaucoup de JavaScript, l'INP est le Core Web Vital le plus susceptible de nécessiter votre attention, et la solution est presque toujours la même discipline : faire moins de travail sur le main thread, et le faire en morceaux plus petits.


