Performance Web
Qu’est-ce que INP (Interaction to Next Paint) ?
Métrique Core Web Vitals qui mesure la réactivité : le temps entre une interaction utilisateur (clic, toucher, frappe clavier) et le prochain frame peint par le navigateur.
Définition simple
C'est comme mesurer le délai entre le bouton poussé et la lumière qui s'allume : au-delà de quelques centaines de millisecondes, on doute que ça marche. Métrique Core Web Vitals qui mesure la réactivité : le temps entre une interaction utilisateur (clic, toucher, frappe clavier) et le prochain frame peint par le navigateur. Remplace le FID (First Input Delay) depuis mars 2024. Un INP faible (< 200 ms) indique une interface réactive ; au-delà, l’utilisateur perçoit un lag. Les causes fréquentes : JavaScript long sur le main thread, handlers trop lourds, layout thrashing. Mesurable via Chrome DevTools (Performance), PageSpeed Insights et les outils RUM (Real User Monitoring). L’INP prend en compte la pire interaction sur la page (ou une valeur haute percentile) pour refléter l’expérience des utilisateurs les plus impactés. Les long tasks (tâches JS > 50 ms) bloquent le main thread et retardent la réponse aux clics. Le découpage du JavaScript, le debounce des handlers et l’utilisation de web workers pour les calculs lourds améliorent l’INP.
Comment ça marche ?
Le navigateur mesure le délai entre chaque interaction (clic, toucher, frappe) et le prochain frame affiché. La valeur INP retenue est en général une haute percentile (p75). Les long tasks JavaScript sur le main thread retardent la réponse.
Impact business
Un mauvais INP dégrade l’expérience (boutons qui « ne répondent pas », formulaires saccadés) et peut impacter le classement Google. Les sites avec beaucoup d’interactions (e-commerce, apps, formulaires) doivent surveiller et optimiser l’INP pour garder un bon score Core Web Vitals et limiter l’abandon. Une interface perçue comme lente ou bloquante augmente le taux de rebond et réduit les conversions (panier, inscription). Améliorer l’INP renforce la crédibilité technique et l’expérience sur mobile où les processeurs sont moins puissants. Ramener l'INP p75 sous 200 ms sur un tunnel checkout supprime en pratique la majorité des retours « bouton mort » sur mobile milieu de gamme et fait souvent chuter d'un à plusieurs points le taux d'abandon sur l'étape paiement lorsque le JS principal était auparavant saturé.
Bonnes pratiques
- Réduire le JS sur le main thread (code splitting, lazy load), alléger les handlers (debounce). Mesurer avec Lighthouse et RUM ; viser p75 sous 200 ms.
Erreurs communes
- Laisser des handlers lourds ou ignorer l'INP en ne regardant que le LCP. Sur les pages interactives, un mauvais INP fait échouer le signal Core Web Vitals.
Prompt IA
Contexte : site [React / Next.js / autre], type [e-commerce avec panier / formulaire long / app interactive]. Explique l’INP et en quoi il remplace le FID. Liste 3 causes probables d’INP élevé pour ce type de site, puis 3 à 5 corrections concrètes (code splitting, debounce, requestIdleCallback, web workers, réduction des re-renders). Propose un plan de mesure (Lighthouse, RUM) et des cibles (p75 < 200 ms).
SERVICE LIÉ
Passer de la définition à un projet concret.
Création de site internet
Approfondir ce sujet dans le cadre d’un accompagnement adapté à votre contexte.
À LIRE AUSSI
Guides plus complets sur le blog.
QUESTIONS FRÉQUENTES
Aller plus loin sur INP (Interaction to Next Paint).
L’INP mesure le délai entre une action utilisateur (clic, toucher) et l’affichage de la réponse par le navigateur. Un INP > 200 ms donne une sensation de lag. Pour l’améliorer : réduire le JavaScript sur le main thread (code splitting, lazy load), alléger les handlers (debounce), éviter le layout thrashing et déporter les calculs lourds en web workers.
Le FID (First Input Delay) ne mesurait que la première interaction. L’INP (mars 2024) prend en compte toutes les interactions sur la page et reflète mieux la réactivité globale. Google utilise l’INP comme métrique Core Web Vitals à la place du FID. Les deux visent à garantir une interface réactive ; l’INP est plus représentatif de l’expérience réelle.
En lab : Chrome DevTools (onglet Performance, enregistrer une interaction) ou PageSpeed Insights. En production : Chrome User Experience Report (CrUX), ou un outil RUM (Real User Monitoring) qui envoie les métriques d’interaction. Viser un p75 sous 200 ms. Identifiez les pages ou parcours avec le pire INP pour prioriser les optimisations.