En mars 2024, Google a officiellement remplacé le FID (First Input Delay) par l’INP (Interaction to Next Paint) comme métrique Core Web Vitals. Ce changement, confirmé comme facteur de classement dans les mises à jour algorithmiques 2025-2026, a redistribué les cartes SEO : des sites qui avaient d’excellents scores FID découvrent des INP catastrophiques. Ce guide explique précisément ce qu’est l’INP, comment le mesurer, pourquoi il est plus pertinent que le FID, et quelles optimisations techniques permettent d’atteindre les seuils « bon » exigés par Google.
FID vs INP : comprendre le changement de paradigme
Le FID (First Input Delay) mesurait uniquement le délai avant la première interaction d’un utilisateur avec la page — généralement un clic sur un bouton ou un lien. Sa faiblesse principale était qu’il ne capturait qu’un instant unique et ignorait la réactivité globale de la page pendant toute la durée de la session. Un site pouvait avoir un excellent FID sur le premier clic mais être catastrophiquement lent sur les interactions suivantes sans que la métrique le détecte.
L’INP (Interaction to Next Paint) est beaucoup plus représentatif de l’expérience réelle. Il mesure le délai entre TOUTES les interactions utilisateur (clics, saisies clavier, taps) et le prochain rendu visuel de la page, puis retient la valeur la plus haute (ou le 98e percentile). Un utilisateur qui remplit un formulaire, navigue entre plusieurs onglets d’un dashboard ou utilise un filtre de recherche va générer des dizaines d’interactions — l’INP capture la pire d’entre elles.
Cette évolution reflète un changement dans l’usage du web : les utilisateurs ne consomment plus passivement les pages, ils interagissent continuellement avec des applications web de plus en plus riches. Un CMS WordPress avec des plugins lourds, un e-commerce avec des filtres dynamiques ou une application SaaS avec des tableaux de bord interactifs sont directement concernés par l’INP d’une façon que le FID ne captait pas.
Seuils INP et impact sur le classement Google
Google définit trois niveaux de performance INP, mesurés au 75e percentile des sessions réelles (Chrome User Experience Report) : « Bon » si l’INP est inférieur à 200 ms, « À améliorer » entre 200 et 500 ms, et « Mauvais » au-delà de 500 ms. Ces seuils sont mesurés sur des appareils réels — un Android milieu de gamme traite JavaScript 4 à 8 fois plus lentement qu’un MacBook Pro, ce qui fait que des sites parfaits en développement local ont des INP catastrophiques sur mobile.
L’impact sur le SEO est réel mais nuancé. Google utilise les Core Web Vitals comme signal de classement dans le cadre du Page Experience update, mais confirme que la pertinence du contenu reste le facteur primordial. Deux sites de contenu équivalent sur une requête concurrentielle verront l’avantage aller à celui avec les meilleurs Vitals. Pour les sites en position 3 à 10 sur des requêtes importantes, améliorer l’INP de « Mauvais » à « Bon » peut apporter 1 à 3 positions supplémentaires.
Les données CrUX (Chrome User Experience Report) accessibles dans Google Search Console montrent la distribution réelle de votre INP sur les appareils de vos visiteurs. Concentrez-vous sur les données mobile, qui représentent souvent 60 à 70 % du trafic et affichent systématiquement des scores inférieurs au desktop. PageSpeed Insights affiche désormais l’INP en priorité dans son rapport, remplaçant le FID dans toutes les interfaces Google.
Anatomie d’une interaction : où se perd la réactivité
Une interaction INP se décompose en trois phases : le délai d’entrée (temps d’attente avant le début du traitement du gestionnaire d’événement), le temps de traitement (exécution des fonctions JavaScript), et le délai de présentation (temps pour que le navigateur calcule le style, le layout et peigne les pixels). L’INP est la somme de ces trois phases. Identifier laquelle est dominante est la première étape de toute optimisation.
Le délai d’entrée est souvent causé par le thread principal JavaScript déjà occupé par une longue tâche au moment où l’utilisateur interagit. Si votre script exécute une fonction de 500 ms pour calculer des données, et que l’utilisateur clique pendant cette exécution, son clic attendra 500 ms dans la file avant d’être traité. Les Long Tasks (tâches JavaScript dépassant 50 ms sur le thread principal) sont les coupables les plus fréquents d’un INP élevé.
Le délai de présentation vient du coût du recalcul de style et du layout. Si votre gestionnaire d’événement modifie une propriété CSS qui force un reflow (width, height, margin, padding, position), le navigateur doit recalculer les positions de tous les éléments affectés avant de peindre. Sur des pages avec des milliers de nœuds DOM, ce reflow peut prendre 50 à 200 ms. Préférez les propriétés qui ne forcent pas de reflow : transform, opacity, visibility.
Outils de mesure et diagnostic INP
Plusieurs outils permettent de mesurer et diagnostiquer l’INP en 2026. Chrome DevTools affiche les Long Tasks dans le panneau Performance et détaille l’attribution des interactions (quel gestionnaire d’événement a déclenché quoi). L’onglet « Performance insights » de Chrome 120+ identifie automatiquement les interactions problématiques et suggère des pistes d’optimisation.
La bibliothèque web-vitals.js (Google) permet de mesurer l’INP en production sur les vrais utilisateurs. Intégrez-la avec un envoi vers Google Analytics 4, Datadog ou Sentry pour visualiser la distribution de votre INP par page, device et type de connexion. Cette donnée terrain est plus précieuse que les scores PageSpeed Insights car elle reflète le comportement réel de votre audience spécifique.
Lighthouse CLI en version 10+ inclut une simulation d’INP, mais les résultats en laboratoire divergent fréquemment des données de terrain car Lighthouse simule une seule interaction prédéfinie sur un appareil virtuel. Utilisez Lighthouse pour le développement et les CI/CD checks, mais basez vos décisions sur les données CrUX et web-vitals.js en production. La combinaison des deux approches donne une image complète.
// Mesurer l'INP avec la Performance Observer API
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === "event") {
const duration = entry.duration;
const interactionType = entry.name;
console.log(`INP candidate: ${duration}ms (${interactionType})`);
// INP bon : <200ms | A ameliorer : 200-500ms | Mauvais : >500ms
if (duration > 200) {
sendToAnalytics({ metric: "inp_candidate", value: duration, type: interactionType });
}
}
}
});
observer.observe({ type: "event", buffered: true, durationThreshold: 16 });Optimisations JavaScript pour améliorer l’INP
La première optimisation est le découpage des Long Tasks en tâches plus courtes en utilisant scheduler.postTask() ou setTimeout(fn, 0) pour céder le contrôle au thread principal entre chaque étape de traitement. Une tâche de 300 ms découpée en 6 tâches de 50 ms génère un INP de 50 ms au lieu de 300 ms car l’utilisateur peut interagir entre les tâches. L’API scheduler.yield() (Chrome 115+) est encore plus précise pour cela.
Différez le chargement des scripts non critiques. Les scripts de tracking, les widgets chat, les scripts de tests A/B et les fonts custom chargés de manière synchrone bloquent le thread principal pendant le démarrage de la page et augmentent le délai d’entrée des premières interactions. Chargez ces scripts avec defer ou async, ou encore mieux, après l’événement DOMContentLoaded via un setTimeout de 1 000 à 3 000 ms pour ne pas pénaliser les interactions early-page.
Optimisez les gestionnaires d’événements pour qu’ils soient aussi légers que possible. Évitez de faire des requêtes réseau synchrones, des calculs complexes ou des manipulations DOM extensives dans un clic handler. Déléguez le travail lourd à un Web Worker (qui tourne sur un thread séparé) et mettez à jour le DOM uniquement quand les données sont prêtes. Pattern recommandé : clic handler léger → state update → Web Worker → résultat → DOM update.
INP et WordPress : cas pratique
WordPress cumule plusieurs facteurs défavorables à l’INP : les plugins ajoutent des scripts JavaScript souvent mal optimisés, les thèmes chargent des bibliothèques complètes (jQuery, Bootstrap) même sur des pages simples, et les builders visuels (Elementor, Divi) génèrent des arbres DOM de plusieurs milliers de nœuds. Un site WordPress typique non optimisé affiche un INP entre 300 et 800 ms sur mobile — dans la zone « À améliorer » à « Mauvais » de Google.
Les actions d’amélioration prioritaires pour WordPress sont : supprimer jQuery de la file de chargement si vous n’en avez pas besoin (WP 6.5+ charge vanillaJS par défaut), désactiver les scripts des plugins inactifs sur les pages où ils ne sont pas utilisés (plugin Asset CleanUp ou WP Rocket), utiliser un cache de page pour servir du HTML statique précompilé sans exécuter de PHP pour chaque requête, et migrer vers un thème léger (GeneratePress, Blocksy, Kadence) si votre thème actuel est lourd.
Mesurez l’INP de vos pages WordPress les plus critiques (homepage, pages produits WooCommerce, formulaires de contact) avec les vraies données CrUX dans Search Console. Concentrez-vous sur les pages qui ont à la fois du trafic important ET un mauvais INP — améliorer l’INP d’une page à 10 visiteurs par mois n’a aucun impact SEO. Le principe de Pareto s’applique : 20 % des pages génèrent 80 % de l’impact SEO total.
LCP et CLS : les autres métriques toujours d’actualité
Bien que l’INP soit le nouveau focus, le LCP (Largest Contentful Paint) et le CLS (Cumulative Layout Shift) restent des métriques Core Web Vitals actives. Le LCP mesure le temps d’affichage du plus grand élément visible (généralement une image hero) : seuil « bon » sous 2,5 secondes. Il est directement impacté par la taille et l’optimisation des images, le Time to First Byte (TTFB) du serveur et le chargement des polices.
Le CLS (seuil « bon » sous 0,1) mesure la stabilité visuelle de la page : les éléments qui « sautent » pendant le chargement parce que des images sans dimensions ou des publicités chargées tardivement repoussent le contenu. La correction principale est de toujours spécifier width et height sur les balises img et de réserver l’espace des publicités et iframes avec des conteneurs à hauteur fixe. WordPress 6.5 ajoute automatiquement les attributs de dimension sur les images block editor.
Une stratégie d’optimisation Core Web Vitals efficace traite les trois métriques simultanément car elles partagent des causes communes : images non optimisées impactent LCP et CLS, JavaScript bloquant impacte LCP et INP, mauvais TTFB impacte LCP et indirectement INP. Un audit complet avec PageSpeed Insights et Web Vitals dans Chrome DevTools révèle souvent que corriger 3 à 5 problèmes fondamentaux améliore les trois métriques simultanément, maximisant le ROI de l’effort d’optimisation.
Plan d’action SEO pour 2026 avec les Core Web Vitals
La stratégie gagnante combine optimisation technique continue et suivi de données terrain. Commencez par un audit baseline de vos Core Web Vitals réels (CrUX dans Search Console) sur vos 10 pages à plus fort trafic organique. Classez-les par impact potentiel (trafic × score actuel) pour prioriser les chantiers qui amélioreront le plus vos positions sur les requêtes importantes.
Mettez en place un monitoring automatisé des Core Web Vitals avec alertes quand un score dépasse les seuils Google. Un déploiement qui dégrade involontairement l’INP d’une page stratégique doit être détecté et corrigé en heures, pas en semaines. Lighthouse CI intégré dans votre pipeline GitHub Actions ou GitLab CI bloque automatiquement les déploiements qui font régresser les scores en dessous des seuils définis.
Enfin, documentez vos optimisations et leur impact mesuré. Un gain de 15 % de trafic organique après une amélioration de l’INP est un argument business fort pour justifier du temps ingénieur sur ces sujets. Les Core Web Vitals ne sont plus une affaire de webmasters techniques : ils impactent directement le chiffre d’affaires des sites e-commerce et la génération de leads des sites B2B, ce qui en fait un investissement justifiable devant n’importe quel comité de direction.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.