INP
Définition
Interaction to Next Paint. Métrique qui mesure la réactivité globale du site lors des interactions utilisateur. Objectif : sous 200 ms.
Ce que INP mesure
INP (Interaction to Next Paint) mesure la réactivité globale du site sur toute la durée de la visite. Pour chaque interaction (clic, tap, frappe au clavier), on chronomètre le temps entre l'action de l'utilisateur et le prochain rendu visuel du navigateur. La métrique retient le pire de tous ces temps sur la session, ou un percentile (98e) si le volume d'interactions est important. C'est l'indicateur qui répond à la question : quand je clique, est-ce que ça réagit instantanément ou est-ce que ça rame ? Plus la valeur est faible, plus le site se sent réactif.
Les seuils Google
Sous 200 ms, l'INP est bon (vert). Entre 200 et 500 ms, à améliorer (orange). Au-delà de 500 ms, mauvais (rouge). Le ranking se base sur le 75e percentile en field data. Un INP à 800 ms sur mobile devient perceptible pour l'utilisateur : chaque clic donne l'impression d'attendre. Au-dessus de la seconde, le site est désagréable. Sur les apps complexes (dashboards, configurateurs), c'est souvent la métrique la plus difficile à tenir, car chaque interaction déclenche du JavaScript significatif.
Pourquoi INP est plus dur que FID
FID ne mesurait que la première interaction, souvent un simple clic sur un lien de navigation. INP mesure toutes les interactions, y compris les plus coûteuses : ouvrir un menu, filtrer une liste, taper dans un champ avec validation en temps réel. Les pires cas remontent dans la métrique. Pour passer au vert, il faut une réactivité régulière, pas juste un beau démarrage. Les patterns courants comme les filtres qui recalculent toute la liste à chaque frappe, ou les formulaires qui valident sur chaque keystroke, sortent souvent en rouge si on n'a pas pris la précaution de débouncer.
Diagnostiquer un mauvais INP
Chrome DevTools, onglet Performance, capture l'interaction et révèle les tâches longues qui la bloquent. Web Vitals Extension affiche l'INP en temps réel pendant qu'on utilise le site. Pour le terrain, on installe un RUM (Real User Monitoring) qui segmente par interaction, par page et par appareil, et alerte sur les régressions. L'erreur classique est de tester en local sur un MacBook puissant et de voir des INP à 50 ms : sur un Android milieu de gamme, on dépasse facilement 500 ms. Tester sur appareil réel avec throttling CPU 4x dans DevTools est indispensable.
Les leviers techniques
Réduire le JavaScript exécuté côté client : Server Components, code splitting agressif, lazy-loading des composants secondaires. Découper les tâches longues : scheduler.yield() ou requestIdleCallback pour rendre la main au navigateur entre les blocs. Déplacer les calculs lourds en web workers (parsing JSON volumineux, calculs métier, compression). Débouncer ou throttler les handlers de frappe et de scroll. Éviter les re-renders React inutiles avec memo, useMemo, useCallback. Supprimer les scripts tiers qui ne servent à rien : c'est souvent là que se cachent les pires long tasks.
Les pièges classiques
Les hooks React qui font des calculs lourds dans le rendu sans memo bloquent à chaque changement d'état. Les state managers (Redux, Zustand mal configuré) qui notifient tous les composants au moindre changement explosent l'INP. Les bibliothèques d'animation lourdes (Framer Motion, GSAP mal utilisé) bloquent le thread sur les pages chargées. Les A/B testing tools qui injectent du code synchrone à l'ouverture allongent la première interaction. Les analytics tags qui s'exécutent à chaque clic sans throttle dégradent toute la session. Auditer ces points avant de chercher des optimisations exotiques est plus rentable.
Pourquoi INP devient critique
INP capte des problèmes invisibles en LCP : une page qui s'affiche vite mais bouge mollement à chaque clic. Sur les apps interactives (dashboards, configurateurs, marketplaces), c'est devenu l'indicateur le plus parlant. Sur les sites SEO, l'impact sur le ranking pousse à le surveiller. Sur les apps B2B avec utilisation prolongée, l'impact sur la productivité utilisateur justifie l'investissement. La bonne nouvelle, c'est que les optimisations qui réduisent l'INP profitent aussi à la lisibilité du code, à la maintenabilité, et à la consommation énergétique côté client. C'est rarement un travail perdu.