Les Core Web Vitals, ce sont les trois métriques avec lesquelles Google mesure l'expérience réelle de vos visiteurs : vitesse d'affichage (LCP), réactivité (INP) et stabilité visuelle (CLS). Depuis mars 2024, INP a remplacé FID comme signal d'interactivité, et il est nettement plus exigeant. Place aux seuils officiels, aux pièges de mesure, et à la façon dont on optimise une stack Next.js.
- INP a remplacé FID en mars 2024 comme unique signal d'interactivité, et il est bien plus sévère.
- Seuils officiels : LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 (source : web.dev).
- Google classe sur les données de terrain (CrUX), pas sur vos tests en local.
- L'essentiel se joue sur le JavaScript hydraté et l'image principale.
- Pas besoin de refonte dans la majorité des cas : un audit ciblé suffit.
Les seuils officiels à connaître#
Le changement le plus impactant des dernières années : INP (Interaction to Next Paint) est le seul signal d'interactivité pris en compte depuis mars 2024. FID est officiellement retiré de l'équation.
Les seuils officiels publiés par Google (web.dev) :
Pour être classé « bon », il faut que 75% de vos visites réelles passent le seuil. Viser juste la limite, c'est donc déjà être en danger : nous, on dimensionne pour passer largement en dessous.
Le piège des données de laboratoire
Un score parfait sur PageSpeed en local ne garantit rien. Google classe sur les données de terrain (CrUX), collectées chez vos vrais utilisateurs, sur leurs vrais appareils. Un mobile d'entrée de gamme sur 4G donne des chiffres très différents de votre MacBook en Wi-Fi.
Pourquoi INP change tout#
FID mesurait le délai avant la première interaction. INP mesure le délai de toutes les interactions sur la durée de la session, et retient la pire. C'est beaucoup plus sévère sur les applications React lourdes.
Les principales causes d'un mauvais INP :
- Hydration JS trop lourde
- Event handlers bloquants
- Re-renders inutiles au clic
- Scripts tiers (analytics, chat, ads)
FID vs INP en une phrase
FID, c'était « est-ce que la première porte s'ouvre vite ? ». INP, c'est « est-ce que toutes les portes s'ouvrent vite, pendant toute la visite ? ».
Comment on adapte notre stack Next.js#
1. RSC first pour réduire l'hydration#
Avec Next.js 15+, on pousse les composants en React Server Components autant que possible. Moins de JS hydraté = moins d'INP potentiel.
// RSC : aucun JavaScript envoyé au client
export default function ProductCard({ product }: { product: Product }) {
return (
<article className="card">
<h2>{product.name}</h2>
<p>{product.price}</p>
</article>
)
}2. useTransition pour les interactions non-critiques#
'use client'
import { useTransition } from 'react'
function FilterButton({ label, onFilter }: Props) {
const [isPending, startTransition] = useTransition()
return (
<button
onClick={() => startTransition(() => onFilter(label))}
className={isPending ? 'opacity-70' : ''}
>
{label}
</button>
)
}3. Audit des scripts tiers#
Chaque script tiers peut dégrader l'INP. On charge tout ce qui n'est pas critique en différé :
<Script src="https://analytics.example.com/script.js" strategy="lazyOnload" />Notre ordre de priorité
On traite toujours dans cet ordre : d'abord le JavaScript hydraté (le plus gros levier INP), ensuite l'image LCP, et seulement après les micro-optimisations. Inverser cet ordre fait perdre des jours pour quelques millisecondes.
LCP : les vraies optimisations#
Le LCP vient généralement de trois sources, dans cet ordre de fréquence :
- Image principale :
priority+sizescorrects surnext/image - Fonts :
display: swap+ préchargement de la police critique - TTFB : SSG ou ISR plutôt que SSR pour les pages statiques
<Image src="/hero.webp" alt="Hero" priority sizes="(max-width: 768px) 100vw, 50vw" quality={85} />L'écart de résultats selon l'approche de rendu est net :
| Notre approche (Next.js) | WordPress + plugins | |
|---|---|---|
| LCP mobile | Largement sous les 2.5s, mesuré sur le terrain | Souvent au-dessus de 3s avec un thème chargé |
| INP | Sous le seuil des 200ms grâce au RSC | Pénalisé par l'empilement de scripts |
| Contrôle | Le code est à vous, optimisable ligne à ligne | Dépendant des plugins et du thème |
Notre approche sur les projets#
Sur nos projets Next.js, on vise systématiquement des marges confortables sous les seuils : un LCP nettement sous les 2.5s et un INP sous les 100ms en conditions mobiles, mesurés sur le terrain et pas seulement en laboratoire. Cette exigence se construit dès l'architecture, en lien direct avec le maillage interne et la structure des pages.
Les Core Web Vitals au vert, ce n'est pas un bonus qu'on ajoute à la fin. C'est une contrainte qu'on pose dès l'architecture, avant la première ligne de code.
La vitesse n'est qu'un des signaux d'un site performant : on regarde aussi le parcours, la visibilité et le message dans notre méthode d'audit de site web. Core Web Vitals au vert reste notre baseline sur chaque projet livré. La performance n'est qu'un levier du référencement : l'ensemble est couvert dans notre guide complet du référencement naturel. Si les vôtres sont dans le rouge, c'est précisément ce qu'on diagnostique dans notre audit SEO technique.
Questions fréquentes
Les Core Web Vitals sont-ils un facteur de ranking direct ?
Oui, mais c'est un facteur parmi des centaines. Google les utilise comme signal de qualité de l'expérience de page. À pertinence de contenu égale, un site rapide passe devant un site lent. Les Core Web Vitals ne compensent jamais un mauvais contenu, mais un mauvais score peut vous coûter des positions sur des requêtes concurrentielles.
Quelle est la différence entre FID et INP ?
FID (First Input Delay) ne mesurait que le délai de la toute première interaction. INP (Interaction to Next Paint) mesure la réactivité de toutes les interactions pendant la session, et retient la pire. INP est donc beaucoup plus sévère, en particulier sur les applications React lourdes en JavaScript.
Faut-il refaire tout son site pour passer les nouveaux seuils ?
Rarement. Dans la majorité des cas, on atteint les seuils avec un audit ciblé : réduction du JavaScript hydraté, optimisation de l'image LCP, audit des scripts tiers et mise en cache. Une refonte complète ne se justifie que si l'architecture technique est fondamentalement inadaptée (site lourd à base de plugins, par exemple).
Comment mesurer ses Core Web Vitals soi-même ?
Google PageSpeed Insights donne les données de laboratoire et, si votre site a assez de trafic, les données réelles d'utilisateurs (CrUX). La Search Console affiche le rapport Core Web Vitals sur l'ensemble de vos pages. Pour le développement, l'onglet Performance de Chrome DevTools mesure l'INP en conditions réelles.