Core Web Vitals 2026 : maîtriser l'INP pour le SEO

Depuis mars 2024, l'INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) dans les Core Web Vitals de Google. En 2026, cette métrique reste l'un des signaux du Page Experience, au même titre que le LCP et le CLS. Un site dont les interactions répondent en plus de 200 ms sur mobile perd du terrain face à des concurrents plus réactifs, d'autant que la contrainte y est double : un processeur souvent quatre fois moins puissant qu'un ordinateur de bureau et une bande passante limitée. Voici comment mesurer, comprendre et optimiser votre INP.

INP vs FID : pourquoi Google a changé de métrique

Le FID mesurait uniquement le délai entre l'interaction de l'utilisateur et le début du traitement par le thread principal. Un site pouvait donc obtenir un bon FID tout en affichant un résultat visible seulement 500 ms plus tard. L'INP, lui, mesure l'intégralité de l'interaction : de la pression du doigt jusqu'au rendu de la réponse. C'est une métrique beaucoup plus proche de la perception réelle de l'utilisateur.

« Passer d'une métrique de réactivité à une métrique de complétude de l'interaction, c'est une révolution silencieuse mais profonde pour la performance web. »

Les seuils officiels en 2026

• INP inférieur ou égal à 200 ms : bonne performance.
• INP entre 200 ms et 500 ms : à améliorer.
• INP supérieur à 500 ms : mauvaise performance.
• Le 75e percentile des visites mobiles est retenu comme référence.

Ces seuils, identiques au LCP (2,5 s) et au CLS (0,1), sont mesurés en conditions réelles via le rapport CrUX de Google. Les données de laboratoire (Lighthouse) ne servent qu'à diagnostiquer : c'est le trafic réel de vos visiteurs qui compte pour le classement. Si les seuils n'ont pas bougé depuis 2024, le poids de la métrique dans l'évaluation globale du Page Experience, lui, continue de croître.

Les causes techniques d'un mauvais INP

Trois grands coupables : le JavaScript bloquant sur le thread principal, les long tasks de plus de 50 ms, et les événements complexes (saisie, défilement, animations). Les frameworks lourds, le rendu non optimisé et les scripts tiers (analytics, publicité, chatbots) ajoutent chacun des tâches qui saturent le thread unique du navigateur.

1. Mesurer en conditions réelles avec le CrUX et l'API Event Timing, pas seulement avec Lighthouse.
2. Identifier les long tasks via le profiler de Chrome et les attribuer à un script précis.
3. Réduire le JavaScript au strict minimum : lazy loading, code splitting, suppression des dépendances inutiles.
4. Différer les scripts tiers et les charger de façon asynchrone avec une priorité basse.

Les techniques concrètes pour 2026

Le service worker et la mise en cache permettent de servir une coquille d'application instantanée, mais le gain principal vient de la réduction du travail synchrone : découper les traitements lourds en micro-tâches avec setTimeout ou scheduler.yield(), déléguer les calculs à un Web Worker, et pré-répondre aux interactions probables avec une interface optimiste (optimistic UI). Les frameworks modernes comme React 19, avec son compilateur et ses actions serveur, réduisent naturellement le travail exécuté côté client. Côté DOM, évitez le layout thrashing en lisant et en écrivant le DOM dans des phases séparées, et préférez transform et opacity aux propriétés qui déclenchent un reflow. Pour les listes longues, la virtualisation (react-window, FlatList) réduit drastiquement le nombre de nœuds rendus.