Définition & Concepts

INP (Interaction to Next Paint) — Core Web Vitals 2024-2025

Version Décideur

L'essentiel

INP est le score Google qui mesure à quelle vitesse votre site réagit quand un utilisateur clique, tape ou interagit. Imaginez : vous cliquez sur 'Ajouter au panier', et vous attendez 800 ms avant de voir l'effet → mauvais INP. Vous voyez l'effet en 100 ms → excellent INP. Google a remplacé l'ancienne métrique FID par INP en mars 2024 parce que FID ne mesurait que la première interaction. INP mesure TOUTES les interactions. Critique pour le SEO depuis 2024.

Version Expert

Détails Techniques

Métrique Core Web Vitals introduite par Google en mars 2024 (remplaçant FID — First Input Delay). INP mesure le temps de réaction d'une page web aux interactions utilisateur : du clic, tap ou touche clavier jusqu'au prochain rendu visuel. Seuils Google : bon <200 ms, à améliorer 200-500 ms, mauvais >500 ms. Mesuré au 75e percentile sur la totalité des interactions d'une session. Facteur de classement SEO direct depuis 2024. Distingue les sites monolithiques lents (Magento 2, Salesforce SC) des sites modernes (Next.js, Shopify Hydrogen).

#Définition INP (Interaction to Next Paint) — Core Web Vitals 2024-2025

Métrique Core Web Vitals introduite par Google en mars 2024 (remplaçant FID — First Input Delay). INP mesure le temps de réaction d'une page web aux interactions utilisateur : du clic, tap ou touche clavier jusqu'au prochain rendu visuel. Pour approfondir, consultez la page service développement web performance Nehos.

Traduit en termes opérationnels, Seuils Google : bon <200 ms, à améliorer 200-500 ms, mauvais >500 ms. Mesuré au 75e percentile sur la totalité des interactions d'une session. Facteur de classement SEO direct depuis 2024. Distingue les sites monolithiques lents (Magento 2, Salesforce SC) des sites modernes (Next.js, Shopify Hydrogen).

La compréhension fine de INP (Interaction to Next Paint) — Core Web Vitals 2024-2025 différencie les équipes qui livrent des résultats de celles qui accumulent de la dette.

#INP (Interaction to Next Paint) — Core Web Vitals 2024-2025 expliqué simplement

Imaginez que vous dirigez une PME ou une scale-up. Voilà pourquoi on insiste sur la mesure : pas de décision sans donnée.

#Cas d'usage concrets

DNVB cosmétique Shopify Liquid → Hydrogen — Migration Shopify Hydrogen Next.js par Nehos. INP avant : 380 ms (mauvais). INP après : 95 ms (excellent). Conversion mobile +34 %.

Retailer omnicanal mid-market — Audit Core Web Vitals = INP 520 ms. Refonte JavaScript : tree-shaking agressif, code-splitting, lazy hydration. INP 145 ms après 6 semaines. Position Google +18 % organic.

Distributeur B2B Medusa.js custom — Architecture composable Next.js + Medusa.js + edge functions. INP 78 ms dès go-live. Top 1 % marché Core Web Vitals.

#INP (Interaction to Next Paint) — Core Web Vitals 2024-2025 chez Nehos Groupe

Chez Nehos Groupe, on ne se contente pas de théoriser. Sur les 3 derniers projets impliquant INP (Interaction to Next Paint) — Core Web Vitals 2024-2025, on a documenté les résultats avec des KPIs précis. Notre service développement web performance Nehos couvre ce périmètre de A à Z.

La méthode Nehos est documentée sur Méthode Composable Commerce Stack Nehos. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 34 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : service headless commerce Next.js et Hydrogen.

#Termes associés

Pour aller plus loin, explorez les termes connexes.

Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.

#Points clés à retenir

Quels sont les seuils INP exacts définis par Google ? Google publie trois paliers dans la documentation officielle web.dev. Un INP est considéré comme bon en dessous de 200 millisecondes mesurées au 75e percentile (P75) sur 28 jours glissants — cela signifie que 75 % des interactions de vos utilisateurs réels doivent finir sous ce seuil.

Comment mesurer concrètement l'INP d'un site en production ? Il existe trois sources complémentaires, et il faut les croiser. Premièrement, la PageSpeed Insights ou Search Console qui exposent la donnée CrUX agrégée par Google sur les utilisateurs Chrome réels — c'est la source qui compte pour le SEO.

Quelle est la vraie différence entre INP et FID (First Input Delay) ? Le FID, métrique sortante, mesurait uniquement le délai d'attente avant traitement de la première interaction — typiquement le tout premier clic sur la page. C'était insuffisant à deux titres.

Applications Concrètes

Contexte : DNVB cosmétique Shopify Liquid → Hydrogen

"Migration Shopify Hydrogen Next.js par Nehos. INP avant : 380 ms (mauvais). INP après : 95 ms (excellent). Conversion mobile +34 %."

Contexte : Retailer omnicanal mid-market

"Audit Core Web Vitals = INP 520 ms. Refonte JavaScript : tree-shaking agressif, code-splitting, lazy hydration. INP 145 ms après 6 semaines. Position Google +18 % organic."

Contexte : Distributeur B2B Medusa.js custom

"Architecture composable Next.js + Medusa.js + edge functions. INP 78 ms dès go-live. Top 1 % marché Core Web Vitals."

Questions & Réponses

Questions fréquentes sur l'INP (Interaction to Next Paint)

Google publie trois paliers dans la documentation officielle web.dev. Un INP est considéré comme bon en dessous de 200 millisecondes mesurées au 75e percentile (P75) sur 28 jours glissants — cela signifie que 75 % des interactions de vos utilisateurs réels doivent finir sous ce seuil. Entre 200 et 500 ms, le site est dans la zone à améliorer (orange dans Search Console). Au-delà de 500 ms, la métrique est considérée comme mauvaise, et la page est pénalisée dans le ranking organique. À noter : ces seuils sont mesurés sur la donnée terrain (CrUX, Chrome User Experience Report), pas sur Lighthouse en laboratoire — c'est une source régulière de confusion.

Il existe trois sources complémentaires, et il faut les croiser. Premièrement, la PageSpeed Insights ou Search Console qui exposent la donnée CrUX agrégée par Google sur les utilisateurs Chrome réels — c'est la source qui compte pour le SEO. Deuxièmement, le RUM (Real User Monitoring) interne via la web-vitals library de Google, branchée sur votre propre back-end ou un outil tiers (SpeedCurve, Datadog, New Relic) — utile pour segmenter par device, géographie, type de page. Troisièmement, Lighthouse ou Chrome DevTools pour l'analyse en laboratoire pendant le développement — attention, le score Lighthouse INP est synthétique et ne reflète pas toujours la réalité terrain. Notre recommandation chez Nehos : Lighthouse CI sur chaque PR, web-vitals JS en production, et reporting hebdomadaire CrUX.

Le FID, métrique sortante, mesurait uniquement le délai d'attente avant traitement de la première interaction — typiquement le tout premier clic sur la page. C'était insuffisant à deux titres. D'abord parce qu'il ne capturait qu'une seule interaction par session, ce qui flattait les pages dont la première interaction tombait pendant une fenêtre d'inactivité. Ensuite parce qu'il ne mesurait que le délai d'entrée (input delay), sans inclure le temps de traitement JavaScript ni le temps de rendu visuel. L'INP corrige les deux : il mesure toutes les interactions de la session (clic, tap, touche clavier, hors scroll et hover) et retient la pire au 75e percentile, et il chronomètre la chaîne complète de l'événement DOM jusqu'au prochain frame painté à l'écran.

Réponse honnête : parce que FID était trop facile à truquer et donnait une image fausse de l'expérience utilisateur réelle. La quasi-totalité des sites obtenaient un bon score FID sans rien faire, alors que beaucoup ramaient violemment sur les interactions suivantes (filtres produits, ajout panier, ouvertures de modales). L'INP est nettement plus exigeant et discriminant : Google a publié que seulement environ 64 % des origines web ont un INP en zone verte au lancement, contre 95 % pour FID. C'est exactement ce que Google cherchait — une métrique qui sépare réellement les sites rapides des sites lents, et qui pousse l'industrie à investir sur la performance d'interaction, pas seulement de chargement. C'est aussi un signal politique : Google veut récompenser les architectures modernes (React Server Components, edge rendering, lazy hydration) et pénaliser les monolithes JavaScript lourds.

Notre stack standard chez Nehos sur les projets Next.js et headless commerce. Lighthouse CI branché en pré-merge sur GitHub Actions, avec budget INP strict (échec du build au-dessus de 200 ms en laboratoire). Web-vitals JS library officielle de Google injectée en production, avec envoi des metrics vers Datadog ou un endpoint custom Payload pour stockage long terme. Tableau de bord Grafana ou Datadog qui croise INP avec device (mobile vs desktop), géographie, type de page, version déployée. Et alerting Slack si le P75 INP dépasse 250 ms pendant plus de 30 minutes en production. Sur les très gros catalogues e-commerce, on ajoute SpeedCurve ou DebugBear qui font du synthetic monitoring multi-géo en complément. Le tout est intégrable en 2 à 3 jours pour une équipe technique standard, et c'est probablement le meilleur ratio investissement/valeur SEO en 2025.

Exploration associée

service développement web performance Nehos service headless commerce Next.js et Hydrogen refonte e-commerce et retail haute performance Méthode Composable Commerce Stack Nehos Core Web Vitals : panorama des trois métriques Next.js : framework React full-stack