INP et SEO : pourquoi l’Interaction to Next Paint est devenu un signal de classement à part entière
Depuis mars 2024, l’INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) comme métrique d’interactivité dans les Core Web Vitals. Ce changement n’est pas anodin : là où le FID ne mesurait que la réactivité à la première interaction d’un utilisateur sur une page, l’INP évalue la réactivité de la page sur l’ensemble de la session — chaque clic, chaque tap, chaque saisie clavier. C’est une mesure beaucoup plus exigeante, et son impact sur le classement Google est direct. Core Web Vitals : guide complet LCP, INP et CLS pour le SEO
Pourtant, l’INP reste la métrique Core Web Vitals la moins bien comprise et la moins souvent optimisée par les équipes SEO et développement. La raison principale : contrairement au LCP qui s’optimise principalement côté serveur et réseau, l’INP dépend du JavaScript exécuté sur la page — un territoire qui appartient traditionnellement aux développeurs front-end, pas aux consultants SEO. Pourquoi la vitesse de rendu côté serveur influence directement votre score LCP sur mobile
Ce que l’INP mesure exactement
L’INP mesure le délai entre une interaction utilisateur (clic, tap, pression d’une touche) et le moment où le navigateur affiche visuellement la réponse à cette interaction. Il ne mesure pas la première interaction uniquement — il collecte l’ensemble des interactions pendant toute la durée de la visite, et retient le pire résultat (en excluant les valeurs aberrantes extrêmes selon un percentile p98).
Le seuil fixé par Google est clair : un INP inférieur à 200 millisecondes est considéré comme bon. Entre 200 et 500 ms, la page nécessite des améliorations. Au-delà de 500 ms, le score est mauvais et peut affecter le classement. En pratique, un utilisateur commence à percevoir consciemment un délai à partir de 100-150 ms — le seuil de 200 ms correspond donc à la limite haute de ce qui reste acceptable perceptivement.
Pourquoi un mauvais INP affecte le classement SEO
Google utilise les données CrUX (Chrome User Experience Report) pour évaluer les Core Web Vitals en conditions réelles — pas les données de laboratoire produites par Lighthouse. Concrètement, cela signifie que si vos visiteurs réels expérimentent un INP dégradé sur mobile, cette information remonte dans les signaux de classement, indépendamment de ce qu’affiche votre rapport Lighthouse en conditions contrôlées.
L’impact sur le classement fonctionne comme un facteur de départage : à contenu, autorité et pertinence équivalents, une page avec un bon INP sera favorisée face à une page avec un INP dégradé. Dans la pratique des SERPs françaises, c’est un avantage qui se manifeste surtout dans les positions 3 à 10 — là où la concurrence est dense et où chaque signal compte.
Les principales causes d’un mauvais score INP
L’INP est dégradé quand le thread principal du navigateur est trop occupé pour traiter rapidement une interaction utilisateur. Les causes les plus fréquentes sont identifiables sans avoir à plonger dans le code source.
Les scripts tiers sont le premier suspect à examiner : analytics, pixels publicitaires, outils de chat, widgets A/B testing, scripts de réseaux sociaux. Ces scripts s’exécutent sur le thread principal et peuvent bloquer le traitement des interactions pendant plusieurs centaines de millisecondes. Sur un site e-commerce qui accumule 8-10 scripts tiers, il n’est pas rare de voir un INP dégradé uniquement à cause de cette charge additionnelle.
Les long tasks JavaScript — tâches qui monopolisent le thread principal pendant plus de 50 ms — empêchent le navigateur de répondre aux interactions utilisateur pendant leur exécution. Un menu de navigation complexe, un filtre de recherche dynamique, ou un composant React mal optimisé peuvent générer des long tasks récurrentes qui dégradent systématiquement l’INP.
Les event handlers lourds attachés aux clics ou aux saisies peuvent aussi dégrader l’INP si leur logique de traitement est trop complexe. Un handler qui déclenche plusieurs appels API synchrones, des calculs DOM intensifs, ou des mises à jour d’état en cascade ralentira directement le rendu de la réponse visuelle.
Comment diagnostiquer un problème d’INP sur son site
La première étape est de consulter le rapport Core Web Vitals dans Google Search Console, qui donne une vue agrégée de l’INP sur l’ensemble des pages du site, segmentée par mobile et desktop. C’est la seule source qui reflète les données terrain réelles de vos visiteurs.
Pour identifier la source précise du problème, Chrome DevTools est l’outil de référence : l’onglet Performance permet d’enregistrer une session d’interaction et d’identifier visuellement les long tasks et les scripts qui occupent le thread principal. L’extension Web Vitals de Chrome permet quant à elle de mesurer l’INP en temps réel pendant la navigation, ce qui est particulièrement utile pour identifier les interactions spécifiques qui dégradent le score.
Pour une approche plus systématique, PageSpeed Insights combine les données de terrain CrUX avec un diagnostic Lighthouse qui identifie les opportunities d’amélioration spécifiques à la page analysée. Notre guide complet sur les outils et méthodes pour diagnostiquer l’INP détaille chaque étape du processus d’audit.
Les leviers d’optimisation les plus efficaces
L’optimisation de l’INP relève principalement du développement front-end, mais les consultants SEO ont un rôle clé à jouer dans la priorisation et le suivi des corrections. Voici les leviers les plus impactants, du plus simple au plus technique.
Différer et limiter les scripts tiers est souvent le levier le plus rapide à mettre en œuvre. Charger les scripts analytics et publicitaires de façon asynchrone, utiliser des façades pour les widgets sociaux (charger l’iframe de YouTube uniquement au clic, par exemple), et auditer régulièrement la liste des scripts tiers actifs permet de réduire significativement la charge sur le thread principal sans modifier le code applicatif.
Découper les long tasks via des techniques comme `scheduler.postTask()` ou `setTimeout` avec délai zéro permet de fragmenter les tâches longues en unités plus courtes, laissant au navigateur des fenêtres pour traiter les interactions utilisateur entre chaque fragment. C’est une intervention technique mais dont l’impact sur l’INP peut être immédiat et mesurable.
Réduire le DOM est un levier souvent sous-estimé : un DOM trop large (plus de 1 500 éléments) ralentit les opérations de style et de layout qui suivent les interactions, dégradant mécaniquement l’INP. Simplifier la structure HTML des pages complexes — notamment les pages catégories e-commerce avec de nombreux produits — améliore l’INP sans toucher au JavaScript.
FAQ — INP et référencement SEO
L’INP affecte-t-il directement le classement Google ?
Oui, l’INP est un facteur de classement officiel depuis mars 2024 en tant que composante des Core Web Vitals. Google utilise les données de terrain réelles collectées via le Chrome User Experience Report (CrUX) pour évaluer l’INP de chaque page. Son impact sur le classement fonctionne comme un facteur de départage : à contenu et autorité équivalents, une page avec un bon INP (sous 200 ms) sera favorisée face à une page avec un INP dégradé (au-dessus de 500 ms). L’effet est particulièrement visible dans les positions 3 à 10 des SERPs, où la concurrence est dense.
Quelle est la différence entre INP et FID en SEO ?
Le FID (First Input Delay), remplacé par l’INP en mars 2024, ne mesurait que le délai de traitement de la toute première interaction d’un utilisateur sur une page. L’INP (Interaction to Next Paint) est beaucoup plus exigeant : il évalue la réactivité de la page sur l’ensemble de la session utilisateur, en retenant le pire résultat parmi toutes les interactions enregistrées. Concrètement, une page pouvait avoir un excellent FID (première interaction rapide) mais un INP dégradé (interactions suivantes lentes) — le passage à l’INP a donc rendu le signal d’interactivité plus représentatif de l’expérience réelle des utilisateurs.
Comment améliorer rapidement son score INP sans modifier son code ?
La première action à fort impact sans modification de code est la réduction des scripts tiers. Auditer les scripts chargés sur les pages problématiques (analytics, pixels publicitaires, widgets de chat, A/B testing) et différer ou supprimer ceux qui ne sont pas critiques peut améliorer significativement l’INP. La deuxième action accessible sans modification de code est la mise en place d’une politique de chargement paresseux (lazy loading) pour les composants non visibles au premier affichage. Ces deux interventions peuvent être réalisées via la configuration d’un plugin de performance WordPress (WP Rocket, Perfmatters) sans toucher au code applicatif.
