Qu’est-ce que l’INP (Interaction to Next Paint) et comment l’améliorer ?

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.

INP et FID : quelle différence pour le SEO et les Core Web Vitals ?

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.

Comment mesurer l’INP sur mon site en production ?

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.

INP (Interaction to Next Paint) — Définition | Websual - Développeur Web & SEO Pau

Définition technique

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 fonctionne ?

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.

L'erreur classique à éviter

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.

Impact business : pourquoi s'en soucier ?

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.

La règle d'or

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.

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).

INP (Interaction to Next Paint)