INP < 200ms : optimiser la nouvelle Core Web Vital 2026

INP < 200ms : optimiser la nouvelle Core Web Vital 2026

Depuis mars 2024, INP (Interaction to Next Paint) a remplacé FID dans les Core Web Vitals. En 2026, c'est la métrique la plus difficile à corriger : 47% des sites échouent en mobile.

Comprendre INP

INP mesure le délai entre une interaction utilisateur (clic, tap, frappe clavier) et la prochaine peinture visuelle.

Seuils Google 2026 :

• Bon : < 200ms
• À améliorer : 200-500ms
• Mauvais : > 500ms

Les 5 causes principales d'INP élevé

#### 1. Long Tasks JavaScript (> 50ms)

Bloque le thread principal. Solution : découper avec scheduler.yield() ou setTimeout(0).

// ❌ Bloque le thread
function processItems(items) {
  items.forEach(item => heavyWork(item));
}

// ✅ Yield au browser
async function processItems(items) {
  for (const item of items) {
    await scheduler.yield();
    heavyWork(item);
  }
}

#### 2. Hydration React/Vue trop lourde

Solution : Islands architecture (Astro, Qwik), Selective Hydration (React 18+), lazy hydration des composants below-the-fold.

#### 3. Third-party scripts synchrones

GTM, Hotjar, Intercom = 800ms+ de blocking. Solution : async/defer + Partytown pour offloader sur worker.

#### 4. CSS-in-JS runtime

styled-components/emotion = recalcul à chaque render. Solution : migrer vers zero-runtime CSS (Vanilla Extract, Tailwind, Linaria).

#### 5. Event handlers non débouncés

Search, scroll, resize = 60+ events/sec. Solution : debounce 100-300ms.

Cas client : SaaS B2B INP 480ms → 140ms

Stack : Next.js 14, 47 third-parties, dashboard interactif.

Actions :

1. Migration GTM → Partytown : -180ms
2. Lazy hydration cards dashboard : -90ms
3. Debounce search input 250ms : -45ms
4. Découpage long tasks chart rendering : -25ms

Résultat : INP p75 480ms → 140ms en 6 semaines. +23% conversions mobile.