---
title: "Interaction to Next Paint (INP) : mesurer et améliorer l'interactivité"
description: "Optimiser l'INP : une bonne valeur, c'est 200 ms maximum au 75e centile."
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/seo-geo/seo-technique/interaction-to-next-paint-inp-mesurer-et-ameliorer-linteractivite"
category: "SEO & GEO"
topic: "SEO technique"
updated: "2026-10-28T13:24:32.620Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Interaction to Next Paint (INP) : mesurer et améliorer l'interactivité

Interaction to Next Paint (INP) est un Core Web Vital qui mesure la réactivité d'un site sur l'ensemble des interactions de l'utilisateur au cours d'une visite, de la saisie jusqu'à la prochaine image affichée. Une bonne valeur se situe à 200 millisecondes ou moins au 75e centile. Depuis mars 2024, l'INP remplace le First Input Delay et, contrairement à lui, prend en compte toutes les interactions au lieu de la seule première.

## L’essentiel

- L'INP mesure la réactivité sur toutes les interactions d'un chargement de page ; une bonne valeur est <= 200 ms au 75e centile des chargements de page. Depuis mars 2024, il remplace le FID.
- Les données de terrain (CrUX, PageSpeed, web-vitals, RUM) font foi. Les données de laboratoire ne servent qu'au débogage, avec le Total Blocking Time comme indicateur indirect.
- Un thread principal surchargé est la cause numéro un. Sur mobile, la page médiane passe 2 366 ms en tâches longues (desktop : 329 ms). Avec 1 208 ms, le TBT y est environ 18 fois plus élevé que sur desktop.
- Sur mobile, seuls 74 % des sites affichent un bon INP, contre 97 % sur desktop. Le mobile a besoin de son propre budget JavaScript, plus strict.
- Fractionner les tâches longues (scheduler.yield, postTask, setTimeout), supprimer le JS inutilisé (44 % des octets livrés sur mobile) et limiter la fréquence des gestionnaires d'événements.
- Les Server Components, le streaming et l'hydratation sélective de Next.js réduisent le coût de l'hydratation. Economic Times est ainsi passé de ~1 000 ms à 257 ms d'INP.
- Les scripts de consentement et de tracking bloquent souvent la première interaction. Un chargement différé, conditionné au consentement ou déporté hors du thread principal protège l'INP dans le respect du RGPD.

## Pourquoi l'INP compte pour le SEO technique en Autriche

Interaction to Next Paint (INP) mesure la rapidité avec laquelle un site réagit aux interactions des utilisateurs. Les clics, les taps et les saisies au clavier déclenchent un traitement qui aboutit à la prochaine image affichée (paint). L'INP mesure le délai sur l'ensemble de la visite et pas seulement lors de la première saisie. Depuis le 12 mars 2024, l'INP est un [Core Web Vital stable et remplace le First Input Delay](https://web.dev/blog/inp-cwv-launch). La métrique fait ainsi partie des signaux d'expérience sur la page qui, selon la documentation de Google, [sont alignés sur les systèmes de classement principaux](https://developers.google.com/search/docs/appearance/core-web-vitals).

Pour les prestataires B2B en Autriche, c'est doublement important. D'abord, la réactivité est un facteur économique : une analyse de quatre sites e-commerce a montré une [corrélation négative constante entre l'INP et le taux de conversion](https://www.speedcurve.com/blog/INP-user-experience-correlation/), les conversions souffrant parfois dès 100 ms, donc dans la plage « bonne ». Ensuite, en Autriche, un peu plus de deux accès sur cinq proviennent d'appareils mobiles : selon StatCounter, le trafic se répartit entre [57,6 % sur desktop et 42,4 % sur mobile](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria) (mai 2026). Avec [8,69 millions d'internautes et un taux de pénétration de 95,3 %](https://datareportal.com/reports/digital-2026-austria) (octobre 2025), la [performance mobile](https://blckalpaca.at/fr/services/agence-seo) détermine une part considérable de la visibilité.

L'obstacle est bien réel. À l'échelle internationale, selon DebugBear, seuls [64,9 % des sites réussissaient le test INP](https://www.debugbear.com/blog/hardest-core-web-vitals-metric) sur mobile, contre 76,9 % pour le [CLS](https://blckalpaca.at/fr/base-de-connaissances/seo-geo/seo-technique/cumulative-layout-shift-cls-stabilite-visuelle). Seul le LCP, avec 54,9 %, était encore plus difficile à valider. Ces valeurs reposent sur des données CrUX de novembre 2023. Pour 2024, le Web Almanac arrive à [74 % de sites mobiles avec un bon INP, mais 97 % sur desktop](https://almanac.httparchive.org/en/2024/performance). L'écart entre appareils reste important.

## Comment fonctionne l'INP : trois phases et la différence décisive avec le FID

L'INP décompose chaque interaction en trois phases. **Input Delay :** le temps nécessaire pour que le thread principal se libère et puisse exécuter le gestionnaire d'événements. Un thread bloqué par du JavaScript allonge cette phase. **Processing Time :** l'exécution des gestionnaires d'événements eux-mêmes, c'est-à-dire ta logique métier, les mises à jour du framework et les calculs. **Presentation Delay :** le temps nécessaire au navigateur pour afficher le résultat et dessiner la frame suivante.

La différence centrale avec le [First Input Delay](https://blckalpaca.at/fr/base-de-connaissances/seo-geo/seo-technique/core-web-vitals-lcp-inp-et-cls-expliques) tient au périmètre de mesure. Le FID ne mesurait que le délai de la première saisie et ignorait le temps de traitement ainsi que le temps d'affichage. L'INP prend en compte toutes les interactions d'un chargement de page et remonte (de façon simplifiée) la valeur pertinente la plus élevée. Un site peut donc avoir eu un FID parfait et afficher malgré tout un mauvais INP, parce que des interactions ultérieures, comme l'ouverture d'un menu, le filtrage d'une liste ou l'envoi d'un formulaire, sont lentes. Le seuil : au moins 75 % des chargements de page doivent atteindre un INP [de 200 millisecondes au maximum](https://web.dev/articles/inp).

La cause principale des mauvaises valeurs est un thread principal surchargé. Les tâches longues le bloquent et retardent chaque nouvelle saisie. Toute tâche de plus de 50 ms est considérée comme une tâche longue. Les données sont sans appel : la page mobile médiane passe [2 366 ms en tâches longues, contre seulement 329 ms sur desktop](https://almanac.httparchive.org/en/2024/javascript), avec 14 tâches longues au lieu de 3 en médiane. Le Total Blocking Time, l'indicateur de laboratoire habituel pour l'INP, atteint en médiane [1 208 ms sur mobile contre 67 ms sur desktop](https://almanac.httparchive.org/en/2024/javascript), soit environ 18 fois plus.

## Mesurer l'INP : les données de terrain priment sur le labo

Pour un diagnostic fiable, tu dois séparer données de terrain et données de laboratoire.

**Données de terrain (de référence) :** elles proviennent d'utilisateurs réels. Le Chrome User Experience Report (CrUX) alimente PageSpeed Insights et la Search Console. Pour un suivi continu, tu intègres la bibliothèque JavaScript `web-vitals` ou une solution de Real User Monitoring (RUM). Seules les données de terrain reflètent les appareils, la qualité de réseau et les schémas d'interaction réels. C'est précisément là qu'apparaît le handicap du mobile, dû à la puissance de calcul et à la qualité de réseau réelles.

**Données de laboratoire (diagnostic) :** Lighthouse et les Chrome DevTools fournissent des valeurs reproductibles dans un environnement contrôlé. L'INP lui-même ne peut pas être mesuré directement en laboratoire, car il nécessite des interactions dans la durée. Le Total Blocking Time sert alors d'indicateur indirect : il montre à quel point le thread principal est bloqué pendant le chargement. Les données de laboratoire conviennent au débogage et aux tests de régression dans le pipeline CI, mais ne remplacent jamais l'évaluation sur le terrain.

Conséquence : n'optimise pas à l'aveugle pour un score Lighthouse. Priorise par centile. La valeur de l'INP est déterminée par l'extrémité lente de la distribution, c'est-à-dire à partir du 75e centile. Une interaction rapide dans la plupart des chargements, mais qui prend 600 ms dans un tiers des cas, voilà ton vrai problème.

## Bonnes pratiques : soulager le thread principal et accélérer les interactions

Les leviers les plus efficaces réduisent le travail JavaScript ou l'étalent dans le temps.

**Fractionner les tâches longues :** découpe le travail en unités plus petites et rends la main au thread principal avant de dépasser 50 ms. `scheduler.yield()` cède la main après le travail en cours et le reprend en priorité. `scheduler.postTask()` permet de définir des priorités explicites. `setTimeout` sert de solution de repli mieux prise en charge. Google [déconseille désormais](https://web.dev/articles/optimize-long-tasks) `isInputPending()`, car l'[API](https://blckalpaca.at/fr/glossaire/api) peut manquer des saisies. Mieux vaut rendre la main régulièrement, qu'une saisie soit en attente ou non.

**Réduire la charge JavaScript :** en médiane, [558 Ko de JavaScript sont livrés sur mobile, dont environ 206 Ko inutilisés](https://almanac.httparchive.org/en/2024/javascript), soit 44 %. Le code splitting, le tree shaking et la suppression du code mort agissent directement sur l'Input Delay et le Processing Time. Ne charge que ce dont chaque page a besoin et diffère la logique non critique.

**Optimiser les gestionnaires d'événements :** limite les événements fréquents. Le debouncing pour les saisies et le throttling pour les gestionnaires de scroll ou de resize évitent du travail inutile. L'étude de cas redBus le montre précisément : grâce au debouncing du gestionnaire de scroll et à une gestion locale de l'état avec synchronisation Redux différée, [l'INP de la page de recherche a baissé de 72 %, avec une hausse du chiffre d'affaires de 7 %](https://web.dev/case-studies/redbus-inp). Évite les re-renders coûteux, utilise `requestAnimationFrame` pour les mises à jour visuelles, privilégie le CSS au JavaScript pour les animations et allège le rendu avec `content-visibility`.

**Dompter les scripts tiers et de consentement :** les scripts de tracking, de tag manager et de consentement tournent souvent sur le thread principal et le bloquent précisément au moment où l'utilisateur veut interagir. Charge-les en différé, après la première interaction ou dans un Web Worker. Vérifie quels scripts sont vraiment critiques.

## Architecture Next.js pour des valeurs d'INP basses

Avec Next.js, une grande partie de la charge INP vient de l'hydratation : le navigateur doit « ranimer » avec du JavaScript client le HTML rendu côté serveur, ce qui sollicite le thread principal.

[**React Server Components](https://blckalpaca.at/fr/services/logiciel-sur-mesure) :** les composants sans interactivité sont rendus côté serveur et n'envoient pas de JavaScript au client. Cela réduit le bundle et donc le coût de l'hydratation à la racine. L'effet est documenté en pratique : Economic Times a réduit le Total Blocking Time de [3 260 ms à 120 ms et l'INP d'environ 1 000 ms à 257 ms](https://web.dev/case-studies/economic-times-inp), notamment grâce à la migration vers Next.js. Résultat : 50 % de rebonds en moins et 43 % de pages vues en plus.

**Streaming et Suspense :** avec `<Suspense>`, tu streames des parties de la page dès qu'elles sont prêtes, au lieu de tout attendre. Cela raccourcit le délai avant que les zones visibles deviennent interactives.

**Hydratation sélective et imports dynamiques :** ne marque comme composants client que les îlots interactifs (`"use client"`). Les composants client lourds, tu les charges via `next/dynamic`, idéalement seulement quand ils sont nécessaires. Tu évites ainsi les gros bundles client qui bloquent tôt le thread principal.

## Erreurs fréquentes dans l'optimisation de l'INP

**Ne regarder que le score Lighthouse :** une valeur verte en laboratoire ne garantit pas un bon INP sur le terrain. Les données de laboratoire ne connaissent pas les vraies interactions dans la durée. Sans données de terrain ni analyse par centile, tu optimises à côté du problème.

**Ignorer le cas le plus lent :** qui regarde des moyennes passe à côté du 75e centile. C'est précisément là que l'INP est mesuré. Identifie de manière ciblée l'interaction la plus lente.

**Laisser les scripts de consentement et de tracking intacts :** les scripts de bannière apparaissent tôt et bloquent souvent justement la première interaction. Sans chargement différé ou déporté, l'effet reste visible, surtout dans les conditions réelles des appareils mobiles.

**Mettre sur le même plan budget mobile et budget desktop :** les appareils mobiles ont moins de puissance de calcul. Avec un [TBT médian de 1 208 ms sur mobile contre 67 ms sur desktop](https://almanac.httparchive.org/en/2024/javascript), le mobile a besoin d'un budget JavaScript plus strict. Un bundle acceptable sur desktop peut faire exploser le seuil sur mobile.

**Accumuler du JavaScript sans contrôle :** si 44 % du [JavaScript livré est inutilisé](https://almanac.httparchive.org/en/2024/javascript), c'est du poids mort. Vérifie régulièrement la couverture de code et supprime le code inutilisé.

## Métriques, débogage et priorisation en pratique

Pour un débogage ciblé, il existe aujourd'hui des outils précis.

**API Long Animation Frames (LoAF) :** elle fournit des données détaillées sur les frames longues, y compris les scripts responsables et la source du blocage. Tu identifies ainsi non seulement qu'une frame a été longue, mais aussi quel code l'a causée.

**Panneau Performance des Chrome DevTools :** il affiche la piste des interactions avec Input Delay, Processing Time et Presentation Delay. Tu vois ainsi laquelle des trois phases domine et tu adaptes l'action en conséquence : l'Input Delay signale des blocages du thread principal, un Processing Time long des gestionnaires coûteux, un Presentation Delay élevé des coûts de rendu ou de layout.

**Attribution de l'interaction la plus lente :** avec la bibliothèque `web-vitals` en mode attribution ou une solution RUM, tu enregistres pour chaque chargement de page la pire interaction avec son contexte. Priorise selon la fréquence et la gravité au 75e centile.

**Définir des valeurs cibles pour l'Autriche :** fixe 200 ms comme plafond strict, mais prévois une marge, car selon [SpeedCurve, les conversions souffrent parfois dès 100 ms](https://www.speedcurve.com/blog/INP-user-experience-correlation/). Définis des budgets distincts pour le mobile et le desktop. Comme, selon StatCounter, [42,4 % du trafic était mobile](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria) en Autriche en mai 2026 et que les appareils mobiles dépassent nettement plus souvent le seuil malgré [99,5 % de connexions mobiles en haut débit (3G/4G/5G)](https://datareportal.com/reports/digital-2026-austria), le budget mobile devrait être ton principal indicateur de pilotage.

## Pour aller plus loin : INP, crawlers IA et consentement RGPD

L'INP n'agit pas de manière isolée. Pour la [Generative Engine Optimization](https://blckalpaca.at/fr/services/geo) (GEO), ce qui compte avant tout, c'est le contenu livré que les crawlers [IA](https://blckalpaca.at/fr/glossaire/ia) récupèrent. Une architecture légère, rendue côté serveur, aide autant les crawlers que les utilisateurs : les Server Components réduisent le JavaScript client et livrent le contenu directement dans le HTML initial. Les crawlers le récupèrent de façon plus fiable, et les utilisateurs sont servis plus vite.

Le consentement [RGPD](https://blckalpaca.at/fr/glossaire/rgpd) est l'angle mort le plus fréquent. Les [plateformes de gestion du consentement](https://blckalpaca.at/fr/base-de-connaissances/seo-geo/seo-technique/consent-mode-v2-et-privacy-sandbox-ce-qui-reste-apres-2025) se chargent tôt, affichent des overlays et déclenchent, en cas d'acceptation, une cascade de scripts tiers qui sollicitent tous le thread principal. Trois mesures aident sans compromettre la conformité juridique : charge les scripts de tracking uniquement après obtention du consentement et en différé. Déporte les scripts non essentiels côté serveur ou dans un Web Worker. Et garde le script de consentement lui-même aussi léger que possible, puisqu'il apparaît par définition avant la première interaction. Ainsi, le thread principal reste libre quand l'utilisateur ferme la bannière, et c'est justement cette première interaction qui entre dans le calcul de l'INP.

## Données et statistiques

- L'INP est un Core Web Vital stable depuis le 12 mars 2024 et remplace le First Input Delay ; seuil de 200 ms au 75e centile — [web.dev (équipe Google Chrome) - 'Interaction to Next Paint is officially a Core Web Vital' (2024)](https://web.dev/blog/inp-cwv-launch)
- INP < 200 ms, LCP < 2,5 s, CLS < 0,1 comme seuils de bonne performance ; les Core Web Vitals sont alignés sur les systèmes de classement principaux de Google — [Google Search Central - 'Understanding Core Web Vitals and Google search results' (2025)](https://developers.google.com/search/docs/appearance/core-web-vitals)
- 74 % des sites mobiles contre 97 % des sites desktop avec un bon INP (<= 200 ms) en 2024 — [HTTP Archive - Web Almanac 2024, chapitre Performance (2024)](https://almanac.httparchive.org/en/2024/performance)
- Total Blocking Time médian : 1 208 ms sur mobile contre 67 ms sur desktop (environ 18 fois plus) — [HTTP Archive - Web Almanac 2024, chapitre JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- Temps médian en tâches longues : 2 366 ms sur mobile contre 329 ms sur desktop ; 14 contre 3 tâches longues en médiane — [HTTP Archive - Web Almanac 2024, chapitre JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- 558 Ko de JS livrés sur mobile en médiane ; environ 206 Ko inutilisés (44 % des octets livrés) — [HTTP Archive - Web Almanac 2024, chapitre JavaScript (2024)](https://almanac.httparchive.org/en/2024/javascript)
- INP de la page de recherche amélioré de 72 %, +7 % de chiffre d'affaires grâce au debouncing et à la gestion locale de l'état — [web.dev (Google) - Étude de cas 'How redBus improved their website's INP' (2024)](https://web.dev/case-studies/redbus-inp)
- TBT 3 260 ms -> 120 ms ; INP ~1 000 ms -> 257 ms ; -50 % de taux de rebond ; +43 % de pages vues ; migration vers Next.js — [web.dev (Google) - Étude de cas 'Economic Times quest for fixing INP' (2023)](https://web.dev/case-studies/economic-times-inp)
- Corrélation négative constante entre l'INP et le taux de conversion sur quatre sites e-commerce ; effet parfois dès un INP = 100 ms — [SpeedCurve - 'Does Interaction to Next Paint actually correlate to user behavior?' (Cliff Crocker) (2023)](https://www.speedcurve.com/blog/INP-user-experience-correlation/)
- Autriche : 57,6 % desktop contre 42,4 % mobile (mai 2026) — [StatCounter Global Stats - Desktop vs Mobile Market Share Austria (2026)](https://gs.statcounter.com/platform-market-share/desktop-mobile/austria)
- Autriche : 8,69 millions d'internautes (taux de pénétration de 95,3 %, octobre 2025) ; 99,5 % des connexions mobiles en haut débit (3G/4G/5G) — [DataReportal - Digital 2026: Austria (2026)](https://datareportal.com/reports/digital-2026-austria)
- Mobile : INP bon pour 64,9 %, CLS bon pour 76,9 %, LCP bon pour 54,9 % (bonne expérience dans au moins 75 % des cas ; données CrUX au niveau de l'origine, novembre 2023) — [DebugBear - 'Core Web Vitals: Which Metric Is The Hardest To Pass?' (2025)](https://www.debugbear.com/blog/hardest-core-web-vitals-metric)

## Questions fréquentes

### Qu'est-ce qu'une bonne valeur d'INP ?

Une bonne valeur d'INP se situe à 200 millisecondes ou moins, mesurée au 75e centile des chargements de page (chaque chargement compte essentiellement avec son interaction la plus lente). Au-delà de 500 ms, les valeurs sont considérées comme mauvaises. Ce sont les données de terrain d'utilisateurs réels qui font foi, pas les mesures en laboratoire. Comme, selon une analyse internationale, les conversions souffrent parfois dès 100 ms, il est judicieux de garder une marge sous le seuil.
### En quoi l'INP se distingue-t-il du First Input Delay (FID) ?

Le FID ne mesurait que le délai de la première saisie et ignorait le temps de traitement et d'affichage. L'INP prend en compte toutes les interactions d'une visite et remonte la valeur pertinente la plus élevée. Il couvre les trois phases Input Delay, Processing Time et Presentation Delay. L'INP a remplacé le FID comme Core Web Vital le 12 mars 2024.
### Comment mesurer correctement l'INP ?

Tu mesures l'INP à partir des données de terrain du Chrome User Experience Report (CrUX), de PageSpeed Insights, de la Search Console, de la bibliothèque web-vitals ou d'une solution RUM. Les données de laboratoire issues de Lighthouse et des DevTools ne servent qu'au débogage, le Total Blocking Time faisant office d'indicateur indirect de l'INP. L'INP lui-même ne peut pas être mesuré directement en laboratoire, car il nécessite de vraies interactions dans la durée.
### Pourquoi mon INP est-il moins bon sur mobile que sur desktop ?

Les appareils mobiles disposent de moins de puissance de calcul et souvent d'une moins bonne qualité de réseau. La page mobile médiane passe environ 2 366 ms en tâches longues, contre seulement 329 ms sur desktop. Le Total Blocking Time médian est lui aussi environ 18 fois plus élevé sur mobile : 1 208 ms contre 67 ms sur desktop. C'est pourquoi le mobile a besoin de son propre budget JavaScript, plus strict.
### Comment Next.js améliore-t-il l'INP ?

Next.js réduit l'INP surtout grâce aux React Server Components, qui n'envoient pas de JavaScript au client et réduisent ainsi le coût de l'hydratation. Le streaming avec Suspense, l'hydratation sélective des îlots interactifs et les imports dynamiques évitent les gros bundles côté client. En migrant vers Next.js et en réduisant le Total Blocking Time, Economic Times a fait baisser son INP d'environ 1 000 ms à 257 ms.
### Quel rôle jouent les bannières de consentement et les scripts de tracking pour l'INP ?

Les plateformes de gestion du consentement et les scripts de tracking se chargent tôt et bloquent souvent le thread principal précisément au moment où l'utilisateur ferme la bannière. Cette première interaction entre directement dans le calcul de l'INP. Charge les scripts de tracking uniquement après obtention du consentement et en différé, déplace les scripts non essentiels dans un Web Worker et garde le script de consentement lui-même léger, sans compromettre la conformité au RGPD.
### L'INP influence-t-il le classement Google ?

Oui. L'INP fait partie des signaux d'expérience sur la page qui, selon la documentation de Google, sont alignés sur les systèmes de classement principaux. Un bon INP n'est certes pas un facteur de classement à lui seul, mais il agit comme levier pour la conversion et l'expérience utilisateur. Une analyse de quatre sites e-commerce a montré une corrélation négative constante entre l'INP et le taux de conversion.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/seo-geo/seo-technique/interaction-to-next-paint-inp-mesurer-et-ameliorer-linteractivite). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.