Pourquoi Google abandonne-t-il le FID au profit de l'INP dans les Core Web Vitals ?

Pourquoi ce changement de métrique maintenant ?

Le First Input Delay (FID) ne mesurait que le délai avant la première interaction utilisateur. C'était insuffisant pour évaluer la réactivité réelle d'une page durant toute la navigation.

L'Interaction to Next Paint (INP) va plus loin : il capte le temps de réponse de chaque interaction — clics, taps, saisies clavier — et retient les valeurs les plus représentatives. Google corrige ainsi un angle mort du FID qui ne capturait qu'un instant fugace.

Que mesure précisément l'INP ?

L'INP enregistre le délai entre une action utilisateur et le moment où le navigateur affiche visuellement le résultat. Concrètement : le temps entre un clic sur un bouton et l'apparition du feedback visuel.

La métrique retient le 98e centile des interactions sur la page. Si 98% de vos utilisateurs attendent moins de 200 ms, vous êtes dans le vert. Au-delà de 500 ms, vous basculez dans le rouge.

Quand cette bascule prend-elle effet ?

Le basculement officiel intervient en mars. À partir de cette date, l'INP remplace totalement le FID dans le calcul des Core Web Vitals et, par ricochet, dans le facteur de classement Page Experience.

Depuis plusieurs mois, Search Console affiche déjà les données INP. C'est le moment de diagnostiquer et corriger avant que ça impacte vos positions.

• L'INP mesure la réactivité globale, pas seulement la première interaction
• Seuil « bon » : moins de 200 ms — seuil « mauvais » : plus de 500 ms
• Les données sont déjà disponibles dans Search Console pour préparer la transition
• Le remplacement du FID par l'INP devient officiel en mars

Cette métrique est-elle vraiment plus pertinente que le FID ?

Soyons honnêtes : le FID était une métrique facile à passer. La plupart des sites affichaient du vert sans effort réel, parce qu'elle ne capturait qu'un instant. L'INP, lui, expose les ralentissements durant toute la session.

C'est une amélioration, oui — mais attention au piège. L'INP peut exploser à cause d'un seul script JS mal optimisé qui bloque le thread principal. Les sites riches en interactions (e-commerce, dashboards, SaaS) vont morfler si les gestionnaires d'événements ne sont pas optimisés.

Les outils actuels mesurent-ils correctement l'INP ?

PageSpeed Insights et Lighthouse affichent l'INP en mode « lab » (simulation), mais les valeurs terrain diffèrent souvent. Les interactions réelles des utilisateurs — avec des connexions variables, des CPU surchargés, des extensions navigateur — génèrent des scores bien plus sévères. [A vérifier]

Search Console reste la source la plus fiable, car elle compile les données RUM (Real User Monitoring). Ne te fie pas uniquement aux tests synthétiques : le terrain est impitoyable.

Dans quels cas l'INP peut-il fausser le diagnostic ?

Les pages avec peu d'interactions (articles de blog statiques, landing pages minimalistes) afficheront naturellement de bons scores INP. L'inverse est vrai pour les interfaces riches : filtres, accordéons, modales, autocomplétion — chaque interaction compte.

Le 98e centile peut masquer des outliers extrêmes. Si 2% de tes utilisateurs patientent 3 secondes, ça ne remonte pas dans le score global — mais ces 2% abandonnent probablement. Surveille les distributions, pas seulement la valeur agrégée.

Que faut-il faire avant mars pour anticiper cette bascule ?

Première étape : ouvre Search Console, section Core Web Vitals, et regarde tes scores INP actuels. Si tu es déjà dans le vert, parfait — mais vérifie les pages critiques (fiches produits, tunnel de conversion).

Si tu vois du orange ou du rouge, commence par identifier les scripts bloquants. Chrome DevTools > Performance > enregistre une session avec interactions. Repère les tâches longues (long tasks) qui dépassent 50 ms.

Quelles optimisations concrètes amélioreront l'INP ?

Découpe ton JavaScript en chunks plus petits. Les frameworks modernes (React, Vue, Next.js) permettent le code-splitting : charge seulement ce qui est nécessaire au moment de l'interaction.

Utilise requestIdleCallback pour reporter les tâches non urgentes. Si un clic déclenche un traitement lourd, déporte-le pour que le feedback visuel apparaisse immédiatement.

Passe en revue tes event listeners. Un écouteur mal optimisé sur un scroll ou un resize peut saturer le thread principal. Debounce, throttle, ou mieux : passe par des Web Workers pour les calculs coûteux.

Comment vérifier que les corrections portent leurs fruits ?

Teste en conditions réelles : throttle ton CPU dans Chrome DevTools (6x slowdown), simule une connexion 3G. L'INP doit rester sous 200 ms même dans ces conditions dégradées.

Surveille Search Console toutes les semaines. Les données RUM mettent 28 jours à se stabiliser après un changement — ne t'attends pas à un effet immédiat.

• Auditer les scores INP actuels dans Search Console
• Identifier les scripts tiers bloquants et les optimiser ou les supprimer
• Découper le JavaScript en chunks et lazy-loader les composants non critiques
• Optimiser les event listeners (debounce, throttle, Web Workers)
• Tester en conditions dégradées (CPU throttling, connexion lente)
• Monitorer l'évolution sur 28 jours minimum pour valider les corrections