L'INP (Interaction to Next Paint) mesure la latence entre une interaction utilisateur (clic, tap, frappe clavier) et le moment où le navigateur peint le résultat visuel de cette interaction. Contrairement à son prédécesseur FID (First Input Delay) qui ne regardait que la première interaction, l'INP regarde toutes les interactions de la session et retient la pire (au 98e percentile). C'est devenu officiellement un Core Web Vitals en mars 2024, en remplacement de FID — beaucoup de sites qui avaient un bon FID se sont retrouvés en rouge sur l'INP.
Les seuils Google : ≤ 200 ms = bon, 200-500 ms = à améliorer, > 500 ms = mauvais. Le coupable principal est presque toujours le même : trop de JavaScript qui bloque le main thread. Quand l'utilisateur clique, le navigateur doit attendre que le main thread soit libre avant d'exécuter le handler, puis effectuer le re-render. Si vous avez un script analytics monstrueux, un framework qui hydrate 200 composants au chargement, ou des handlers de scroll mal écrits, l'INP s'effondre. Les SPA React lourdes sont les premières victimes.
Les fixes : (1) réduire la taille du JavaScript embarqué — c'est là que les RSC de Next.js brillent, vous n'expédiez plus que ce qui est interactif, (2) déférer les third-parties (analytics, chat, A/B test) en post-load, (3) découper les longues tâches avec `scheduler.yield()` ou des web workers, (4) éviter les setState en cascade sur un seul handler, (5) utiliser le composant Script de Next avec `strategy="lazyOnload"` pour les widgets non-critiques. L'INP est le plus dur des trois Core Web Vitals à corriger sur un site existant — c'est souvent le déclencheur d'une refonte sur site sur-mesure.
Quick wins pour faire baisser l'INP sous 200 ms
- Auditer le JS embarqué : Chrome DevTools → Performance → Long Tasks. Tuer ou différer tout ce qui dépasse 50 ms.
- Différer les third-parties : analytics, GTM, chat, intercom → `defer` + chargement post-interaction.
- Réduire l'hydration React : passer aux RSC de Next.js, n'hydrater que ce qui est vraiment interactif.
- Découper les handlers lourds : `scheduler.yield()` (API moderne) ou web workers pour sortir le calcul du main thread.
