Core Web Vitals : pourquoi la vitesse est devenue du SEO

Le changement silencieux de 2021

En mai 2021, Google a intégré officiellement les Core Web Vitals dans son algorithme de classement. Pendant 18 mois avant cette date, le moteur de recherche avait communiqué progressivement pour que les développeurs s’y préparent. Beaucoup ne l’ont pas pris au sérieux. Cinq ans plus tard, l’écart de classement entre les sites qui ont optimisé et ceux qui ne l’ont pas fait est massif.

Les Core Web Vitals ne sont pas un détail technique. C’est devenu un facteur de tri équivalent à la pertinence du contenu sur les requêtes concurrentielles. Sur des mots-clés à forte intention transactionnelle (« agence SEO Genève », « création site internet Suisse »), un site avec un Lighthouse à 70 ne se positionne pas, même avec un contenu objectivement supérieur à celui du site à Lighthouse 95 qui est en première position.

Cet article explique ce que mesurent vraiment les Core Web Vitals, pourquoi Google leur donne autant d’importance, et comment les tenir en 2026.

Les trois métriques qui comptent

Google publie une dizaine de métriques de performance via Lighthouse. Trois seulement font partie des Core Web Vitals officiels en 2026.

Largest Contentful Paint (LCP) mesure le temps de chargement du plus gros élément visible à l’écran lors du premier affichage. C’est généralement une image hero, un titre H1, ou une vidéo. La cible Google : moins de 2,5 secondes. Au-delà de 4 secondes, l’expérience est jugée mauvaise.

Interaction to Next Paint (INP) a remplacé en 2024 l’ancien First Input Delay (FID). INP mesure le délai entre l’interaction utilisateur (clic, tap, frappe clavier) et le moment où la page répond visuellement. Cible : moins de 200 ms. Au-delà de 500 ms, mauvais.

Cumulative Layout Shift (CLS) mesure les décalages visuels de la mise en page pendant le chargement. Vous avez tous vu ça : vous êtes sur le point de cliquer un bouton, une bannière publicitaire se charge en haut, le bouton se déplace, vous cliquez sur autre chose. Cible : score inférieur à 0,1.

Ces trois métriques mesurent ensemble une chose : la qualité réelle de l’expérience utilisateur du chargement et de l’interaction. Pas un score abstrait, pas une moyenne marketing. Le temps réel d’attente.

Pourquoi Google donne autant d’importance à ces métriques

Trois raisons structurelles, dans l’ordre d’importance.

Le mobile a écrasé le desktop. En 2026, 65 % des recherches Google viennent de smartphones. Sur mobile, la moindre lenteur a un impact massif sur l’expérience utilisateur : connexion 4G ou 5G variable, processeur moins puissant, attention courte. Google ne peut pas se permettre de pousser des résultats lents en position 1, sinon les gens utilisent moins Google.

La concurrence des réseaux sociaux et de l’IA. Quand vous cherchez une information, vous avez le choix entre Google, TikTok (45 % des moins de 30 ans), ChatGPT, et autres LLMs avec recherche web. Google n’a plus le monopole. Si son expérience devient frustrante, ses utilisateurs partent. Pousser des sites lents en position 1 dégrade son produit.

La mesure est devenue précise et anonyme. Depuis Chrome User Experience Report (CrUX), Google mesure les vrais temps d’expérience sur des dizaines de millions de sessions réelles, sans cookie individuel. Cette donnée alimente l’algorithme en temps réel. Un site qui dégrade ses Core Web Vitals voit son trafic baisser dans les semaines qui suivent.

Ce qui dégrade le LCP

Le LCP est la métrique la plus liée à la stack technique du site. Cinq causes principales.

Images trop lourdes ou non optimisées. Une image hero de 2 MB en mobile = 2 secondes de chargement minimum sur 4G moyen. La solution : compression WebP ou AVIF (format moderne 30 à 50 % plus léger que JPEG), responsive images avec srcset adapté à chaque viewport, et lazy loading pour ce qui est sous la ligne de pli.

Polices web bloquantes. Une font custom chargée en synchrone bloque le rendu jusqu’à son arrivée. La solution : font-display: swap pour afficher une font fallback immédiatement, ou servir les fonts en local pour éviter la latence d’un tiers.

CSS et JavaScript bloquants en render. Tout fichier dans le <head> sans async ou defer bloque le rendu. La solution : extraire le CSS critique inline dans le HTML, charger le reste en non-bloquant, splitter les bundles JavaScript en chunks logiques.

Temps de réponse élevé. Un serveur qui répond en 500 ms (TTFB élevé) ajoute mécaniquement 500 ms au LCP. La solution : HTTP/2 ou HTTP/3, compression Brotli.

Stack technique inadaptée. WordPress avec 30 plugins, ou une SPA React qui hydrate en client une page éditoriale, plombent inévitablement le LCP. La solution : choisir une stack moderne adaptée au type de page (Astro pour éditorial, Next.js pour interactif, Remix pour transactionnel).

Ce qui dégrade l’INP

L’INP est lié à la quantité de JavaScript qui tourne au moment où l’utilisateur interagit avec la page.

JavaScript over-engineered. Beaucoup de sites chargent 500 KB de JavaScript pour une page qui pourrait fonctionner en 50 KB. Chaque KB additionnel doit être téléchargé, parsé, compilé, exécuté. Sur un mobile mid-range, c’est dramatique.

Long tasks bloquantes. Une fonction JavaScript qui s’exécute en plus de 50 ms bloque le main thread. Si l’utilisateur clique pendant ce temps, l’interaction est retardée. La solution : découper les long tasks (setTimeout, requestIdleCallback, Web Workers pour les calculs lourds).

Frameworks SPA mal utilisés. React, Vue, Svelte sont excellents pour des applications. Pour un site vitrine, ils sont surdimensionnés. Si vous utilisez React pour une page « À propos », vous payez 200 KB de JS pour rien.

Ce qui dégrade le CLS

Le CLS est le moins technique des trois mais le plus visible pour l’utilisateur.

Images sans dimensions déclarées. Une <img> sans width et height définis cause un décalage au chargement. La solution : déclarer systématiquement les dimensions, soit en attributs HTML, soit en CSS aspect-ratio.

Polices web qui changent la mise en page. Le swap d’une font fallback vers la font custom peut décaler tout le texte. La solution : choisir une font fallback aux métriques similaires, ou utiliser size-adjust dans @font-face pour préciser les dimensions.

Contenu injecté en JavaScript après le premier rendu. Bannières cookies, popups, widgets de chat. La solution : réserver l’espace avec un placeholder de la bonne dimension, ou retarder l’injection au moment idéal (interaction utilisateur).

Publicités et embeds tiers. Les iframes YouTube, les widgets Twitter, les bannières publicitaires. La solution : réservation d’espace avec aspect-ratio ou hauteur minimale fixée.

Comment tester votre site

Trois outils à connaître.

PageSpeed Insights (https://pagespeed.web.dev) donne le score Lighthouse mobile et desktop, avec recommandations détaillées. C’est l’outil officiel Google. Test ponctuel, pas de tracking dans le temps.

Search Console (Rapport Core Web Vitals) donne les données réelles de votre site agrégées sur 28 jours, par groupe d’URL. C’est ce que Google utilise effectivement pour vous classer. À surveiller en permanence.

WebPageTest (https://webpagetest.org) donne une analyse détaillée du waterfall de chargement. Excellent pour identifier les bottlenecks spécifiques.

Cible 2026 : Lighthouse mobile > 90 sur PageSpeed Insights, et 75 % des URL en « bon » dans Search Console Core Web Vitals. Au-dessous, votre site est handicapé sur les requêtes concurrentielles.

Ce qu’on fait chez Voren

Tous les sites Voren sont conçus avec les Core Web Vitals comme contrainte architecturale, pas comme un check de fin de projet.

Stack adaptée au type de page. Astro pour les sites éditoriaux et corporate (HTML statique avec hydration partielle), Next.js pour les sites avec forte interactivité, Remix pour les applications transactionnelles. On ne sort jamais une SPA pour un site qui n’en a pas besoin.

Images optimisées par défaut. Compression WebP ou AVIF automatique, responsive images avec srcset, lazy loading sous la ligne de pli.

Polices servies en local avec font-display: swap. Pas de Google Fonts en synchrone, pas de FOIT (Flash of Invisible Text) ni de FOUT visible.

CSS critique inliné. Le CSS de la première vue est dans le <head>, le reste est chargé en non-bloquant.

Lighthouse > 95 visé sur les forfaits Premium et Sur mesure, > 90 sur Essentiel — mesuré au go-live.

La vraie raison qui fait la différence

Beaucoup d’agences traitent les Core Web Vitals comme une optimisation de fin de projet : on développe le site, on lance, on regarde Lighthouse, on patche. Ça marche partiellement mais ça laisse toujours 10 à 20 points sur la table.

La différence se fait dans la conception. Choisir Astro plutôt que WordPress en début de projet vous fait gagner 30 points sur Lighthouse sans aucun effort d’optimisation. Choisir des images compressées WebP plutôt que des PNG vous fait gagner 10 points.

Quand ces choix sont faits en début de projet, votre site arrive en production avec un Lighthouse à 95, sans optimisation laborieuse. Quand ils ne le sont pas, vous passez ensuite des semaines à optimiser après-coup, avec des gains marginaux.

Pour aller plus loin

Si votre site a un Lighthouse en dessous de 75 en mobile, c’est probablement la cause n°1 de votre stagnation SEO. Avant d’investir dans du contenu ou des backlinks, il faut résoudre la base technique.

Demander un audit SEO gratuit : on regarde votre Lighthouse, votre Core Web Vitals, votre stack, et on vous dit ce qu’il faut prioriser, en 7 jours.

Découvrir nos forfaits de création de site : tous nos sites sont livrés avec un score Lighthouse mesuré au go-live (> 90 à > 95 selon le forfait).