Pourquoi Google remplace-t-il FID par INP dans les Core Web Vitals ?

Quelle différence entre FID et INP ?

Le First Input Delay (FID) mesurait uniquement le délai avant le traitement de la première interaction utilisateur — un clic sur un bouton, par exemple. Simple, mais réducteur.

Interaction to Next Paint (INP) va beaucoup plus loin : il évalue toutes les interactions sur une page et mesure le temps nécessaire pour afficher la mise à jour visuelle correspondante. Concrètement, si un utilisateur clique plusieurs fois, scroll, tape dans un formulaire, chaque interaction compte.

Pourquoi ce changement maintenant ?

Google cherche à mieux refléter l'expérience utilisateur réelle. Une page peut avoir un excellent FID parce que la première interaction est rapide, mais des interactions suivantes catastrophiques.

L'INP capture cette nuance — et c'est précisément ce qui frustre ou satisfait un visiteur sur la durée. Google veut pénaliser les sites qui trichent avec une première interaction rapide mais plantent ensuite.

• INP mesure la réactivité globale, pas juste le premier clic
• Seuil recommandé : moins de 200 ms pour être considéré comme « bon »
• Entre 200 et 500 ms : « à améliorer »
• Au-delà de 500 ms : « mauvais »
• Impact SEO confirmé : c'est désormais un signal de classement officiel

Quand ce changement prend-il effet ?

L'intégration d'INP dans les Core Web Vitals est déjà effective. FID n'est plus considéré dans le calcul des signaux d'expérience page.

Si votre PageSpeed Insights ou votre Search Console montrent encore du FID, c'est un vestige — concentrez-vous sur INP. Les données de terrain (CrUX) reflètent déjà cette bascule.

Cette métrique capture-t-elle vraiment l'expérience utilisateur ?

Oui, bien mieux que FID. Sur le terrain, j'ai vu des sites avec un FID impeccable mais des formulaires qui rament. INP aurait détecté ça.

Mais — et c'est un gros « mais » — INP peut être trompeur sur certains types de sites. Une application web complexe avec des interactions lourdes (éditeur en ligne, configurateur produit) aura naturellement un INP plus élevé qu'un blog statique. Google ne contextualise pas assez selon le type de site. [A vérifier] : si Google ajustera les seuils par secteur à l'avenir.

Les observations terrain confirment-elles un impact réel sur le classement ?

Oui et non. Les sites avec un INP catastrophique (> 500 ms) sur mobile ont effectivement perdu du terrain ces derniers mois. Mais attention : corrélation n'est pas causalité.

Sur des requêtes ultra-compétitives, un bon INP peut faire la différence entre position 3 et position 5. Sur des niches peu concurrencées, j'ai vu des sites avec un INP moyen à 400 ms rester en tête — parce que la pertinence du contenu et les backlinks pèsent toujours plus lourd.

Quelles sont les limites de cette métrique ?

L'INP se base sur les données de terrain (CrUX), donc sur des utilisateurs réels. Si votre trafic est faible ou très segmenté (B2B de niche, par exemple), vous n'aurez peut-être pas assez de données pour un score fiable.

Autre limite : l'INP ne distingue pas entre une interaction critique (soumettre un formulaire) et une interaction cosmétique (hover sur un menu). Tout est mis dans le même panier. Un site peut avoir un INP pourri à cause d'un carrousel inutile, alors que son parcours d'achat est fluide. [A vérifier] : si Google affinera le calcul pour pondérer les interactions selon leur importance.

Que faut-il optimiser en priorité pour améliorer l'INP ?

D'abord, identifiez les interactions lentes. Utilisez les outils de développement Chrome (onglet « Performance ») ou Web Vitals extension pour repérer les events qui dépassent 200 ms.

Les coupables habituels : JavaScript bloquant, animations CSS lourdes, recalculs de layout après chaque clic. Si votre site charge 12 scripts tiers (analytics, chat, A/B testing), chacun peut ralentir le thread principal.

Concretement : réduisez le JavaScript inutile, différez ce qui n'est pas critique, utilisez des Web Workers pour déporter les calculs lourds. Et testez — vraiment — sur mobile mid-range, pas sur votre MacBook Pro.

Quelles erreurs éviter absolument ?

Erreur classique : sur-optimiser le Largest Contentful Paint (LCP) en chargeant tout en différé, puis se retrouver avec un INP catastrophique parce que le JavaScript arrive trop tard et bloque les interactions.

Autre piège : ignorer les interactions non-visibles. Un utilisateur peut cliquer avant que votre bouton soit interactif (parce qu'il s'affiche vite mais le JS n'est pas encore attaché). Résultat : aucun retour visuel, frustration, mauvais INP.

• Auditez votre site avec PageSpeed Insights et Chrome User Experience Report
• Identifiez les interactions qui dépassent 200 ms dans les données de terrain
• Réduisez le JavaScript exécuté au chargement (code splitting, lazy loading)
• Limitez les scripts tiers non essentiels ou chargez-les en différé
• Testez sur des appareils réels mid-range, pas seulement en simulation
• Surveillez l'impact après chaque déploiement avec CrUX API ou Search Console
• Optimisez les animations CSS (utilisez transform et opacity, évitez width/height)

Comment vérifier que mon site respecte les seuils INP ?

Utilisez Google Search Console (rapport « Signaux web essentiels ») pour voir si vos URLs sont classées « Bonne », « À améliorer » ou « Mauvaise ». C'est la source officielle — pas un test ponctuel.

Complétez avec PageSpeed Insights pour un diagnostic détaillé. Regardez les « données de terrain » (CrUX) en priorité, pas seulement les « données de labo » (Lighthouse). Lab data est utile pour déboguer, mais Google classe selon les vraies expériences utilisateur.