Vitesse du site et Core Web Vitals

La vitesse d'un site influence à la fois le budget de crawl que les robots lui consacrent et l'expérience réelle des visiteurs : un site lent se fait explorer moins souvent et moins profondément, et perd des visiteurs avant même qu'ils aient lu le contenu. Les Core Web Vitals sont l'outil standard pour mesurer cette vitesse de façon comparable d'un site à l'autre.

Pourquoi la vitesse influence le crawl budget et l'expérience

Le budget de crawl désigne le nombre de pages qu'un robot est prêt à explorer sur votre site dans un temps donné. Ce budget n'est pas illimité : il dépend en partie de la capacité de votre serveur à répondre rapidement. On observe généralement qu'un site lent ou instable pousse les robots à réduire leur fréquence de passage et le nombre de pages explorées par visite, ce qui ralentit mécaniquement la découverte de nouveau contenu et sa mise à jour dans l'index.

Côté utilisateur, l'effet est plus direct : un temps de chargement long augmente le taux d'abandon avant même l'affichage du contenu. Pour un objectif GEO, cela compte doublement : une page lente a moins de chances d'être explorée par un crawler IA, et moins de chances d'être lue jusqu'au bout par un internaute qui clique depuis une réponse générée.

Les trois métriques Core Web Vitals expliquées

Google a défini trois métriques qui, ensemble, forment les Core Web Vitals :

• LCP (Largest Contentful Paint) : le temps nécessaire pour afficher le plus grand élément visible à l'écran (souvent une image principale ou un titre). Cible généralement recommandée : sous 2,5 secondes.
• INP (Interaction to Next Paint) : le délai entre une interaction de l'utilisateur (clic, appui sur une touche) et la mise à jour visuelle correspondante. Cette métrique a remplacé le FID (First Input Delay) en 2024. Cible généralement recommandée : sous 200 millisecondes.
• CLS (Cumulative Layout Shift) : la mesure des décalages visuels inattendus pendant le chargement (un bouton qui se déplace juste avant que vous cliquiez dessus, par exemple). Cible généralement recommandée : sous 0,1.

Ces seuils sont des repères indicatifs communiqués par Google, pas des règles absolues valables dans tous les contextes : un site avec beaucoup de contenu interactif complexe peut tolérer des marges légèrement différentes selon son usage.

Mesurer avec PageSpeed Insights (et pourquoi pas seulement lui)

pagespeed.web.dev est l'outil de référence pour tester une page précise. Il fournit deux types de données, à ne pas confondre :

• Les données de terrain (Field Data), issues du Chrome User Experience Report, qui reflètent l'expérience réelle de vos visiteurs sur les 28 derniers jours — disponibles uniquement si votre site reçoit suffisamment de trafic Chrome.
• Les données de laboratoire (Lab Data), générées lors d'un test simulé au moment où vous lancez l'analyse — utiles pour diagnostiquer, mais qui peuvent varier d'un test à l'autre selon les conditions réseau simulées.

Le rapport Core Web Vitals de Google Search Console, vu dans une leçon précédente, complète cet outil en donnant une vue agrégée sur l'ensemble du site plutôt que page par page, ce qui aide à prioriser par gabarit plutôt que par URL isolée.

Mobile et desktop : deux réalités distinctes

Les Core Web Vitals sont évalués séparément pour mobile et pour desktop, et les résultats divergent souvent nettement entre les deux. La majorité du trafic web se faisant aujourd'hui sur mobile, et Google utilisant l'indexation « mobile-first » (c'est la version mobile de votre page qui sert de référence pour l'exploration et l'évaluation), il est recommandé de traiter les résultats mobiles comme prioritaires en cas d'arbitrage. Un site qui obtient de bons scores sur desktop mais des scores médiocres sur mobile reste, du point de vue de Google, un site avec un problème de vitesse à corriger.

Les correctifs les plus fréquents et leur ordre de priorité

Dans la plupart des audits, les gains les plus rapides viennent de :

1. Compression et redimensionnement des images : servir des images à la taille réellement affichée, dans un format moderne (WebP ou AVIF), avec chargement différé (lazy loading) pour les images hors écran.
2. Réduction du JavaScript bloquant : différer le chargement des scripts non essentiels au rendu initial (chat en ligne, widgets tiers, pixels publicitaires secondaires).
3. Réservation d'espace pour les éléments dynamiques : définir des dimensions explicites pour les images, vidéos et publicités avant leur chargement, pour éviter les décalages de mise en page (CLS).
4. Mise en cache et CDN : utiliser un réseau de diffusion de contenu pour rapprocher les fichiers statiques des visiteurs, et configurer un cache navigateur adapté.
5. Choix de l'hébergement : un hébergement mutualisé bon marché reste souvent le facteur limitant le plus difficile à corriger sans changer de solution technique.

Suivre l'impact dans le temps

Après chaque correctif significatif, revérifiez avec PageSpeed Insights et surveillez le rapport Core Web Vitals de Search Console dans les semaines suivantes plutôt que dans l'heure qui suit : les données de terrain se basent sur une fenêtre glissante de 28 jours, elles ne réagissent pas instantanément à un changement.

Une fois la vitesse maîtrisée, la base technique du site est globalement posée. Il est temps d'aborder le contrôle de l'accès des robots avec la leçon sur le fichier robots.txt et le contrôle des crawlers IA, puis de comprendre en détail comment un moteur lit une page.