Google l'a officialisé : la vitesse de chargement de votre site fait désormais partie des critères de classement. En 2026, avec les AI Overviews couvrant un quart des pages de résultats, la performance détermine aussi si un robot IA peut lire votre contenu.
Ce que les Core Web Vitals mesurent réellement
Google a confirmé les Core Web Vitals comme signal de classement en mai 2021. Trois métriques comptent : le LCP mesure la vitesse de chargement du contenu principal, l'INP mesure la réactivité de la page aux interactions, et le CLS mesure la stabilité de la mise en page au chargement.
| Métrique | Ce qu'elle mesure | Seuil cible |
|---|---|---|
| LCP — Largest Contentful Paint | Vitesse de chargement du contenu principal | sous 2,5 s |
| INP — Interaction to Next Paint | Réactivité aux interactions | sous 200 ms |
| CLS — Cumulative Layout Shift | Stabilité de la mise en page | sous 0,1 |
Pourquoi la performance est aussi un signal GEO
Les robots IA — dont Googlebot, qui alimente les AI Overviews — timeout sur les serveurs lents et ignorent souvent les pages qui ne se rendent pas assez vite. Un site en première page peut rester invisible à la couche IA si les fondations de performance sont défaillantes.
- HTML rendu côté serveur : beaucoup de robots IA n'exécutent pas JavaScript. Les pages statiques (SSG) ou rendues côté serveur (SSR) sont lisibles ; le contenu SPA client-only peut ne pas l'être.
- First byte rapide : un TTFB sous 200 ms signale un serveur fiable et entre dans les budgets de crawl.
- Pas de blocage au rendu : les polices et scripts qui retardent le premier affichage retardent aussi ce que le robot indexe.
Ce que demande un Lighthouse 90+ réel
Un score Lighthouse 90+ soutenu en production signifie que les décisions de build sont structurellement saines — un proxy qui corrèle étroitement avec les données CWV terrain réelles.
- Retirer les bibliothèques d'animation lourdes (motion/framer, GSAP) du chemin critique — elles ajoutent 80-100 Ko au bundle JavaScript.
- Précharger uniquement les polices visibles au-dessus du pli ; utiliser font-display:optional pour les autres.
- Préférer la génération statique pour les pages de contenu ; garder le rendu serveur pour les routes dynamiques uniquement.
- Définir width et height explicites sur toutes les images pour éliminer le décalage de mise en page.
- Charger les scripts tiers (analytics, widgets chat) de façon asynchrone, après le premier affichage.
La preuve sur nos propres sites
Le site de ZAOURI (zaouri.com) atteint un Lighthouse performance 90+ sur mobile en production — pas en simulation de laboratoire. La même discipline propulse Marrakech Private (100 en SEO Lighthouse) et Marrakech Nightlife (100 SEO, 100 Best Practices). Ces scores sont mesurés en conditions réelles, pas supposés.
FAQ
- Le score Lighthouse impacte-t-il directement mon classement Google ?
- Pas directement. Google utilise les données CWV réelles du rapport Chrome UX (CrUX), pas les scores de laboratoire. Mais un 90+ soutenu en Lighthouse corrèle très étroitement avec de bonnes données CWV terrain, car les mêmes décisions sous-tendent les deux.
- Un site lent existant peut-il être corrigé ?
- Oui. La mise à niveau des performances prend généralement 4 à 8 semaines selon le stack et la portée. Les sites sur frameworks modernes (Next.js, Nuxt) se règlent plus vite que les monolithes legacy.
- La recherche IA se soucie-t-elle de la vitesse indépendamment de Google ?
- Le robot de Perplexity priorise explicitement le HTML propre rendu côté serveur. Googlebot utilise la même logique de budget de crawl pour les AI Overviews que pour l'indexation organique. Vitesse et indexabilité sont le même problème.