Leads générés pour nos clients
282,000
Appelez nous
01 84 25 60 95
INP

L’INP (Interaction to Next Paint) est le troisième Core Web Vital officiel depuis mars 2024, en remplacement du FID (First Input Delay). C’est la métrique la plus complexe des Core Web Vitals — et aussi celle dont les causes et les solutions sont les moins bien comprises. Ce guide expert vous explique précisément ce qu’est l’INP, pourquoi il est difficile à optimiser, et comment l’améliorer concrètement.

🎯 Seuils officiels INP

Bon : < 200 ms | À améliorer : 200 à 500 ms | Médiocre : > 500 ms — Ces seuils sont mesurés sur les données réelles des utilisateurs Chrome (CrUX), pas sur les tests en laboratoire.

Définition précise : qu’est-ce que l’INP ?

L’INP (Interaction to Next Paint) mesure la réactivité globale d’une page à toutes les interactions utilisateur tout au long de la session — pas seulement la première. Il capture le délai entre une interaction de l’utilisateur (clic, tap, saisie clavier) et le moment où le navigateur est capable d’afficher la prochaine image (frame) suite à cette interaction.

La différence clé avec son prédécesseur, le FID : le FID mesurait uniquement la première interaction (premier clic sur la page). L’INP mesure toutes les interactions de la session et rapporte la pire valeur (ou le 98ème percentile) — ce qui est beaucoup plus représentatif de l’expérience globale. Une page peut avoir un excellent FID mais un INP médiocre si les interactions suivantes sont lentes.

Comment l’INP est-il mesuré ?

Pour chaque interaction, 3 phases sont mesurées :

  1. Délai d’entrée (Input delay) : temps entre l’action de l’utilisateur et le début du traitement par le navigateur. Souvent causé par d’autres tâches JavaScript en cours d’exécution sur le thread principal.
  2. Durée de traitement (Processing time) : temps d’exécution des event listeners associés à l’interaction. C’est la phase sur laquelle vous avez le plus de contrôle direct.
  3. Délai de présentation (Presentation delay) : temps entre la fin du traitement et l’affichage visuel de la réponse à l’écran (le prochain frame).

L’INP final est la somme de ces 3 phases pour chaque interaction. Seule la valeur au 98ème percentile est rapportée — ce qui signifie que même si 97 % de vos interactions sont rapides, 1 interaction très lente sur 50 peut dégrader votre INP.

Pourquoi l’INP est plus difficile à optimiser que le LCP

Le LCP se concentre sur le chargement initial de la page — un événement unique facilement identifiable et mesurable. L’INP concerne toutes les interactions tout au long de la session — il peut donc être causé par des centaines de scripts, composants et événements différents. C’est pourquoi l’INP est souvent pire sur les Single Page Applications (SPA) comme React ou Vue, où les interactions déclenchent des re-rendus complexes.

Les principales causes d’un mauvais INP

Les Long Tasks JavaScript

Une Long Task est une tâche JavaScript qui bloque le thread principal pendant plus de 50ms. Pendant qu’une Long Task s’exécute, le navigateur ne peut pas traiter les interactions utilisateur — ce qui crée un Input Delay. Les causes fréquentes : scripts tiers (analytics, chatbots, publicités), bundles JavaScript volumineux, et calculs complexes synchrones.

Les event listeners synchrones lourds

Si votre event listener (la fonction qui s’exécute quand l’utilisateur clique ou tape) contient des opérations coûteuses synchrones (requêtes DOM complexes, calculs, manipulations de nombreux éléments), la durée de traitement sera élevée — et l’INP en souffrira.

Les re-rendus complexes

Dans les frameworks modernes (React, Vue, Angular), une action utilisateur peut déclencher un re-rendu de nombreux composants. Si ce re-rendu touche une grande partie du DOM, la présentation delay sera élevée et l’INP dégradé.

Solutions concrètes pour améliorer l’INP

Décomposer les Long Tasks

Utilisez scheduler.postTask() ou setTimeout(callback, 0) pour découper les tâches JavaScript longues en microtâches plus courtes qui cèdent le contrôle au thread principal entre chaque exécution. Cela libère le navigateur pour traiter les interactions en attente.

Utiliser requestAnimationFrame pour les animations

Les animations CSS sont gérées par le GPU — elles sont toujours préférables aux animations JavaScript synchrones. Pour les animations JS inévitables, utilisez requestAnimationFrame() pour synchroniser les mises à jour visuelles avec le cycle de rendu du navigateur.

Différer les scripts non critiques

Ajoutez les attributs defer ou async sur tous les scripts non critiques (analytics, publicités, chatbots). Ces scripts ne doivent pas s’exécuter avant que la page soit interactive. Utilisez l’outil Lighthouse pour identifier les scripts qui consomment le plus de temps sur le thread principal.

Web Workers pour les calculs intensifs

Les Web Workers permettent d’exécuter des calculs intensifs (traitement de données, algorithmes complexes) dans un thread séparé du thread principal — sans bloquer les interactions utilisateur. C’est la solution ultime pour les applications avec beaucoup de logique JavaScript.

Optimiser les event listeners

Auditez vos event listeners avec le Performance Profiler de Chrome DevTools. Pour chaque listener dont la durée dépasse 50ms : réduisez le nombre d’opérations DOM, utilisez la délégation d’événements (un seul listener sur un parent plutôt qu’un listener par enfant), et mettez en cache les résultats des sélections DOM fréquentes.

Mesurer et surveiller l’INP

Chrome DevTools → onglet Performance → enregistrez une interaction. Les Long Tasks apparaissent en rouge dans la timeline. Le Core Web Vitals Extension (Chrome) affiche l’INP en temps réel lors de votre navigation. La Google Search Console → Expérience de page affiche l’INP réel de vos pages basé sur les données CrUX. Attention : les données CrUX nécessitent un volume suffisant de visites pour être représentatives (généralement 500+ sessions).

INP et SEO : l’impact sur les classements

L’INP est un facteur de classement officiel depuis mars 2024. Un INP ‘Médiocre’ (> 500ms) place votre site dans la catégorie des pages avec une expérience utilisateur insuffisante — ce qui peut pénaliser vos positions sur des marchés concurrentiels où vos concurrents ont un meilleur INP. Consultez notre guide complet sur les Core Web Vitals pour le contexte global.

Foire aux questions sur l'INP

L’INP (Interaction to Next Paint) mesure la réactivité d’une page à toutes les interactions utilisateur tout au long de la session. Il a officiellement remplacé le FID (First Input Delay) en mars 2024 comme troisième Core Web Vital officiel.
Le FID mesurait uniquement le délai avant la première interaction de la page. L’INP mesure toutes les interactions de la session et rapporte la pire valeur. L’INP est bien plus représentatif de l’expérience globale d’une page interactive.
Via Chrome DevTools (Performance Profiler), la Core Web Vitals Extension Chrome (INP en temps réel), Google PageSpeed Insights (données laboratoire et terrain), et Google Search Console → Expérience de page (données CrUX réelles des utilisateurs).
Scripts JavaScript tiers lourds (analytics, chatbots, publicités), Long Tasks qui bloquent le thread principal, re-rendus complexes dans les frameworks (React, Vue), et event listeners synchrones coûteux.
Partiellement. WP Rocket améliore surtout le LCP (cache, CDN, images) et le CLS. Pour l’INP, il aide via la minification et le defer des scripts. Mais les problèmes d’INP avancés nécessitent souvent des optimisations JavaScript plus profondes.
Oui, significativement. Le LCP se concentre sur le chargement initial (un événement unique). L’INP peut être causé par des centaines d’interactions différentes tout au long d’une session. Les SPA (Single Page Applications) sont particulièrement sujettes à de mauvais INP.
Oui, sur les marchés concurrentiels. L’INP est un facteur de classement officiel depuis mars 2024. Un INP ‘Médiocre’ (> 500ms) peut pénaliser vos positions face à des concurrents avec le même niveau de contenu mais de meilleures performances.
top