Un bon score INP est de 200 millisecondes ou moins, mesuré au 75e percentile des visites réelles. Entre 200 et 500 ms, la page « doit être améliorée », et au-delà de 500 ms elle est jugée mauvaise. Google applique ces seuils séparément au mobile et au desktop : une page peut donc réussir sur l’un et échouer sur l’autre.
L’Interaction to Next Paint (INP) mesure la rapidité avec laquelle une page réagit visuellement après un clic, un appui tactile ou une pression de touche. Elle est devenue une Core Web Vital le 12 mars 2024, en remplacement du First Input Delay (FID), qui ne mesurait que le délai avant le traitement de la première interaction. L’INP examine les interactions sur toute la visite et retient l’une des plus lentes.
En pratique, « bon » signifie trois choses : au moins 75 % des visites réelles obtiennent une réponse en 200 ms, vous mesurez avec des données terrain et non un simple test en laboratoire, et vous gardez une marge sous le seuil pour qu’un nouveau script ou une semaine de soldes chargée ne vous fasse pas basculer.
Ce guide explique comment le score est calculé, où trouver le vôtre, pourquoi certains outils n’affichent rien, et comment diagnostiquer et corriger un INP lent sans tâtonner.
Quels sont les seuils de l’INP ?
Google utilise trois tranches, et les valeurs limites comptent. Le tableau ci-dessous reprend la documentation INP de web.dev et le rapport Core Web Vitals de la Search Console.
| Évaluation | Valeur INP | Ce que cela signifie pour les utilisateurs |
|---|---|---|
| Bon | 200 ms ou moins | Les clics et appuis paraissent immédiats pour la plupart des visites |
| À améliorer | Plus de 200 ms, jusqu’à 500 ms | Décalage perceptible sur les menus, filtres, formulaires ou l’ajout au panier |
| Mauvais | Plus de 500 ms | Les utilisateurs cliquent à nouveau, pensent que la page est cassée ou partent |
Exactement 200 ms, est-ce bon ? Oui. web.dev définit « bon » comme « inférieur ou égal » à 200 ms : 200 passe, 201 non. La même logique s’applique à 500 ms : exactement 500 reste « à améliorer », et tout ce qui dépasse est mauvais.
À titre de comparaison, les deux autres Core Web Vitals de la Search Console utilisent des seuils LCP de 2,5 s et 4 s, et des seuils CLS de 0,1 et 0,25. L’INP est la seule qui mesure la réactivité en millisecondes plutôt que le chargement ou la stabilité visuelle.
Comment votre score INP est-il réellement calculé ?
L’INP est d’abord calculé par visite, puis synthétisé sur l’ensemble des visites au 75e percentile. Comprendre ces deux étapes dissipe l’essentiel de la confusion autour de ce chiffre.
Pendant une visite, le navigateur chronomètre chaque clic, appui et pression de touche. Chaque interaction comporte trois phases :
- Délai d’entrée : l’attente avant le démarrage de vos gestionnaires d’événements, généralement parce que le thread principal est occupé à autre chose.
- Durée de traitement : le temps 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.
L’INP de la visite correspond à la plus longue de ces interactions, avec une exception pour les pages très sollicitées : web.dev indique qu’une interaction la plus lente est ignorée toutes les 50 interactions, afin qu’un pic isolé sur une longue session ne définisse pas le score. Le survol, le défilement et le zoom ne comptent pas comme des interactions.
Les valeurs de toutes les visites sont ensuite regroupées, et le 75e percentile est retenu. C’est la « règle des 75 % » : votre page est bonne si au moins trois visites sur quatre ont un INP de 200 ms ou moins. Le quart restant peut être plus lent sans faire échouer la page, c’est pourquoi corriger votre interaction lente la plus courante compte plus que de traquer un cas rare.
Une visite durant laquelle l’utilisateur ne clique, n’appuie ni ne tape jamais ne produit aucune valeur INP. Les pages surtout lues, comme les longs articles, ont souvent moins de données INP que les pages que l’on manipule, comme les filtres de catégorie ou le tunnel de commande.
Un bon score INP est-il différent sur mobile et sur desktop ?
Le seuil est le même, 200 ms, mais les résultats sont très différents. Les téléphones ont des processeurs plus lents, le même code met donc plus de temps à s’exécuter, et Google présente le mobile et le desktop séparément dans PageSpeed Insights comme dans la Search Console.
Le chapitre performance du Web Almanac 2024 de l’HTTP Archive a constaté que 74 % des sites mobiles et 97 % des sites desktop avaient un bon INP. Autrement dit, l’INP est surtout un problème mobile. Si votre rapport desktop est vert et votre rapport mobile orange, c’est le schéma normal, pas une erreur de mesure.
Donnez la priorité à l’appareil qui apporte votre trafic et votre chiffre d’affaires. Pour la plupart des sites grand public, c’est le mobile, ce qui implique aussi de tester sur un téléphone Android de milieu de gamme ou avec la limitation du processeur dans Chrome DevTools, et non sur un ordinateur portable rapide. Notre guide du SEO mobile couvre le sujet mobile plus largement.
Où vérifier votre score INP ?
Utilisez les données terrain pour savoir si vous réussissez, et les outils de laboratoire pour comprendre pourquoi vous échouez. Chaque outil répond à une question différente.
| Outil | Type de données | Idéal pour |
|---|---|---|
| Search Console, rapport Core Web Vitals | Terrain (CrUX), URL regroupées | Voir quels groupes de pages échouent sur mobile ou desktop, et valider les correctifs |
| PageSpeed Insights | Terrain (CrUX, 28 derniers jours) plus test Lighthouse en laboratoire | Vérifier rapidement une URL ou toute l’origine |
| API CrUX, BigQuery ou CrUX Vis | Terrain (CrUX) | Tendances dans le temps et comparaisons avec les concurrents |
| Real user monitoring (RUM), par exemple la bibliothèque JavaScript web-vitals | Terrain, vos propres visiteurs | Trouver quel élément et quelle interaction ont causé un INP lent |
| Panneau Performance de Chrome DevTools | Laboratoire | Enregistrer une interaction et voir quelle tâche l’a bloquée |
| Lighthouse (mode navigation) | Laboratoire | Total Blocking Time comme indicateur approximatif ; il ne mesure pas l’INP lors d’un test de chargement de page |
La documentation de Google est claire sur la hiérarchie : les données terrain issues d’utilisateurs réels sont le meilleur moyen de mesurer l’INP. Le Total Blocking Time peut signaler des problèmes, mais web.dev le décrit comme un indicateur raisonnable, « pas un substitut à l’INP ». Un score Lighthouse parfait ne signifie pas que vous réussissez l’INP.
Pourquoi PageSpeed Insights n’affiche-t-il aucun score INP pour certaines pages ?
Généralement parce qu’il n’y a pas assez de données d’utilisateurs réels pour cette URL. PageSpeed Insights récupère les données terrain du Chrome UX Report (CrUX), qui n’inclut que les pages découvrables publiquement et suffisamment visitées. Google ne publie pas le seuil de trafic exact.
Quand une URL manque de données, PageSpeed Insights tente de se rabattre sur les données de l’origine, c’est-à-dire votre domaine entier. Si l’origine en manque aussi, la section terrain affiche « No Data » et seuls les résultats de laboratoire Lighthouse restent. Autres raisons fréquentes :
- La page est récente et n’a pas encore accumulé 28 jours de visites
- La page est derrière une connexion ou bloquée à l’indexation, donc CrUX ne l’inclut pas
- Les visiteurs interagissent rarement avec la page, d’où peu d’échantillons INP malgré un bon trafic
La solution pratique consiste à ajouter votre propre RUM. La fonction onINP de la bibliothèque web-vitals remonte l’INP de chaque visite, et sa version d’attribution indique quel élément était concerné et combien de temps a duré chacune des trois phases. Vous obtenez ainsi des données sur les pages à faible trafic et, surtout, le contexte nécessaire au débogage.
Comment trouver ce qui ralentit l’INP ?
Diagnostiquez d’abord la phase, puis la cause. Chaque phase oriente vers un type de correctif différent.
| Phase lente | Cause typique | Où regarder |
|---|---|---|
| Délai d’entrée | Thread principal occupé par d’autres scripts : gestionnaires de balises, widgets de chat, A/B testing, hydratation lourde pendant le chargement | Les tâches longues dans DevTools autour du moment du clic |
| Durée de traitement | Le gestionnaire d’événements en fait trop : filtrage d’une longue liste de produits, appels analytics, stockage synchrone, nouveau rendu de composants entiers | Le gestionnaire click ou keydown dans le panneau Performance |
| Délai de présentation | DOM volumineux, recalcul coûteux des styles et de la mise en page, rendu de gros blocs de HTML par script | Les entrées « Recalculate Style » et « Layout » après le gestionnaire |
Une méthode simple :
- Dans la Search Console, repérez les groupes d’URL signalés « Problème INP » sur mobile.
- Ouvrez une URL d’exemple et identifiez les interactions que les gens effectuent vraiment : le menu, un filtre, le sélecteur de taille, l’ajout au panier, un champ de formulaire.
- Dans Chrome DevTools, activez la limitation du processeur, lancez un enregistrement Performance, effectuez l’interaction et arrêtez.
- Cherchez les tâches longues, que web.dev définit comme des tâches de plus de 50 ms, et notez de quel script elles proviennent.
- Répétez l’interaction pendant que la page est encore en cours de chargement. C’est souvent là que le thread principal est le plus chargé, et c’est là que les vrais utilisateurs cliquent.
Comment améliorer un mauvais score INP ?
Faites moins de travail sur le thread principal au moment de l’interaction, et laissez au navigateur la possibilité d’afficher plus tôt. Les correctifs ci-dessous sont classés à peu près du plus simple au plus technique.
Auditez d’abord les scripts tiers
Sur de nombreux sites marketing, le coût INP le plus élevé ne vient pas de votre code. Widgets de chat, heatmaps, outils de consentement, widgets d’avis et multiples balises analytics se disputent tous le thread principal. Listez chaque script de votre gestionnaire de balises, supprimez ce que personne n’utilise et différez les balises non essentielles après le chargement de la page ou après la première interaction.
Affichez d’abord un retour visuel, puis faites le reste
Mettez à jour l’interface immédiatement (ouvrez le menu, affichez l’indicateur de chargement, marquez le bouton comme activé), puis exécutez le travail plus lent dans une tâche séparée. C’est ce qu’on appelle céder la main au thread principal. Une petite fonction utilitaire comme celle ci-dessous utilise scheduler.yield() lorsque le navigateur le prend en charge et se rabat sur setTimeout ailleurs :
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Selon web.dev, scheduler.yield() est pris en charge dans Chrome et Edge à partir de la version 129 et dans Firefox à partir de la version 142, mais pas dans Safari, d’où l’importance de la solution de repli.
Découpez les tâches longues
Toute tâche de plus de 50 ms bloque les saisies. Découpez les longues boucles, comme le traitement de centaines de produits, en blocs séparés par une pause. Demandez à votre développeur d’examiner l’hydratation dans les frameworks front-end, qui s’exécute souvent comme une seule grosse tâche pendant le chargement.
Gardez un DOM léger
Chaque élément supplémentaire ralentit le recalcul des styles et de la mise en page. Paginez ou virtualisez les longues listes, supprimez les menus en double cachés pour mobile et desktop, et utilisez la propriété CSS content-visibility pour ne pas rendre les sections hors écran.
Évitez le layout thrashing
Lire une valeur de mise en page, comme la hauteur d’un élément, juste après avoir modifié des styles oblige le navigateur à recalculer la mise en page immédiatement. Regroupez les lectures avant les écritures dans vos gestionnaires d’événements.
Revérifiez après chaque modification
Les données terrain mettent du temps à évoluer. CrUX dans PageSpeed Insights couvre les 28 derniers jours, et la validation de la Search Console s’appuie sur une période de surveillance de 28 jours. Utilisez votre propre RUM pour confirmer le correctif en quelques jours, puis laissez les rapports de Google rattraper leur retard.
L’INP influence-t-il le positionnement SEO ?
L’INP fait partie des Core Web Vitals, qui selon Google correspondent à ce que ses systèmes de classement principaux cherchent à récompenser, mais ce n’est pas un raccourci vers le haut des résultats. Google « recommande vivement » de bonnes Core Web Vitals pour réussir dans la recherche, tandis que la pertinence et la qualité du contenu restent déterminantes.
L’argument le plus fort pour corriger l’INP est commercial. Des filtres lents, des boutons d’ajout au panier qui traînent et des formulaires qui ne réagissent pas coûtent directement des conversions, surtout sur mobile. Considérez un bon score INP comme le socle d’un site utilisable, puis consacrez l’essentiel de votre effort SEO au contenu et à la structure. Notre guide du SEO e-commerce montre quelle place occupe la performance dans les priorités d’une boutique.
Quel objectif viser ?
Visez un INP au 75e percentile nettement sous les 200 ms sur mobile, pas juste en dessous. Une page à 190 ms passe aujourd’hui, mais peut échouer après une nouvelle balise marketing ou un pic de trafic venant d’appareils plus lents. Une marge de quelques dizaines de millisecondes laisse à votre équipe de la place pour ajouter des fonctionnalités.
Fixez des objectifs par gabarit plutôt que par URL : pages catégories, fiches produits, articles, formulaires et tunnel de commande. Corrigez d’abord le gabarit qui cumule le plus de trafic et le pire INP, et intégrez l’INP à la checklist de mise en production pour que les nouveaux scripts soient examinés avant leur mise en ligne.
Quelle est la place de Marketer Coffee ?
Marketer Coffee est une agence SEO IA et GEO ; nous traitons la performance comme une composante du SEO technique, aux côtés de l’architecture, des données structurées et du contenu. Résultats dans d’autres secteurs :
- Aldi.pl (commerce de détail). Les clics organiques sont passés de 367 127 à 852 724 par mois en 12 mois (+132 %) grâce aux contenus produits, au balisage Product, à une architecture allégée et à l’unification des données des magasins. Lire l’étude de cas Aldi.
- IDG-Online (services de vidéosurveillance et affiliation). De 500 à plus de 30 000 clics mensuels en 16 mois face à Ceneo, MediaExpert et MediaMarkt, grâce à des pages classements, des contenus questions-réponses et du balisage schema. Lire l’étude de cas IDG-Online.
À qui nous convenons : les sites pour lesquels vitesse, structure et contenu doivent suivre un plan unique, souvent des boutiques ou des sites internationaux. À qui nous ne convenons pas : les équipes qui ont seulement besoin d’un ingénieur performance front-end pour une réécriture ponctuelle de framework ; faites appel à un développeur spécialisé pour cela. Pour voir comment votre site se comporte dans la recherche IA comme dans Google, commencez par notre audit gratuit de visibilité IA.
Questions fréquentes sur les scores INP
Qu’est-ce qu’un bon score INP ?
200 millisecondes ou moins au 75e percentile des visites réelles, mesuré séparément pour le mobile et le desktop. Au-delà de 200 ms et jusqu’à 500 ms, il faut l’améliorer ; au-delà de 500 ms, il est mauvais.
Quand l’INP a-t-il remplacé le FID ?
L’INP est devenu une Core Web Vital le 12 mars 2024, en remplacement du First Input Delay. La Search Console a supprimé le FID à cette date.
Pourquoi mon INP est-il bon sur desktop mais mauvais sur mobile ?
Les téléphones ont des processeurs plus lents, les mêmes scripts mettent donc plus de temps à s’exécuter. Le Web Almanac 2024 a relevé un bon INP sur 97 % des sites desktop, mais seulement sur 74 % des sites mobiles.
Lighthouse peut-il mesurer l’INP ?
Un test Lighthouse standard de chargement de page n’inclut pas d’interactions utilisateur : il ne peut donc pas indiquer l’INP. Il affiche le Total Blocking Time, un indicateur approximatif. Utilisez les données terrain de CrUX ou votre propre RUM pour juger l’INP.
Combien de temps faut-il pour qu’un correctif INP apparaisse dans la Search Console ?
Les données terrain couvrent une période glissante de 28 jours et la validation de la Search Console surveille pendant 28 jours : comptez environ quatre semaines avant que les rapports reflètent pleinement un correctif. Votre propre RUM peut le confirmer plus tôt.
En bref ?
Un bon INP, c’est 200 ms ou moins pour au moins 75 % des visites réelles, sur chaque type d’appareil. Repérez les gabarits en échec dans la Search Console, enregistrez les interactions lentes dans DevTools, identifiez la phase lente et corrigez la cause : moins de scripts tiers, un retour visuel plus rapide, des tâches plus courtes et un DOM plus léger. Puis gardez-vous une marge.
Si vous souhaitez un second avis sur la place de la performance parmi vos priorités SEO, réservez une consultation gratuite.
Sources : web.dev, « Interaction to Next Paint (INP) » (seuils, 75e percentile, phases d’interaction, règle des valeurs aberrantes, TBT comme indicateur) ; article de blog web.dev de Jeremy Wagner et Rick Viscomi annonçant l’INP comme Core Web Vital le 12 mars 2024 ; web.dev, « Optimize Interaction to Next Paint » et « Optimize long tasks » (tâches longues de 50 ms, prise en charge de scheduler.yield) ; Aide Google Search Console, rapport Core Web Vitals (seuils, validation sur 28 jours) ; Google Search Central, « Understanding Core Web Vitals and Google search results » ; Chrome for Developers, méthodologie CrUX et CrUX dans PageSpeed Insights (éligibilité, période de 28 jours, repli sur l’origine) ; HTTP Archive, Web Almanac 2024, chapitre Performance ; Marketer Coffee, études de cas Aldi et IDG-Online (autres secteurs).
