INP : mesurer et améliorer la réactivité de votre site (Interaction to Next Paint)

TL;DRUn bouton qui semble ne pas réagir, un menu qui s'ouvre avec un temps de retard : c'est ce que mesure l'INP, l'indicateur de réactivité des Core Web Vitals. Voici comment il fonctionne, comment le mesurer et comment le corriger, avec ce que nous avons changé sur notre propre site.

📌 Qu'est-ce que l'INP ?#

L'INP, pour Interaction to Next Paint, mesure la réactivité d'une page : le temps qui s'écoule entre une action du visiteur (un clic, un toucher sur écran tactile, une touche du clavier) et le moment où le navigateur affiche à l'écran le résultat de cette action. Le défilement et le survol ne sont pas comptés.

Le navigateur observe toutes les interactions d'une visite et retient la plus lente, ou presque : sur les pages qui en comptent beaucoup, il écarte une valeur extrême toutes les cinquante interactions, pour qu'un incident isolé ne fausse pas le résultat. Un INP élevé signifie donc qu'au moins une action courante sur la page laisse le visiteur attendre, avec ce sentiment désagréable que le bouton « n'a pas marché ».

L'INP est l'un des trois Core Web Vitals, les indicateurs d'expérience que Google suit en priorité, avec le LCP (vitesse d'affichage du contenu principal) et le CLS (stabilité visuelle). Il a remplacé le FID (First Input Delay) le 12 mars 2024. Le FID ne mesurait que le délai avant le traitement de la toute première interaction ; l'INP couvre toute la visite et va jusqu'à l'affichage, ce qui reflète bien mieux ce que vit l'utilisateur.

📌 Quel est un bon INP ?#

Ces seuils sont ceux que publie Google sur web.dev. Ils s'appliquent au 75e centile des visites réelles : pour qu'une page soit jugée bonne, au moins trois visites sur quatre doivent rester sous 200 ms. Le calcul est fait séparément pour le mobile et l'ordinateur, et le mobile est presque toujours le plus difficile, car ses processeurs sont plus lents.

📌 Les trois phases d'une interaction#

La latence d'une interaction se décompose en trois phases successives. Savoir laquelle domine est la clé du diagnostic, car chacune se corrige différemment.

1. Le délai d'entrée (input delay) : le temps pendant lequel le navigateur ne peut même pas commencer à traiter le clic, parce que son fil d'exécution principal est occupé par autre chose, typiquement un script en train de s'exécuter.
2. Le temps de traitement (processing duration) : l'exécution des gestionnaires d'événements associés à l'action, c'est-à-dire votre code JavaScript et celui des bibliothèques qui réagissent au clic.
3. Le délai de présentation (presentation delay) : le temps qu'il faut ensuite au navigateur pour recalculer les styles, la mise en page, puis dessiner l'image suivante. Il s'allonge avec la taille du DOM et l'ampleur des changements à afficher.

Le point commun de ces trois phases est le fil d'exécution principal du navigateur (main thread). Il ne fait qu'une chose à la fois : JavaScript, calcul des styles, mise en page et dessin s'y succèdent. Toute tâche de plus de 50 ms, appelée long task, retarde d'autant ce qui attend derrière elle, y compris la réponse à un clic.

📊 Données terrain et données de laboratoire#

L'INP est d'abord une mesure terrain : il faut une vraie personne qui clique pour qu'il existe. Google le collecte auprès des utilisateurs de Chrome qui l'ont accepté, dans le rapport CrUX (Chrome User Experience Report), sur une période glissante de 28 jours. C'est cette valeur qui compte pour l'évaluation des Core Web Vitals.

Un test de laboratoire comme Lighthouse charge la page sans jamais cliquer : il ne peut donc pas calculer d'INP en mode navigation classique. Il affiche à la place le TBT (Total Blocking Time), la somme des parties de long tasks qui dépassent 50 ms pendant le chargement. Le TBT n'est pas l'INP, mais il en est un bon indicateur : un thread principal souvent bloqué au chargement le sera aussi quand le visiteur voudra cliquer.

Bon à savoir. Un bon TBT ne garantit pas un bon INP. Le TBT ne regarde que le chargement de la page ; l'INP couvre toute la visite. Un gestionnaire de clic lent sur un filtre de produits, un menu ou un formulaire n'apparaîtra jamais dans le TBT, mais pèsera directement sur l'INP. Testez toujours à la main les interactions importantes de vos pages.

📌 Comment mesurer l'INP#

📌 PageSpeed Insights#

En haut du rapport, la partie « Découvrez ce que vivent vos utilisateurs réels » affiche l'INP terrain de la page, ou de l'ensemble du site (« origine ») si la page seule n'a pas assez de trafic. La partie inférieure, issue de Lighthouse, n'en contient pas : c'est là qu'on trouve le TBT. Si aucune donnée terrain n'apparaît, le site n'a pas assez de visites Chrome pour figurer dans CrUX.

📈 Google Search Console#

Le rapport « Signaux Web essentiels » regroupe les adresses du site par groupes de pages similaires et signale celles dont l'INP est à améliorer ou mauvais, séparément pour mobile et ordinateur. C'est l'outil idéal pour repérer les gabarits en cause plutôt que de tester les pages une par une.

📌 Chrome DevTools#

Le panneau Performance des outils de développement (touche F12) affiche en direct l'INP local pendant que vous utilisez la page, avec la liste des interactions et leur durée. Pour simuler un mobile, activez le ralentissement du processeur (x4 ou x6), puis enregistrez une trace pendant le clic suspect : la trace montre les tâches exécutées et la répartition entre les trois phases.

📌 La bibliothèque web-vitals#

Pour savoir quelles interactions sont lentes chez vos vrais visiteurs, la bibliothèque JavaScript open source web-vitals, maintenue par l'équipe Chrome, mesure l'INP dans le navigateur. Sa version « attribution » indique en plus l'élément cliqué et la durée de chacune des trois phases :

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  const { interactionTarget, inputDelay, processingDuration, presentationDelay } = attribution;
  // Envoyez ces valeurs à votre outil de statistiques
  navigator.sendBeacon('/rum', JSON.stringify({
    inp: Math.round(value),
    note: rating,            // 'good', 'needs-improvement' ou 'poor'
    cible: interactionTarget, // sélecteur CSS de l'élément cliqué
    delaiEntree: Math.round(inputDelay),
    traitement: Math.round(processingDuration),
    presentation: Math.round(presentationDelay),
  }));
});

Dès quelques centaines de visites collectées, vous savez quel bouton ou quel composant pose problème, et quelle phase corriger en priorité.

📌 Causes fréquentes et corrections#

📌 Découper les tâches longues avec scheduler.yield()#

Un traitement de 300 ms d'un seul tenant bloque tout clic pendant 300 ms. Découpé en morceaux, il laisse le navigateur traiter les interactions entre deux morceaux. La fonction scheduler.yield(), disponible dans Chrome depuis la version 129, sert exactement à cela : elle rend la main au navigateur, puis reprend la suite en priorité. Les navigateurs qui ne la connaissent pas encore se rabattent sur un setTimeout :

function cederLaMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function traiterLaListe(elements) {
  for (const element of elements) {
    traiter(element);
    await cederLaMain(); // le navigateur peut répondre à un clic entre deux éléments
  }
}

Le même principe s'applique dans un gestionnaire de clic : mettez d'abord à jour ce que le visiteur doit voir (bouton enfoncé, indicateur de chargement), rendez la main, puis faites le reste. L'image suivante s'affiche tout de suite et l'INP ne compte que cette première partie.

📌 Différer le JavaScript non critique#

Le JavaScript le plus rapide est celui qui n'est pas exécuté. Un carrousel, une carte ou une bibliothèque d'animation n'ont pas besoin d'être chargés tant que le visiteur n'en approche pas. L'import dynamique, combiné à IntersectionObserver, les charge seulement au moment utile :

const bloc = document.querySelector('.carrousel');
const observateur = new IntersectionObserver(async (entrees) => {
  if (!entrees.some((e) => e.isIntersecting)) return;
  observateur.disconnect();
  const { initialiserCarrousel } = await import('./carrousel.js');
  initialiserCarrousel(bloc);
}, { rootMargin: '300px' });
observateur.observe(bloc);

📌 Éviter les reflows forcés#

Lire une dimension (offsetHeight, getBoundingClientRect()) juste après avoir modifié le style oblige le navigateur à recalculer la mise en page sur-le-champ, en plein milieu de votre script. Répété dans une boucle ou à chaque défilement, ce schéma multiplie les calculs. Regroupez d'abord toutes les lectures, puis toutes les écritures, et confiez la détection de visibilité à IntersectionObserver, qui la calcule sans bloquer.

📌 Alléger le DOM et surveiller les scripts tiers#

Plus une page contient d'éléments, plus chaque mise à jour coûte cher à afficher : c'est le délai de présentation qui s'allonge. Les scripts tiers, eux, s'exécutent sur le même thread principal que votre code et peuvent occuper le navigateur au moment précis du clic. Une revue régulière de ces deux points fait souvent gagner plus que l'optimisation fine de votre propre code.

📌 Notre expérience sur websource.fr#

Le 17 octobre 2026, nous avons retravaillé le JavaScript de nos pages Expertises. Jusque-là, chaque page chargeait systématiquement GSAP, son extension ScrollTrigger, Swiper et Lenis, soit environ 230 Ko de JavaScript non compressé, même quand la page ne contenait ni carrousel ni animation complexe. Chaque élément animé à l'apparition recevait en plus son propre ScrollTrigger, qui calcule des positions dans la page et provoquait des reflows forcés.

Nous avons fait deux changements :

• ces bibliothèques sont désormais chargées par des import() dynamiques, déclenchés uniquement quand l'élément qui en a besoin approche de l'écran ;
• l'animation d'apparition au défilement a été réécrite avec IntersectionObserver et la Web Animations API du navigateur, au lieu d'un ScrollTrigger par élément, ce qui supprime ces reflows forcés.

Sur ces pages, le TBT mesuré par Lighthouse en simulation mobile est passé d'environ 80 à 200 ms à souvent moins de 60 ms. Ce sont des mesures de laboratoire, qui varient d'une exécution à l'autre : elles indiquent que le thread principal est moins encombré, pas encore quel sera notre INP terrain, que nous suivrons dans les données CrUX au fil des semaines.

📌 Par où commencer ?#

1. Consultez l'INP terrain de vos pages principales dans PageSpeed Insights, puis le rapport Signaux Web essentiels de la Search Console pour repérer les groupes de pages concernés.
2. Reproduisez les interactions clés (menu, filtres, ajout au panier, formulaire) dans le panneau Performance de Chrome avec un processeur ralenti.
3. Identifiez la phase dominante, puis appliquez la correction correspondante du tableau ci-dessus.
4. Installez web-vitals avec attribution pour vérifier l'effet sur vos vrais visiteurs.

Si votre site est lent de manière plus générale, commencez par notre diagnostic en 5 étapes : il aide à distinguer un problème de JavaScript, qui touche l'INP, d'un problème de serveur, mesuré par le TTFB.

Websource accompagne ses clients dans l'optimisation des performances de leurs sites, de l'audit des scripts à la correction du code, et propose un hébergement web configuré pour la vitesse. Pour un diagnostic de votre site, contactez-nous.

❓ Questions fréquentes#

📌 Que veut dire INP ?#

Interaction to Next Paint, soit « de l'interaction à l'image suivante ». C'est le délai entre une action du visiteur et l'affichage de son résultat à l'écran.

📌 Quel est un bon INP ?#

200 ms ou moins au 75e centile des visites réelles. Entre 200 et 500 ms, il est à améliorer ; au-delà de 500 ms, il est considéré comme mauvais.

📌 Pourquoi PageSpeed Insights n'affiche-t-il pas d'INP pour ma page ?#

L'INP vient des données terrain CrUX. Si la page, ou le site entier, ne reçoit pas assez de visites de la part d'utilisateurs de Chrome, aucune donnée terrain n'est disponible. Le TBT de la partie Lighthouse reste alors le meilleur indicateur.

📌 Quelle différence entre l'INP et le FID ?#

Le FID ne mesurait que le délai avant le traitement de la première interaction. L'INP prend en compte toutes les interactions de la visite et inclut le traitement et l'affichage, d'où son remplacement en mars 2024.

Article publié le 20/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.