Depuis le 12 mars 2024, INP a remplacé FID comme métrique de réactivité dans les Core Web Vitals. Et FID n’est plus un objectif à chasser.
Ce qui suit sert à une chose, faire baisser INP sans casser ton site, avec un chemin clair, mesure, diagnostic, actions.
Vise le vert sur les pages qui ramènent du trafic et des conversions. INP est une mesure terrain, si une page n’est presque jamais visitée, tu n’auras pas de données ou tu mettras longtemps à voir un effet dans les rapports.
Ce qui change, INP et le vert dans les rapports google
Les Core Web Vitals reposent sur trois métriques, LCP pour le chargement, INP pour la réactivité, CLS pour la stabilité visuelle. Google recommande de viser de bons scores, et précise aussi qu’un bon rapport ne garantit pas une place en tête, car le classement dépend d’autres signaux.
Même avec des Core Web Vitals au vert, tu peux rester invisible si ton contenu ne se prête pas à une réponse synthétique. Là, tu touches un autre levier, la façon dont tes pages se font citer par les assistants et moteurs IA.
Si tu veux cadrer ça proprement, tu peux lire cet article sur le GSO et le GEO, puis revenir à la partie mesure et actions sur INP.
Quand tu parles de vert, tu parles surtout de deux endroits, Search Console et PageSpeed Insights. Les deux reposent sur des données réelles, et classent les URL en bon, à améliorer, médiocre. Le rapport Search Console s’appuie sur LCP, INP, CLS, et le statut d’un groupe d’URL prend la pire métrique.
Seuils à viser pour passer au vert, sur la base du 75e percentile des visites, mobile et desktop séparés,
INP au plus 200 ms, LCP au plus 2,5 s, CLS au plus 0,1.
Mesurer INP
Pour INP, les docs web.dev le disent clairement, la meilleure mesure vient des vrais utilisateurs. Les tests en labo servent au diagnostic, mais le “vert” dépend des données terrain, calculées au 75e percentile sur les vrais utilisateurs.
Autre point qui surprend souvent, ces données bougent avec une inertie. Les sources basées sur CrUX agrègent une moyenne glissante sur 28 jours, donc ton correctif peut mettre du temps à se voir dans les rapports.
| Outil | 👍 Avantages | 👎 Inconvénients | 🎯 Quand tu l’utilises |
|---|---|---|---|
| Search Console, rapport Core Web Vitals | Vue terrain, groupée par types de pages, priorisation simple | Pas de cause racine, seulement des symptômes, délai lié à CrUX | Choisir où agir et suivre la bascule rouge, orange, vert |
| PageSpeed Insights | Terrain CrUX + audit Lighthouse au même endroit, page et origine | Le labo ne reflète pas toujours ce que vivent tes visiteurs, et certaines pages manquent de données terrain | Valider une page précise, comparer terrain et labo |
| Chrome UX Report, CrUX API | Données terrain agrégées, suivi d’une page ou d’une origine dans le temps | Moyenne glissante 28 jours, granularité et périmètre limités aux données éligibles | Monitoring régulier et dashboards |
| Chrome DevTools, Performance panel | Diagnostic chirurgical, visualise les tâches longues, les recalculs de style, le rendu | Temps d’analyse, demande un peu de méthode | Trouver exactement quel script bloque, et quand |
| RUM, Real User Monitoring | Le plus actionnable, relie INP à une interaction précise et à un contexte utilisateur | Implémentation, coût, gouvernance des données | Sites business, gros trafic, app web riche |
| Lighthouse seul | Reproductible, utile en CI, repère vite les gros problèmes | Mesure labo, INP dépend des interactions, et parfois Lighthouse ne peut pas produire un INP fiable | Contrôle qualité et régression techniques |
Comprendre INP, ce que la métrique mesure vraiment
INP mesure le délai entre une interaction et le prochain rendu visible, sur toute la visite, pas juste le premier clic. Les interactions prises en compte sont clic, tap, clavier. Le scroll et le survol ne comptent pas pour INP.
Comment le score se construit, INP retient l’interaction la plus lente observée, avec une logique qui ignore des valeurs extrêmes quand il y a énormément d’interactions, puis le résultat final se lit au 75e percentile des visites.
FID, lui, ne mesurait que le délai de la première interaction, sans tenir compte du temps de traitement ni du rendu. Résultat, tu pouvais avoir un FID vert et une interface pénible pendant la navigation. C’est une des raisons du passage à INP.
À noter, FID n’est plus un Core Web Vital, et son support a pris fin dans les outils Chrome à partir de septembre 2024.
La checklist INP au vert, du plus rentable au plus casse tête
INP se découpe en trois morceaux, input delay, traitement, rendu. Ta baisse d’INP viendra presque toujours d’un même angle, moins de blocage sur le thread principal, moins de travail dans les handlers, rendu plus léger.
- Repère la page et l’action qui font exploser INP, terrain d’abord, puis reproduction en local.
- Traque les tâches longues autour du clic, du tap, du clavier.
- Allège les handlers, fais le strict nécessaire avant le prochain rendu.
- Découpe le travail en plusieurs tâches, pour rendre la main au navigateur.
- Stoppe le layout thrashing, pas de lecture de layout juste après une écriture de style.
Maintenant, la version opératoire, avec quoi faire, pourquoi, comment vérifier.
| ✅ Action | 🧠 Ce que ça corrige | 🔎 Comment vérifier | ⚡ Priorité |
|---|---|---|---|
| 🧹 Supprime ou remplace les scripts qui bloquent l’interface | Moins de tâches longues, moins d’input delay pendant et après le chargement | DevTools, observe les tâches longues, compare avant après sur une action utilisateur | Haute |
| ✂️ Réduis le coût du JavaScript au démarrage | Moins de parsing, compilation, exécution, donc moins de blocage sur le thread principal | DevTools, regarde le temps passé en script evaluation et les long tasks | Haute |
| 🧩 Découpe le travail dans les callbacks, rends la main souvent | Handlers plus courts, interactions suivantes moins bloquées | DevTools, les long tasks se fragmentent, la latence du clic baisse | Haute |
| 🎞️ Donne la priorité au rendu visible, diffère le reste | Le prochain frame part plus vite, donc INP baisse | Test interaction, observe que l’élément change d’état plus tôt | Haute |
| 🧱 Évite le layout thrashing | Moins de recalculs synchrones de style et layout, rendu plus fluide | DevTools, repère les warnings et les recalculs dans la timeline | Moyenne |
| 🌿 Réduis la taille et la complexité du DOM | Moins de travail de rendu après interaction, présentation plus rapide | Profil rendu, compare le coût des recalculs et du paint | Moyenne |
| 👀 Utilise content visibility pour le hors écran | Moins de rendu inutile, le navigateur peint plus vite après interaction | Audit et vérification visuelle sur les zones hors viewport | Moyenne |
| 🧪 Si tu n’as pas de terrain fiable, utilise TBT comme proxy labo | TBT aide à voir le blocage du thread principal, même si ce n’est pas INP | Lighthouse, suis TBT et les opportunités, puis valide au terrain | Basse |
Sur un site WordPress ou un site à plugins, commence par une passe simple, désactive ce qui n’apporte rien au business, mesure, puis réactive un par un. Beaucoup de lenteurs INP viennent d’un empilement de scripts.
Pièges fréquents qui font exploser INP
- Tu te fies au labo et tu ignores le terrain, tu risques de corriger un problème théorique.
- Tu optimises le premier clic et tu oublies la navigation, INP mesure toute la visite.
- Tu ajoutes des features qui recalculent le layout à chaque interaction, et tu crées du layout thrashing.
- Tu embarques des iframes lourds, et tu oublies que leurs interactions comptent dans l’expérience globale.
- Tu attends un effet instantané dans Search Console, alors que les données CrUX sont agrégées sur 28 jours.
Laisser un commentaire