Pourquoi tout le monde vous parle de Core Web Vitals (et pourquoi c'est mérité)

Depuis 2021, Google intègre la vitesse réelle d'un site dans son algorithme de classement. Pas la vitesse mesurée en laboratoire — la vitesse vécue par les visiteurs. Concrètement : votre Chrome envoie anonymement à Google les performances ressenties sur les sites que vous visitez. Ces données alimentent le rapport CrUX (Chrome User Experience), qui sert de base aux Core Web Vitals.

Trois conséquences directes pour vous :

Bonne nouvelle : ces métriques sont mesurables, objectives, et la plupart des problèmes se résolvent en quelques jours.

Les 3 métriques qui comptent en 2026

Oubliez les dizaines d'indicateurs PageSpeed. Google n'en classe que trois.

LCP Largest Contentful Paint — vitesse d'affichage

Temps qu'il faut pour afficher le plus gros élément visible (image hero, titre principal). C'est ce que le visiteur ressent comme "le site est chargé".

≤ 2,5 s — Bon
2,5 – 4 s — À améliorer
> 4 s — Mauvais
INP Interaction to Next Paint — réactivité

Temps de réponse aux clics, taps et frappes clavier sur toute la session. Google garde la pire interaction. INP a remplacé FID en mars 2024 et il est plus exigeant.

≤ 200 ms — Bon
200 – 500 ms — À améliorer
> 500 ms — Mauvais
CLS Cumulative Layout Shift — stabilité visuelle

Mesure les décalages visuels imprévus. Une bannière qui pousse un bouton au moment où vous cliquez. Une image dont la hauteur n'était pas réservée. Plus le contenu saute, plus le score est mauvais.

≤ 0,1 — Bon
0,1 – 0,25 — À améliorer
> 0,25 — Mauvais

Important : Google calcule la note au 75e percentile sur 28 jours glissants. Traduction : 75 % de vos visiteurs doivent passer les seuils. Si vous testez votre site sur fibre + iPhone récent, vous voyez le meilleur des cas — pas ce que Google note.

Diagnostiquer en 3 minutes : la méthode

Étape 1 — PageSpeed Insights (60 secondes)

Allez sur pagespeed.web.dev, collez votre URL, lancez. Deux blocs s'affichent en haut : "Données réelles des utilisateurs" (CrUX) et "Données de laboratoire". Ne regardez que le premier. C'est celui qui compte.

Trois cas possibles :

Étape 2 — Search Console (60 secondes)

Dans Google Search Console, ouvrez Expérience > Signaux web essentiels. Vous voyez le nombre d'URL classées "Médiocre", "À améliorer", "Bonne", séparées mobile et desktop. Le mobile compte plus que le desktop : 65 % du trafic moyen.

Étape 3 — Identifier la métrique fautive (60 secondes)

Dans le rapport PageSpeed, faites défiler jusqu'à la section "Diagnostic". Les opportunités sont triées par gain potentiel. Notez les 3 premières lignes — elles représentent 80 % du gain à venir.

Les 7 fixes prioritaires (par ordre d'impact)

  1. Optimiser l'image hero (impact LCP énorme)

    L'image en haut de page est presque toujours le LCP. Convertir en WebP ou AVIF, redimensionner aux dimensions réelles d'affichage, utiliser srcset pour servir la bonne taille selon l'écran. Ajouter fetchpriority="high" et un <link rel="preload">. Gain typique : 1 à 2 secondes de LCP.

  2. Précharger les fonts critiques (impact LCP/CLS)

    Les polices web bloquent le rendu et provoquent des décalages quand elles arrivent. Précharger uniquement la font utilisée dans le titre principal, en woff2, avec font-display: swap et size-adjust pour éviter le saut de mise en page.

  3. Différer le JavaScript non critique (impact INP)

    Les scripts d'analytics, de chat, de tracking, de pixels publicitaires, mis en async ou defer. Les modules lourds chargés à la demande. Une page d'accueil ne doit pas charger 1,5 Mo de JavaScript le premier coup.

  4. Réserver l'espace pour images, iframes et bannières (impact CLS)

    Toujours déclarer width et height sur les images. Réserver un placeholder pour les iframes (vidéos YouTube, Maps). Pour les bannières cookies, réserver leur hauteur dès le HTML — pas via JavaScript. Élimine la majorité des CLS.

  5. Activer un cache solide (impact LCP visites répétées)

    Cache navigateur sur tous les assets statiques (1 an pour images, fonts, JS, CSS), cache serveur ou plugin (Cloudflare, Cache-Control headers, WP Rocket). Une visite "warm" doit charger en moins d'une seconde.

  6. Auditer les scripts tiers (impact INP + LCP)

    Live chats, pixels Meta, Hotjar, A/B testing, widgets de réservation, popups d'avis : chaque script tiers ajoute 100 à 400 ms d'INP. Audit brutal : combien servent vraiment ? Les autres dégagent.

  7. Vérifier l'hébergement (impact LCP global)

    Mutualisé bas de gamme = 800 ms de TTFB minimum. Sur un site WordPress, c'est éliminatoire. Hébergement managé (Kinsta, WP Engine, o2switch performance) ou statique (Cloudflare Pages, Netlify) : 50 à 200 ms de TTFB. Différence de 600 ms qui se voit immédiatement.

Combien ça coûte vraiment de corriger un site lent ?

Trois scénarios selon le point de départ :

ScénarioTravailDélaiBudget indicatif
Site WordPress 1-2 ans, propreOptimisations ciblées (images, cache, JS)2 à 4 jours800 € – 1 500 €
Site WordPress 4-7 ans, theme lourdAudit + nettoyage plugins + migration hébergement1 à 2 semaines1 800 € – 3 500 €
Builder bloqué (Wix lent, Squarespace ancien)Refonte technique sur stack moderne3 à 6 semaines3 500 € – 8 000 €

Pour la décision refonte vs optimisation, voir notre article Combien coûte vraiment un site internet en 2026.

Combien de temps avant de voir l'impact SEO ?

Google met à jour les données CrUX sur des fenêtres glissantes de 28 jours. Donc :

Ces gains se cumulent avec un travail SEO de fond. Si vous travaillez aussi votre SEO local pour le Pack Google ou votre référencement IA, l'effet est multiplicatif.

Les pièges classiques (à éviter absolument)

Le piège du "score 95/100"

Beaucoup d'agences vendent un score PageSpeed de 95 en lab. Inutile si le score field reste mauvais. Demandez toujours les vrais chiffres CrUX sur 28 jours, pas une capture d'écran de test.

Le piège du plugin miracle

Aucun plugin ne corrige seul les Core Web Vitals d'un site lourd. Un cache plugin sans optimisation des images, des fonts, du theme et de l'hébergement, c'est rendre le site rapide pour les pages déjà visitées et lent pour les nouveaux visiteurs — précisément ceux qui comptent pour le SEO.

Le piège du A/B test sans contrôle des CWV

Un outil A/B testing peut faire chuter l'INP de 50 ms. Multiplié par 3-4 outils (chat, popup, heatmap, A/B test), vous explosez les seuils. Auditer chaque ajout.

Notre approche : on lit d'abord les vraies données CrUX, on identifie la métrique fautive et la cause racine, on applique les fixes par ordre d'impact, on remesure 28 jours plus tard. Pas de promesses de score, des résultats mesurables.