INP : la nouvelle métrique Google qui change tout pour les sites interactifs

Le 12 mars 2024, Google a officiellement remplacé FID (First Input Delay) par INP (Interaction to Next Paint) dans les Core Web Vitals. Ce changement a un impact direct sur le SEO de tout site interactif (e-commerce, SaaS, formulaires, menus déroulants). Voici ce qu’il faut savoir.

Pourquoi remplacer FID ?

FID mesurait uniquement le délai de la première interaction : combien de temps entre le clic de l’utilisateur et le moment où le navigateur commence à traiter ce clic.

Limites de FID :

• Ne mesurait que la première interaction
• Ne capturait pas les interactions ultérieures (souvent plus problématiques)
• Médian de 80 % des sites = bonne note FID, même quand l’expérience interactive était médiocre

INP corrige ces limites en mesurant toutes les interactions sur la page, et en retenant la pire (au 98ᵉ percentile). C’est un signal beaucoup plus fidèle de la réactivité réelle d’un site.

Définition précise de l’INP

Selon la documentation officielle web.dev :

L’INP est le temps que met le navigateur à afficher la prochaine frame visuelle après une interaction utilisateur (clic, tap, frappe clavier).

Concrètement, l’INP mesure 3 phases :

1. Input delay : temps entre l’événement utilisateur et le début du traitement par le code
2. Processing time : temps que prend le code JavaScript pour traiter l’événement
3. Presentation delay : temps entre la fin du traitement et le rendu de la nouvelle frame

INP = total de ces 3 phases pour la pire interaction de la page.

Les seuils Google

Mesurés sur de vrais utilisateurs (CrUX), au 75ᵉ percentile des visites :

Statut	Valeur INP
Bon	≤ 200 ms
À améliorer	200 ms – 500 ms
Mauvais	> 500 ms

Selon le Web Almanac 2024, 64 % des sites mobiles sont dans le vert sur INP. Le 36 % restant a du travail.

Quelles interactions sont mesurées

Mesurées :

• Clic (click)
• Tap tactile (pointerdown, pointerup sur mobile)
• Frappe clavier (keydown, keyup)

Pas mesurées :

• Survol (hover)
• Scroll
• Pinch-zoom

Cas limite : les liens

Cliquer sur un lien <a> qui mène à une autre page n’est généralement pas comptabilisé dans l’INP de la page actuelle (sauf si du JS bloque le navigateur avant la navigation).

Quels sites sont à risque

Les sites avec INP problématique partagent souvent ces caractéristiques :

• Single Page Apps lourdes : React, Vue, Angular avec beaucoup de state management
• Sites avec popups, modals, dropdowns non optimisés
• E-commerce avec filtres complexes (recalcul JS à chaque clic)
• Tableaux dynamiques (tri, recherche, pagination en JS)
• Animations CSS lourdes déclenchées sur clic

À l’inverse, les sites statiques (Astro, Eleventy, Hugo) ont des INP excellents car peu de JS côté client.

Causes principales d’un mauvais INP

1. Long tasks JavaScript

Une « long task » est un bloc de JS qui bloque le main thread plus de 50 ms. Quand un clic arrive pendant une long task, l’INP explose.

Causes typiques :

• Boucles for sur de gros tableaux
• Parsing JSON volumineux
• Re-renders React excessifs
• Calculs synchrones (tri, filtres complexes)

2. Event handlers trop gros

Quand l’utilisateur clique, votre code traite l’événement. Si ce traitement prend 300 ms, l’INP sera ≥ 300 ms.

Exemples :

• Mise à jour d’un store global qui re-rend 50 composants
• Appel API synchrone (mauvaise pratique)
• Animation déclenchée qui force un layout

3. Layouts forcés (« forced reflow »)

Lire element.offsetWidth puis modifier le DOM dans la même frame oblige le navigateur à recalculer le layout, bloquant le rendu.

4. Hydratation excessive (frameworks)

Sur Next.js / Nuxt en mode SSR, l’hydratation post-chargement peut prendre 500-1500 ms pendant lesquels les interactions sont très lentes.

→ Astro résout ce problème nativement avec les islands (hydratation sélective).

Comment mesurer son INP

En développement

• Chrome DevTools → Performance : enregistrement avec interactions, le profiler montre les long tasks
• Lighthouse : simule INP sous Lab Mode (limites : pas représentatif des vrais utilisateurs)
• web-vitals.js library : capter les INP des vrais utilisateurs et les envoyer à votre analytics

En production

• Google Search Console → Core Web Vitals : données CrUX (utilisateurs Chrome)
• PageSpeed Insights : combine Lab + CrUX
• CrUX BigQuery : pour les analyses avancées sur des milliers de pages

Optimiser son INP : checklist

1. Réduire le JavaScript côté client

Le plus radical : moins de JS = INP plus bas par défaut. Utiliser un framework comme Astro qui ne charge que le JS strictement nécessaire.

2. Découper les long tasks

Diviser le travail en chunks asynchrones avec requestIdleCallback, scheduler.yield() (nouveau API 2024), ou setTimeout(0) :

async function processLargeArray(items) {
  for (const item of items) {
    await new Promise(r => setTimeout(r, 0));
    process(item);
  }
}

3. Debounce / throttle les inputs fréquents

Pour les recherches en temps réel, formulaires « onChange », filtres :

const search = debounce((query) => fetchResults(query), 300);

4. Web Workers pour les calculs lourds

Décharger le main thread des calculs CPU-intensive (parsing, transformations data) vers des Web Workers.

5. Optimiser les re-renders React/Vue

• React.memo pour les composants purs
• useMemo / useCallback correctement utilisés
• React 19 + le compiler React (sortie 2024) → optimisations automatiques

6. Prioriser les interactions critiques

Utiliser <input type="search" enterkeyhint="search"> pour des hints, et différer le rendu non-critique avec <Suspense>.

7. Éviter les animations transform lourdes sur clic

Préférer les animations CSS courtes (< 200 ms) et utilisez will-change: transform pour pré-allouer les couches GPU.

Cas concret d’optimisation

Avant : un site e-commerce React avec 200 produits, filtres dynamiques. INP médian = 850 ms (rouge).

Optimisations appliquées :

1. Debounce sur les filtres (300 ms)
2. Pagination virtuelle (rendu uniquement des produits visibles)
3. Web Worker pour le tri
4. React.memo sur les ProductCards
5. Lazy-loading des images en dessous du fold

Résultat : INP médian = 180 ms (vert).

→ Effet sur le SEO : passage du statut « Mauvais » à « Bon » dans Search Console, +12 % de trafic organique sur 3 mois (corrélation observée par les sites ayant communiqué leurs résultats sur le sujet).

INP et SEO : impact direct ?

Selon les déclarations de Google, les Core Web Vitals (dont INP) sont un facteur de ranking confirmé depuis 2021 (Page Experience update). Ce n’est pas le facteur le plus puissant — le contenu reste roi — mais à contenu équivalent, un site « Good » sur INP a un avantage sur un site « Poor ».

Par ailleurs, INP est corrélé à la conversion : selon une étude Google sur 100 000 sites, passer de Poor à Good sur INP augmente le taux de conversion de 8-12 % en moyenne.

---

Sources

• Annonce officielle INP remplace FID (Google, mars 2024)
• Documentation INP officielle
• HTTPArchive Web Almanac 2024 — Core Web Vitals
• Optimisation INP par Google

---

Notre optimisation des performances à 150 € HT inclut un audit INP et un plan d’action. Garantie Lighthouse > 90 mobile.