Les Core Web Vitals ont changé de fond depuis 2024, exit FID, place à INP (Interaction to Next Paint). Et le changement n’est pas cosmétique : il bouge les classements de manière sensible sur les sites B2B avec interactions complexes (configurateurs, formulaires lourds, dashboards). Voici ce qu’on observe sur les missions Digitalpaca depuis l’introduction.
Les 3 métriques 2026
| Métrique | Seuil “good” | Mesure |
|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5 s | Temps avant que l’élément le plus grand soit peint |
| INP (Interaction to Next Paint) | ≤ 200 ms | Latence du pire input utilisateur sur la session |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | Décalages visuels cumulés (sans interaction) |
INP est la nouveauté qui pèse vraiment en B2B. Contrairement à FID (qui ne mesurait que le premier input et fournissait souvent des chiffres faussement bons), INP regarde le pire input de la session. Sur un site B2B où l’utilisateur clique 10-30 fois (filtres catalogue, validation formulaire, expansion accordéons), n’importe quel handler JS qui bloque 250 ms vous fait passer en “needs improvement”.
INP : impact réel sur les sites B2B
Trois cas typiques de chute INP qu’on a rencontrés en audit :
- Configurateur produit avec calcul de prix en JS bloquant sur changement de variant, INP à 800-1200 ms. Correction : déplacer le calcul en web worker ou debouncer.
- Formulaire de demande de devis avec validation client lourde, INP à 350-600 ms au submit. Correction : alléger la validation et basculer en validation côté serveur après submit.
- Listing catalogue avec re-render complet sur changement de filtre, INP catastrophique. Correction : virtualiser le listing (TanStack Virtual ou équivalent) ou changer d’approche en SSR-only avec query params.
L’erreur classique : garder un thème WordPress lourd qui empile 4-5 plugins JS au chargement. INP devient ingérable sans une refonte du frontal.
Top 10 fautes les plus coûteuses
D’après nos 60+ audits Lighthouse :
- Images non optimisées (JPEG/PNG au lieu de WebP/AVIF)
- Fontes non préchargées (font-display: swap manquant)
- JS tiers chargé sans defer/async (Hotjar, Drift, Calendly…)
- CSS unused massif (Bootstrap entier pour 3 composants)
- iFrames YouTube embed direct (utiliser lite-youtube-embed)
- LCP qui pointe sur une image Unsplash externe non-priorisée
- Layout shifts dus à fontes web sans size-adjust
- Polling JS intervalle court (5 sec) qui bloque le main thread
- Handler onClick lourd sur des grilles longues
- CMS bloquant la TTFB > 600 ms à cause de plugins serveur
Pile technique recommandée 2026
La pile sur laquelle on atteint Lighthouse 95-100 sans optimisation héroïque :
- Astro 6 (statique) ou Next.js App Router (avec ISR sur les pages cataloguées)
- Images locales optimisées par Astro/Next (WebP/AVIF + srcset + width/height)
- Fontes Google via Astro Font Provider ou self-hosted (préchargé, swap, sized)
- Pas de framework JS sur les pages éditoriales (Astro statique)
- Îlots interactifs pour les composants qui en ont besoin (config, form complexe)
- Hosting CDN edge (Netlify, Cloudflare Pages, Vercel)
Sur cette pile, l’INP est généralement < 100 ms par défaut, parce qu’il n’y a quasiment pas de JS à exécuter sur les pages de contenu. C’est la principale raison pour laquelle on a basculé à Astro chez Digitalpaca pour les sites éditoriaux.
Pour aller plus loin sur la stack : Choisir sa stack pour un site B2B en 2026. Pour mesurer où vous en êtes, le service SEO inclut un audit Core Web Vitals en 3 jours.