Core Web Vitals 2026 : INP a remplacé FID — ce qui change vraiment pour votre score

Le 12 mars 2024, Google a officiellement remplacé FID (First Input Delay) par INP (Interaction to Next Paint) dans les Core Web Vitals. Si vous avez encore FID dans vos rapports ou dans vos présentations client, mettez à jour vos docs — cette métrique n'existe plus.

Ce changement est plus significatif qu'il n'y paraît. INP est plus difficile à optimiser que FID, et de nombreux sites qui avaient de bons scores FID se retrouvent maintenant avec un INP dans la zone orange ou rouge.

FID vs INP : la différence fondamentale

FID mesurait le délai entre le premier clic d'un utilisateur et la réaction du navigateur. Juste le délai, pas le temps total de traitement. Et seulement la première interaction.

INP mesure la latence de toutes les interactions tout au long de la session — clics, frappes clavier, taps sur mobile — et retient le 98e percentile. Autrement dit, la quasi-pire interaction de toute la session.

C'est une différence fondamentale :

• FID : "Est-ce que la page répond rapidement au premier clic ?"
• INP : "Est-ce que la page reste réactive tout au long de la navigation ?"

Un site avec un excellent FID peut avoir un INP catastrophique si certaines interactions (ouverture d'un menu, filtrage dans un tableau, soumission de formulaire) bloquent le thread principal pendant plus de 500ms.

Les seuils à connaître

Pour le ranking Google, les Core Web Vitals ne sont qu'un facteur parmi d'autres — et pas le plus important. Mais sur des marchés compétitifs où tout le reste est équivalent, un bon INP peut faire la différence. Et surtout, un mauvais INP dégrade l'expérience utilisateur, ce qui impacte indirectement le taux de rebond et le temps passé sur le site.

Pourquoi INP est plus difficile à optimiser que FID

FID était relativement facile à "passer" : il suffisait d'éviter les gros scripts qui bloquaient le thread principal au chargement. Une fois la page chargée, FID ne mesurait plus rien.

INP est actif tout au long de la session. Chaque interaction qui prend plus de 200ms contribue à votre score. Et les interactions problématiques sont souvent dans des fonctionnalités JavaScript complexes qui s'exécutent après le chargement :

• Les filtres dynamiques côté client
• Les animations CSS/JS déclenchées par le scroll
• Les modales et drawers avec des transitions complexes
• Les formulaires avec validation en temps réel
• Les tableaux de données avec tri et pagination client-side

Comment mesurer votre INP

Dans Google Search Console

Rapports > Expérience > Signaux web essentiels. Le rapport distingue mobile et desktop. INP est systématiquement plus problématique sur mobile — les processeurs sont moins puissants, et les interactions tactiles ont une mécanique légèrement différente.

Dans PageSpeed Insights / Lighthouse

PageSpeed affiche l'INP dans la section "Données de terrain" (CrUX — Chrome User Experience Report). Ce sont de vraies données utilisateurs, pas des simulations. Elles n'apparaissent que si votre site a suffisamment de trafic Chrome.

Lighthouse mesure le TBT (Total Blocking Time) comme proxy de l'INP en lab. Ce n'est pas identique, mais un bon TBT corrèle généralement avec un bon INP.

Dans Chrome DevTools

Performance panel > enregistrez une session avec des interactions → cherchez les "Long Tasks" (> 50ms) dans le thread principal. Ce sont vos candidats à l'optimisation.

Les causes les plus communes d'un mauvais INP

1. JavaScript excessif dans les gestionnaires d'événements

// ❌ Handler synchrone lourd — bloque le thread 300ms
button.addEventListener('click', () => {
  const result = heavyComputation(bigDataset) // 300ms
  updateUI(result)
})

// ✅ Décomposition en tâches avec scheduler
button.addEventListener('click', async () => {
  const result = await scheduler.postTask(() => heavyComputation(bigDataset), {
    priority: 'user-visible'
  })
  updateUI(result)
})

2. Rendu synchrone sur des listes longues

// ❌ Render de 500 items en un seul coup — CLS + INP problématiques
function renderList(items) {
  container.innerHTML = items.map(item => `<div>${item.name}</div>`).join('')
}

// ✅ Virtualisation ou chunking
function renderListChunked(items, chunkSize = 50) {
  let index = 0
  function renderChunk() {
    const chunk = items.slice(index, index + chunkSize)
    chunk.forEach(item => {
      const div = document.createElement('div')
      div.textContent = item.name
      container.appendChild(div)
    })
    index += chunkSize
    if (index < items.length) requestAnimationFrame(renderChunk)
  }
  renderChunk()
}

3. Les animations CSS qui déclenchent le layout

Les propriétés qui déclenchent un recalcul de layout complet lors de l'animation (width, height, top, left, margin) génèrent un travail important sur le thread principal.

/* ❌ Animation avec layout thrashing */
.modal-enter {
  transition: height 300ms, width 300ms;
}

/* ✅ Animation sur des propriétés composite-only */
.modal-enter {
  transition: transform 300ms, opacity 300ms;
  /* transform et opacity sont gérés par le GPU, pas le thread principal */
}

4. Les event listeners trop fréquents sans debounce

// ❌ Handler sur chaque keystroke — 50 exécutions par seconde
input.addEventListener('input', () => {
  filterResults(input.value) // requête API ou calcul lourd
})

// ✅ Debounce — attend 200ms d'inactivité avant d'exécuter
input.addEventListener('input', debounce(() => {
  filterResults(input.value)
}, 200))

5. Les imports JavaScript côté client sur des pages SSR

Un problème spécifique aux frameworks comme Next.js : même avec le SSR, l'hydratation côté client peut générer des Long Tasks importantes au moment où l'utilisateur commence à interagir.

// ❌ Import d'une librairie lourde dans un composant client
'use client'
import { HeavyChartLibrary } from 'heavy-chart-library' // 200kb de JS

// ✅ Dynamic import avec lazy loading
'use client'
import dynamic from 'next/dynamic'
const HeavyChartLibrary = dynamic(() => import('heavy-chart-library'), {
  loading: () => <Skeleton />,
  ssr: false,
})

Priorités d'action selon votre situation

Si votre INP est > 500ms (Poor) : Commencez par identifier les Long Tasks dans DevTools sur les interactions les plus fréquentes (navigation principale, bouton CTA, formulaire de recherche). Ce sont elles qui pèsent le plus dans votre 98e percentile.

Si votre INP est entre 200 et 500ms (Needs Improvement) : Auditez vos gestionnaires d'événements. Les handlers qui font des calculs synchrones ou des manipulations DOM massives sont vos premiers coupables.

Si votre INP est < 200ms (Good) : Focalisez-vous sur LCP et CLS — ils ont probablement plus d'impact sur votre ranking que d'optimiser davantage un INP déjà bon.

Ce qui n'a pas changé

LCP et CLS sont inchangés depuis 2021. Les seuils, la mécanique, les facteurs d'optimisation — tout reste identique. Si vous avez déjà investi dans l'optimisation LCP (image hero, TTFB, compression), ce travail reste valide.

La seule chose à retenir : supprimez FID de vos rapports, de vos dashboards, et de vos présentations. Remplacez-le par INP. Et si vous avez des clients qui vous interrogent sur leurs "scores FID" de 2023 — expliquez-leur que cette métrique n'est plus prise en compte.

Pharone mesure INP via PageSpeed Insights API v5 lors de chaque audit. Lancez un audit pour voir vos Core Web Vitals actuels — LCP, INP, CLS — avec des recommandations d'optimisation spécifiques à votre stack.