INP (Interaction to Next Paint) — Core Web Vitals 2024-2025
#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. Signal Core Web Vitals pris en compte par Google 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
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.
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
Exemple de situation : DNVB cosmétique, de Shopify Liquid à Hydrogen — Une migration vers Shopify Hydrogen (Next.js). On mesure l'INP au 75e percentile avant et après la bascule : un INP de plusieurs centaines de millisecondes sur un thème Liquid chargé en scripts doit repasser sous le seuil de 200 ms.
Exemple de situation : retailer omnicanal, refonte JavaScript — Un audit Core Web Vitals révèle un INP supérieur à 500 ms. La refonte JavaScript passe par un tree-shaking poussé, du code-splitting et une hydratation différée, puis l'INP est remesuré en conditions réelles (CrUX) pour vérifier qu'il repasse sous le seuil.
Exemple de situation : distributeur B2B, architecture composable — Une architecture composable Next.js, Medusa.js et edge functions. Dès la mise en production, l'INP est suivi en RUM par type de page et par appareil, pour garder les interactions sous le seuil de 200 ms.
#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 projets qui touchent à ce sujet, on documente les résultats avec des indicateurs fixés dès le cadrage. 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 sont mesurés pendant le projet, sur des indicateurs fixés au départ. 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.
- Core Web Vitals (métriques performance Google)
- LCP (Largest Contentful Paint)
- CLS (Cumulative Layout Shift)
- Lighthouse (outil audit Google)
- Next.js (framework React full-stack)
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
« Une migration vers Shopify Hydrogen (Next.js). On mesure l'INP au 75e percentile avant et après la bascule : un INP de plusieurs centaines de millisecondes sur un thème Liquid chargé en scripts doit repasser sous le seuil de 200 ms. »
« Un audit Core Web Vitals révèle un INP supérieur à 500 ms. La refonte JavaScript passe par un tree-shaking poussé, du code-splitting et une hydratation différée, puis l'INP est remesuré en conditions réelles (CrUX) pour vérifier qu'il repasse sous le seuil. »
« Une architecture composable Next.js, Medusa.js et edge functions. Dès la mise en production, l'INP est suivi en RUM par type de page et par appareil, pour garder les interactions sous le seuil de 200 ms. »
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 : Au lancement, bien moins d'origines web atteignaient la zone verte avec l'INP qu'avec le 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.