Core Web Vitals 2026 : ce que l'INP change vraiment

Depuis que Google a remplacé le First Input Delay (FID) par l’Interaction to Next Paint (INP) dans son tableau de bord des Core Web Vitals, les équipes SEO et développement font face à un signal plus exigeant — et souvent moins bien compris. Comprendre l’INP, c’est comprendre comment Google mesure réellement la réactivité perçue de vos pages.

FID vs INP : pourquoi le changement compte

Le FID mesurait uniquement le délai avant le premier traitement d’une interaction. C’était un indicateur facile à optimiser en surface : il suffisait de libérer le thread principal au moment du premier clic pour afficher un bon score, même si les interactions suivantes étaient catastrophiques.

L’INP mesure quelque chose de plus honnête : la pire latence parmi toutes les interactions d’une visite (clic, toucher, frappe clavier), avec une tolérance pour quelques outliers. Le seuil de performance est fixé à 200 ms ou moins. Au-delà de 500 ms, la page est classée “pauvre”.

Ce changement pénalise les pages qui paraissaient performantes sur le FID mais accumulaient des jank sur chaque micro-interaction : ouvertures de menus, filtres de recherche, accordéons, formulaires dynamiques.

Comment l’INP est mesuré en pratique

Un score INP reflète le 98e percentile des interactions enregistrées dans les données de terrain (CrUX — Chrome User Experience Report). Cela signifie que même si 97 % de vos interactions sont rapides, une mauvaise interaction récurrente peut faire basculer votre score dans le rouge.

Trois phases composent chaque interaction :

1. Input delay — le délai entre l’action de l’utilisateur et le début du traitement par le navigateur. Causé par des tâches longues bloquant le thread principal.
2. Processing time — le temps d’exécution des event listeners JavaScript liés à l’interaction.
3. Presentation delay — le temps nécessaire au navigateur pour peindre le résultat visible à l’écran (layout, paint, composite).

Un site peut avoir un faible input delay mais un processing time élevé à cause d’un gestionnaire d’événements trop lourd. C’est là que la plupart des problèmes réels se cachent.

Diagnostiquer vos problèmes d’INP

Outils de terrain (données réelles)

• CrUX Dashboard (looker.com/explore/chrome-ux-report) : données agrégées 28 jours, segmentées par type d’appareil.
• PageSpeed Insights : score CrUX par URL avec distribution des percentiles.
• Google Search Console (rapport Expérience page) : alertes par groupe d’URL si plusieurs pages présentent un score médiocre.

Outils de laboratoire (reproduction locale)

• Chrome DevTools → Performance : enregistrez une interaction, identifiez les tâches longues dans la timeline. Cherchez les blocs rouge/orange sur le thread principal.
• Web Vitals extension : affiche l’INP en temps réel dans le badge de l’extension pendant votre navigation.
• PerformanceObserver + event timing : implémentez un monitoring maison pour capturer les interactions lentes en production.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 200) {
      console.warn('INP candidate:', entry.name, entry.duration.toFixed(0) + 'ms');
    }
  }
});
observer.observe({ type: 'event', buffered: true, durationThreshold: 16 });

Corriger les latences d’interaction

1. Réduire l’input delay : fragmenter les tâches longues

La cause numéro un d’un input delay élevé est une tâche JavaScript monopolisant le thread principal pendant plus de 50 ms. Le navigateur ne peut pas répondre à une interaction pendant l’exécution d’une longue tâche.

La solution : fragmenter les tâches longues avec scheduler.yield() (Chrome 115+) ou setTimeout(fn, 0) en attendant une meilleure compatibilité.

async function traiterGrandeListe(items) {
  for (let i = 0; i < items.length; i++) {
    traiterItem(items[i]);
    if (i % 50 === 0) await scheduler.yield(); // libère le thread
  }
}

2. Alléger les gestionnaires d’événements

Chaque callback onClick ou onChange qui déclenche des mises à jour d’état complexes allonge le processing time. Principes à appliquer :

• Déférer le travail non critique : montrez d’abord le feedback visuel, traitez la logique métier ensuite.
• Éviter les re-renders en cascade dans les frameworks (React, Vue) : regroupez les mises à jour d’état.
• Supprimer les listeners inutiles : n’attachez des handlers qu’aux éléments qui en ont besoin.

3. Réduire le presentation delay

Si votre interaction déclenche un layout shift important (modification de largeur, hauteur, position d’éléments), le navigateur doit recalculer l’ensemble du layout avant de peindre. Pour minimiser le presentation delay :

• Contenez les changements de layout dans des sous-arbres DOM isolés (contain: layout).
• Préférez les transformations CSS (transform, opacity) aux propriétés qui déclenchent un reflow (width, height, top).
• Utilisez content-visibility: auto pour les sections hors écran.

Un workflow d’amélioration en 4 étapes

1. Identifier les pages avec un INP > 200 ms via CrUX Dashboard et PSI.
2. Reproduire l’interaction problématique en DevTools et enregistrer le profil de performance.
3. Isoler la phase dominante : input delay, processing time ou presentation delay.
4. Corriger et mesurer en terrain réel sur 28 jours via CrUX (les données de laboratoire ne remplacent pas les données terrain pour l’INP).

L’INP est un signal qui récompense la cohérence de l’expérience sur l’ensemble de la page, pas la performance d’un seul chargement. Intégrer ce suivi à votre workflow de développement — au même titre que les revues de code — est la seule façon d’en maintenir durablement un bon score.