Core Web Vitals 2026 : INP a remplacé FID, ce que ça change vraiment

01FID vs INP : la vraie différence

FID ne mesurait que le délai avant la PREMIÈRE interaction utilisateur sur la page. C'était une métrique très indulgente : une fois la page chargée et la première interaction OK, FID restait bon même si toutes les interactions suivantes étaient catastrophiques. INP, lui, mesure le PIRE délai entre toute interaction et la prochaine peinture pendant TOUTE la session de l'utilisateur. C'est donc beaucoup plus représentatif du ressenti réel — et beaucoup plus dur à passer. Sur nos audits, on voit régulièrement des sites avec FID < 100ms (excellent) mais INP > 500ms (mauvais) à cause de gros handlers React mal optimisés.

02Les seuils Google et leur impact SEO

Bon : INP < 200ms. À améliorer : 200-500ms. Mauvais : > 500ms. Pour info complète, LCP < 2.5s, CLS < 0.1, INP < 200ms sont les trois seuils officiels Google. Si un seul est dans le rouge, votre page perd des points dans le classement Google. L'impact n'est pas binaire (votre site ne disparaît pas), mais sur des requêtes concurrentielles, ces signaux peuvent faire la différence entre la 4ème et la 9ème position — donc entre du trafic et pas de trafic.

03Pourquoi l'INP est si dur à passer

L'INP punit principalement les apps lourdes en JavaScript. Quand un utilisateur clique, le browser doit : traiter l'event handler JS, mettre à jour l'état React/Vue, rendre le DOM, peindre l'écran. Si une de ces étapes prend plus de 50ms, on cumule rapidement vers 200ms+. Les pièges classiques : handlers onClick qui font des calculs lourds, useState qui déclenche des re-renders en cascade, scripts tiers (analytics, A/B testing, chat) qui bloquent le main thread, scroll handlers non-throttled qui réagissent à chaque pixel.

04Optimiser l'INP : 3 leviers principaux

Premièrement : RÉDUIRE LE JS. Sur Next.js, utiliser massivement les Server Components (le JS n'est pas envoyé au client). Code splitting agressif (dynamic imports), lazy loading des modales/onglets. Sur WordPress, supprimer les plugins inutiles (chaque plugin = JS chargé). Deuxièmement : ÉVITER LES LONG TASKS. Toute tâche > 50ms bloque l'INP. Découper avec scheduler.yield() (nouvelle API native) ou requestIdleCallback. Troisièmement : OPTIMISER LES HANDLERS. Debounce/throttle sur les inputs, événements scroll passifs, web workers pour les calculs lourds (recherche full-text, parsing JSON 100k+, etc.).

// Découper une tâche longue avec scheduler.yield (Chromium 129+)
async function processLargeList(items) {
  for (const item of items) {
    processItem(item)
    // Laisse le browser respirer entre chaque
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield()
    }
  }
}

// Alternative classique : découper en chunks
function processInChunks(items, chunkSize = 50) {
  let i = 0
  function next() {
    const chunk = items.slice(i, i + chunkSize)
    chunk.forEach(processItem)
    i += chunkSize
    if (i < items.length) requestIdleCallback(next)
  }
  next()
}

05Cas concrets : où on gagne sur WordPress

Sur WordPress, les principaux coupables INP sont : Elementor ou Divi (les page builders sont des desastres INP, on en voit régulièrement à 800-1500ms), plugins de chat live (Intercom, Tawk, Crisp injectent un gros JS), plugins de popup (Optinmonster, Sumo), trackers tiers (Hotjar, FullStory). Solutions concrètes : passer à un thème custom (gain typique 300-500ms d'INP), différer le chargement des chats avec setTimeout 3-5s après load, utiliser le delay JS de WP Rocket sur les scripts non critiques. Sur nos audits Krealabs, on fait régulièrement passer un site WordPress de INP 600ms à INP 150ms uniquement en virant les bloatants.

06Cas concrets : où on gagne sur Next.js / React

Sur React/Next.js, les coupables typiques : composants client énormes (Tableaux 1000+ lignes, dashboards avec 50 graphiques), useEffect qui se déclenchent en cascade, libraries lourdes chargées eagerly (Moment.js, Lodash entier, Charts.js complet). Solutions : passer un maximum en Server Components, virtualiser les listes longues (react-virtuoso), code splitter les libs lourdes (charts.js → import dynamique), remplacer Moment par date-fns ou dayjs (10x plus léger), tree-shaker Lodash (importer juste lodash/debounce, pas tout lodash). React 19 + Server Components a divisé par 2 nos INP moyens sur des dashboards lourds.

07Mesurer en réel : Lab vs Field data

Lighthouse mesure en LAB (conditions contrôlées Chromium headless) — c'est utile mais incomplet. Les vraies données INP qui comptent pour le SEO viennent du FIELD : Chrome User Experience Report (CrUX). Pour y accéder : Google Search Console > Web Vitals (vue agrégée 28 jours), Vercel Analytics (si vous êtes sur Vercel), Speed Insights, ou Real User Monitoring (Sentry Performance, Datadog RUM). Sur les sites à fort trafic, on configure systématiquement Vercel Speed Insights pour avoir le détail par page et identifier les pires offenders.

08L'avenir : nouvelles métriques en préparation

Google travaille déjà sur les prochaines métriques Core Web Vitals : possiblement TTFB (Time To First Byte) plus visible, ou une métrique de "smoothness" sur les animations de scroll. Notre conseil : ne pas optimiser pour des métriques hypothétiques. Optimiser pour l'expérience utilisateur réelle. Un site qui charge vite, réagit instantanément aux clics, et ne saute pas pendant le chargement — c'est ça qu'on vise. Les métriques Google sont une bonne proxy mais pas le but en soi.