INP un an après : bilan p75 et CWV juin 2026

12 mars 2024, Google débranche le FID. INP devient officiellement la métrique de réactivité des Core Web Vitals. Quatorze mois plus tard, je tire le bilan terrain. Verdict : c'est la métrique CWV la plus ratée du web, et ça ne s'est pas franchement amélioré comme promis.

Le FID, c'était une métrique cadeau. Elle ne mesurait qu'une chose, le délai avant la première interaction, et 97 % des sites la passaient. L'INP, lui, mesure toutes les interactions de la session et calcule au 75e percentile la pire des moins pires. La barre est posée à 200 ms. Le passage a fait mal, et il continue de faire mal.

Selon les données HTTP Archive et CrUX agrégées dans le Web Almanac 2025 publié en novembre, 77 % des sites mobiles passent l'INP au seuil "bon" en données terrain. Côté desktop, c'est 97 %, autant dire un test de Bayrou. La vraie bataille se joue sur mobile, et l'écart mobile-desktop reste de 20 points de pourcentage, contre 23 en 2024.

Pour les sites qui ne sont pas dans la tranche des 1000 plus gros : la note moyenne mobile au p75 tourne autour de 131 ms, le desktop autour de 48 ms. Mobile fait donc 2,8 fois moins bien que desktop. Sur les 1000 sites les plus gros du web (qui ont en théorie le plus de ressources tech), seuls 63 % passent un INP "bon" sur mobile. Avant, c'était 53 %. Dix points de mieux en un an, sur le segment qui a le plus de moyens. Pour les autres, l'inertie est plus lente.

Là où ça pique, c'est ailleurs : 43 % des sites du web restent en zone "à améliorer" ou "mauvais" sur l'INP au p75 mobile. Sur les trois CWV combinés, seulement 48 % des sites mobiles passent. L'INP est le maillon faible. Le LCP s'améliore, le CLS est sous contrôle dans la plupart des CMS modernes, mais l'INP s'accroche.

DebugBear a aussi sorti ses chiffres géographiques. La Corée du Sud sort en tête avec un p75 mobile à 75 ms. La France, les États-Unis, l'Allemagne et le Japon plafonnent à 100 ms. Le Nigeria monte à 275 ms, le Lesotho et l'Angola dépassent 300 ms. La fracture du hardware est aussi une fracture INP. Vos visiteurs Android entrée de gamme paient le prix du JavaScript de votre dev MacBook.

L'INP a trois sous-parties, et tu dois savoir laquelle te plombe avant de coder quoi que ce soit. Beaucoup d'équipes optimisent au pif et perdent des semaines.

L'input delay, c'est le temps entre l'interaction et le début d'exécution du handler. En moyenne sur le web, il compte pour environ 18 % de l'INP total. Cause : un autre script bloque le main thread pile au moment où l'utilisateur clique.

La processing duration, c'est l'exécution réelle des handlers d'événements. Elle compte pour environ 40 %. Cause : ton code de gestionnaire fait trop de boulot d'un coup (re-render lourd, calcul synchrone, dispatch Redux qui cascade).

La presentation delay, c'est entre la fin du handler et le moment où le navigateur affiche le nouveau frame. Elle compte pour environ 42 %, soit la part la plus grosse. Cause : layout thrashing, recalcul de styles massif, hydration React qui se réveille au mauvais moment.

Le réflexe d'optimiser le code applicatif (le 40 % de processing) est compréhensible : c'est ton terrain. Sauf qu'il laisse 60 % du problème à plat. Tu veux vraiment baisser ton INP, tu attaques les trois fronts, pas un seul.

LoAF (Long Animation Frames) a shippé dans Chrome 123 début 2024 et est devenu en 2025-2026 le seul vrai outil utilisable pour comprendre pourquoi ton INP est dans le rouge. L'API Long Tasks, c'était bien gentil, mais elle te disait juste "ce script a duré plus de 50 ms" sans attribution claire.

LoAF mesure les frames d'animation longues (plus de 50 ms entre deux paints) et te donne l'attribution exacte : quel script, quel handler, quel élément. Combiné à web-vitals.js à partir de la v4, tu chopes les LoAF intersectés avec l'interaction INP via longAnimationFramesEntries. Tu sais qui a tué ton frame, pas juste qu'il a été tué.

import { onINP } from 'web-vitals/attribution'

onINP(
	({ attribution }) => {
		const loafs = attribution.longAnimationFramesEntries ?? []
		for (const loaf of loafs) {
			for (const script of loaf.scripts) {
				console.log(script.invoker, script.duration, script.sourceURL)
			}
		}
	},
	{ reportAllChanges: true },
)

Ce que je vois en pratique sur les sites clients : LoAF dénonce le script Google Tag Manager dans 7 cas sur 10, suivi par les widgets chat (Intercom, Crisp, Drift) et les A/B tests (VWO, Optimizely). Les scripts internes applicatifs sont rarement en tête. La dette INP, c'est souvent le tiers qu'on a chargé sans réfléchir.

Pour le contexte plus large des trois métriques, voir Core Web Vitals : optimiser LCP, CLS et INP en 2026.

Côté code, l'API qui a vraiment changé le quotidien en 2025-2026, c'est scheduler.yield(). Dispo en stable depuis Chrome 129 (septembre 2024), Edge 129, et arrivée dans Firefox 142 fin 2025. Le polyfill pour Safari et anciens navigateurs tourne via setTimeout(0).

Le principe est bête. Une tâche qui dépasse 50 ms est une "long task" qui plombe l'input delay. Tu la découpes en morceaux et tu cèdes la main au navigateur entre les morceaux. Avant scheduler.yield, on faisait ça avec setTimeout(0) ou MessageChannel, sauf que le navigateur reprenait n'importe quelle tâche en file d'attente avant ton code, donc tu te faisais doubler par des scripts tiers. scheduler.yield() redonne la main, puis te reprend en priorité haute.

async function processUserActions(actions) {
	for (const action of actions) {
		executeAction(action)
		if (shouldYield()) {
			await scheduler.yield()
		}
	}
}

function shouldYield() {
	return performance.now() - lastYieldTime > 50
}

Le pattern type que je déploie : batch de 50 ms max, yield, batch, yield. Sur un client e-commerce avec 80 cards produit qui se rendaient en une seule passe synchrone (380 ms d'INP au p75), le passage à des batches de 5 cards avec scheduler.yield() entre chaque a fait tomber l'INP à 145 ms. Pas d'autre changement, pas de refacto, juste le yield. Trois jours de dev, gain de 235 ms sur le p75 mobile.

Le piège : isInputPending() est officiellement déconseillé par l'équipe Chrome depuis 2025. Si tu vois ce pattern dans ta codebase, vire-le. Faux négatifs et logique fragile.

Côté frameworks, la situation s'est éclaircie sans devenir parfaite.

React 19 (stable depuis avril 2025) propose enfin une hydration concurrente qui priorise l'interaction utilisateur. Si l'utilisateur clique pendant que React hydrate un composant pas encore prêt, React arrête ce qu'il fait, hydrate la zone cliquée en priorité, puis reprend. Selective hydration via <Suspense>. C'est pas magique, mais ça soulage. Le retour terrain : un gain typique de 30 à 80 ms d'input delay sur les SPA bien découpées.

Le problème, c'est que beaucoup d'équipes n'utilisent pas les Suspense boundaries correctement. Si tu wrappes tout dans un seul Suspense racine, tu n'as rien gagné. La règle pratique : un Suspense par zone interactive indépendante. Header, sidebar, contenu principal, footer. Quatre boundaries minimum sur une page complexe.

Next.js App Router (depuis 2023) fait du Server Component par défaut, ce qui réduit drastiquement le JS envoyé au client. Pour l'INP, c'est un gain indirect : moins de JS = moins de hydration = moins d'input delay. Mais l'instrumentation web-vitals reste manuelle, l'issue GitHub vercel/next.js#45557 est fermée sans engagement. Tu instrumentes à la main dans un client component avec useReportWebVitals.

Vue Router et Nuxt : pas d'intégration officielle web-vitals. Tu plugues à la main. Le plugin vue-web-vitals existe sur GitHub, marqué WIP. Pas mieux que Next côté outillage.

Pour les sites SPA qui souffrent du problème d'agrégation INP (un INP global pour 10 routes), l'API Soft Navigations en origin trial Chrome 147 est la solution future, mais CrUX ne consomme pas encore la donnée. Détails et limites dans mon article sur l'origin trial Chrome 147 et les soft navigations.

Les chiffres de pass rate INP par CMS en 2026, ça donne un classement sans pitié.

Squarespace passe à environ 60 %. Wix s'est rapproché des 57 %, après des années à traîner sous les 40 %. Wix a investi gros dans une refonte avec hydration sélective et Suspense, le gain est visible. Shopify tourne autour de 55 %, plombé par les apps tierces que les marchands installent sans contrôle. WordPress reste à 40 %, plombé par l'écosystème plugin (un WooCommerce moyen charge 40+ fichiers JS différents par page).

La leçon : ton CMS ne décide pas seul de ton INP. Ton stack de plugins et tes scripts tiers, eux, décident. Un WordPress vanilla bien configuré peut être plus rapide qu'un Shopify saturé d'apps. La techno n'excuse rien.

Côté ranking, voilà ce que je vois et ce que disent les données fiables.

Google n'a jamais publié de poids chiffré pour les CWV. Ils restent un facteur de départage. Quand deux pages sont équivalentes en pertinence et autorité, l'INP fait pencher la balance. C'est petit, c'est marginal, mais c'est mesurable.

Après le core update de mars 2026, des observations terrain (notamment ALM Corp sur un échantillon de 1240 sites) ont reporté que les sites avec un INP supérieur à 300 ms au p75 mobile ont enregistré des baisses moyennes de positions de 0,8 à 4 places sur des requêtes compétitives. À prendre avec prudence : c'est une corrélation tierce, pas une causalité confirmée par Google. Ce que je retiens, c'est la direction. Sur les SERP compétitives, l'INP fait le tri.

Côté conversion, les chiffres sont plus durs. SpeedCurve a publié des données sur la corrélation INP / taux de conversion mobile : passer de 250 ms à 100 ms d'INP, c'est environ 10 % de conversions en plus sur des pages e-commerce mobile. redBus avait reporté +7 % de ventes après optimisation INP en 2024. Ça reste la métrique CWV dont l'impact business est le plus direct.

Pour creuser le poids global des CWV en ranking, voir mon analyse sur les Core Web Vitals 2026 et leur impact réel sur les classements.

Je le vois encore en juin 2026 : des équipes qui me sortent fièrement leur Lighthouse à 98 et qui ne comprennent pas pourquoi Search Console les flag en "à améliorer" depuis trois mois.

Lighthouse mesure en labo, sur un device simulé, dans des conditions parfaites. CrUX mesure en terrain, sur les vrais utilisateurs, leurs vrais Android Galaxy A14 sur 4G de campagne. Ce sont deux mondes. Google ranke sur le CrUX, pas sur le Lighthouse.

Le réflexe pro : tu coupes le réseau Lighthouse en "Slow 4G", tu mets le CPU throttling à 6x. Tu retestes. Si tu chutes à 60 sur INP en labo, tu vas chuter sur le terrain. Si tu tiens, tu as une vague chance de tenir.

Mais la seule source qui décide en SEO, c'est la donnée terrain. Search Console, PageSpeed Insights onglet "Champ", CrUX Dashboard, CrUX API, web-vitals.js dans ta propre RUM. Tout le reste est du diagnostic. Et arrête de croire que Lighthouse 98 = passing CWV. C'est un mensonge confortable.

Pour la méthodologie complète de mesure et d'optimisation, voir Core Web Vitals : optimiser LCP, CLS et INP en 2026.

Tu veux passer l'INP au p75 mobile sous 200 ms d'ici la fin du trimestre, voici l'ordre dans lequel j'attaque les chantiers chez mes clients.

1. Mesurer en terrain via web-vitals.js v4 avec attribution activée. Tu sors les LoAF, tu identifies les scripts coupables.
2. Auditer les scripts tiers. GTM en premier. Vire les tags morts, défère ceux qui peuvent l'être, isole les A/B tests sur des pages où ils sont vraiment nécessaires.
3. Découper les long tasks applicatives. Toute boucle qui traite plus de 50 ms passe au pattern scheduler.yield(). Le polyfill cross-browser fait le job partout.
4. Décharger sur Web Workers tout ce qui n'a pas besoin du DOM (parsing JSON lourd, calculs, dédoublonnage de listes, formatage de dates en masse).
5. Vérifier les Suspense boundaries React. Un boundary par zone interactive indépendante, pas un wrapper global.
6. Tester en CPU throttling 6x et réseau Slow 4G. Si tu ne tiens pas le seuil dans ces conditions, tu ne le tiendras pas sur le terrain.
7. Mesurer en CrUX 28 jours plus tard. Pas avant. Google moyenne sur cette fenêtre, ton gain ne se voit pas avant un mois complet.

L'INP a fait ce qu'on attendait : il a dégagé un problème UX que le FID cachait. Les sites qui passaient le FID à 97 % et qui plantaient à 65 % sur l'INP, c'était la réalité que le FID nous masquait depuis cinq ans. Tant mieux que ce soit visible.

Maintenant, en juin 2026, on a les outils. LoAF est mature, scheduler.yield() est partout, web-vitals.js v4 expose les bonnes attributions, les frameworks (React 19, Next.js App Router) ont enfin intégré ce qu'il faut. Les excuses techniques ne tiennent plus.

Ce qui va se passer dans les 12 prochains mois : Google va probablement publier des seuils plus durs à terme (150 ms au lieu de 200 ms), parce que la techno est prête et qu'ils ont l'habitude de pousser quand la barre se généralise. Si tu vises 200 ms aujourd'hui, tu seras dans le rouge demain. Vise 150 ms. C'est ce que je dis à mes clients depuis janvier.

L'INP n'est pas un sujet d'optimisation marginal. C'est devenu le séparateur principal entre les sites qu'on perçoit comme "modernes et rapides" et les sites qu'on perçoit comme "datés et lourds". Et cette perception, elle ne se ressent pas qu'au ranking, elle se ressent au taux de conversion. Les chiffres sont là.

• web.dev, Interaction to Next Paint (INP), documentation officielle
• HTTP Archive, Web Almanac 2025, Performance chapter
• DebugBear, Global INP Statistics 2025
• DebugBear, 2025 In Web Performance
• Chrome for Developers, INP Breakdown DevTools Insight
• Chrome for Developers, Long Animation Frames API
• Chrome for Developers, scheduler.yield() to break up long tasks
• web.dev, Optimize long tasks
• SpeedCurve, JavaScript long tasks and user impact
• SpeedCurve, Long Animation Frames guide
• Chrome UX Report release notes
• DebugBear, How to reduce the impact of third-party code
• web.dev, redBus INP case study
• Wix Engineering, Selective hydration with Suspense (INP)