Le passage à HTTP/2 de Googlebot a-t-il un impact sur vos Core Web Vitals ?

Google a officiellement confirmé que son bot crawle désormais en HTTP/2 depuis plusieurs années. Beaucoup de professionnels se sont demandé si ce changement technique avait un effet sur les Core Web Vitals, ces métriques de performance qui pèsent dans le classement depuis l'introduction de la Page Experience.

La réponse de John Mueller est sans équivoque : aucun impact. Les métriques de vitesse visibles dans la Search Console ou via CrUX mesurent ce que vivent vos visiteurs réels, pas ce que voit Googlebot.

Pourquoi cette confusion existe-t-elle ?

Le protocole HTTP/2 améliore effectivement la vitesse de chargement côté serveur : multiplexage, compression d'en-têtes, prioritisation des requêtes. Quand un site passe de HTTP/1.1 à HTTP/2, le gain peut être mesurable pour les utilisateurs — surtout sur des pages avec beaucoup de ressources.

Certains ont donc fait le raccourci : si Googlebot crawle plus vite en HTTP/2, peut-être que Google en tiendra compte dans ses rapports de performance. Sauf que non. Les Core Web Vitals proviennent du Chrome User Experience Report (CrUX), qui agrège des données de navigation réelle d'utilisateurs Chrome. Googlebot ne contribue jamais à cette base.

Qu'est-ce que cela signifie pour le crawl budget ?

Le crawl HTTP/2 peut théoriquement améliorer l'efficacité du crawl de Googlebot, surtout sur des sites à forte volumétrie. Le bot récupère les pages plus rapidement, consomme moins de bande passante, peut traiter plus de requêtes simultanées.

Mais — et c'est un mais important — Google a toujours dit que le crawl budget n'est un problème que pour les très gros sites. Pour la majorité des projets, même avec des milliers de pages, ce n'est pas un facteur limitant. Ne compte donc pas sur HTTP/2 côté serveur pour débloquer un problème d'indexation que tu n'as probablement pas.

Les Core Web Vitals mesurent quoi, exactement ?

Les Core Web Vitals se composent de trois métriques : LCP (Largest Contentful Paint), FID (First Input Delay, bientôt remplacé par INP), et CLS (Cumulative Layout Shift). Elles mesurent le temps de chargement du contenu principal, la réactivité aux interactions, et la stabilité visuelle.

Ces mesures proviennent uniquement de navigateurs utilisateurs réels — via CrUX, qui collecte des données de Chrome sur des millions de sites. Googlebot ne charge pas de CSS, ne rend pas de JavaScript côté client comme un navigateur, et ne contribue jamais aux rapports CWV.

• Le crawl HTTP/2 de Googlebot n'a aucun effet sur les Core Web Vitals ni sur aucun rapport de performance utilisateur.
• Les CWV proviennent exclusivement du Chrome User Experience Report (CrUX), basé sur des données de navigation réelle.
• Optimiser HTTP/2 côté serveur peut aider le crawl budget sur de très gros sites, mais ne changera rien à votre score de vitesse.
• Pour améliorer les CWV, il faut optimiser l'expérience utilisateur réelle : temps de réponse serveur, taille des ressources, rendu côté client.
• Googlebot en HTTP/2 peut crawler plus vite, mais cela ne se traduit pas par un avantage de ranking lié à la vitesse.

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, complètement. Les sites qui ont migré vers HTTP/2 côté serveur sans toucher au front-end n'ont constaté aucune variation dans leurs rapports Core Web Vitals. Les gains de performance HTTP/2 sont réels, mais ils profitent aux utilisateurs uniquement si leur navigateur supporte le protocole — et tous les navigateurs modernes le font.

Googlebot bénéficie du protocole pour crawler plus vite, mais cela reste invisible dans les métriques publiques. Si ton LCP stagne à 3,5 secondes, passer ton serveur en HTTP/2 ne le fera pas descendre à 2,0. Il faut optimiser les images, réduire le JavaScript bloquant, améliorer le cache, accélérer le TTFB.

Quelles nuances faut-il apporter ?

Il y a une nuance rarement mentionnée : si ton site n'est pas encore en HTTPS, tu ne peux pas profiter de HTTP/2 — et là, oui, tu as un problème. Non seulement HTTPS est un facteur de ranking direct, mais tu passes à côté de tous les gains de performance du protocole moderne.

Autre point : HTTP/2 améliore la vitesse de chargement des ressources multiples (CSS, JS, images). Si ton site charge 50 requêtes en HTTP/1.1, le passage à HTTP/2 peut réduire le temps total de quelques centaines de millisecondes. Cela peut suffire à faire basculer ton LCP sous le seuil des 2,5 secondes. Mais c'est l'utilisateur qui en profite, pas Googlebot dans ses rapports.

[À vérifier] : Google n'a jamais communiqué de chiffres précis sur l'amélioration du crawl budget liée à HTTP/2. On sait que le bot crawle plus vite, mais impossible de quantifier combien de pages supplémentaires sont indexées grâce à ce gain. Pour la plupart des sites, l'effet reste marginal.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Cette règle s'applique dans tous les cas : les Core Web Vitals mesurent toujours l'expérience utilisateur, jamais celle de Googlebot. Peu importe la taille du site, le secteur d'activité, ou la configuration serveur.

Cependant, il existe des situations où HTTP/2 a un impact indirect sur le SEO. Si ton serveur HTTP/2 est mal configuré (par exemple, prioritisation incorrecte des ressources), tu peux dégrader l'expérience utilisateur — et donc tes CWV. De même, si tu actives HTTP/2 Server Push de manière agressive, tu peux surcharger le navigateur et ralentir le rendu. Dans ces cas, c'est HTTP/2 lui-même qui pose problème, pas son absence d'effet sur Googlebot.

Que faut-il faire concrètement pour améliorer les Core Web Vitals ?

Concentre-toi sur l'expérience utilisateur réelle, pas sur Googlebot. Cela signifie : réduire le temps de réponse serveur (TTFB), optimiser les images (WebP, lazy loading), éliminer le JavaScript bloquant, et stabiliser la mise en page (réserver l'espace pour les publicités et images).

Utilise les outils de mesure terrain : PageSpeed Insights, Lighthouse, et surtout le rapport Core Web Vitals de la Search Console. Ce dernier te montre les URL problématiques selon les données CrUX réelles. Ne te fie pas uniquement aux tests en laboratoire — ce sont les données de navigation réelle qui comptent pour Google.

Quelles erreurs éviter ?

La première erreur : croire qu'activer HTTP/2 sur ton serveur améliorera automatiquement tes CWV. Non. HTTP/2 est un prérequis moderne, mais ce n'est pas une solution magique. Si ton LCP est pourri, c'est probablement à cause d'une image hero de 2 Mo non optimisée, pas d'un protocole HTTP dépassé.

Deuxième erreur : négliger le cache côté serveur et le CDN. HTTP/2 accélère le transfert, mais si chaque requête frappe ta base de données, tu restes lent. Un bon cache (Varnish, Redis, Cloudflare) peut diviser ton TTFB par 10 — bien plus que n'importe quel gain HTTP/2.

Troisième erreur : optimiser pour Googlebot au lieu d'optimiser pour l'utilisateur. Googlebot n'a pas de problème de vitesse. Tes visiteurs, oui. Focalise-toi sur eux.

Comment vérifier que ton site est bien configuré ?

Vérifie d'abord que ton serveur sert bien du HTTPS et que HTTP/2 est activé. Tu peux le tester avec un outil comme HTTP/2 Test ou simplement en inspectant les en-têtes de réponse dans les DevTools de Chrome (onglet Network, colonne Protocol).

Ensuite, analyse tes Core Web Vitals dans la Search Console. Si tu n'as pas assez de trafic pour des données CrUX, utilise PageSpeed Insights et Lighthouse pour identifier les goulots d'étranglement. Concentre-toi sur les URL qui reçoivent le plus de trafic organique — c'est là que l'impact SEO sera le plus fort.

Enfin, surveille ton crawl budget dans les rapports d'exploration de la Search Console. Si tu vois des milliers de pages non crawlées depuis des mois, c'est un signal — mais HTTP/2 ne sera probablement pas la solution. Regarde plutôt ta structure de liens internes, ton sitemap, et tes directives robots.txt.

• Activer HTTPS et HTTP/2 sur ton serveur (nginx, Apache, ou via CDN comme Cloudflare).
• Optimiser les images : format WebP, compression, lazy loading, et dimensions adaptées.
• Réduire le JavaScript bloquant : defer, async, et éliminer les scripts inutiles.
• Améliorer le TTFB : cache serveur, CDN, optimisation base de données.
• Stabiliser la mise en page : réserver l'espace pour les images, publicités, et éléments dynamiques.
• Surveiller les Core Web Vitals dans la Search Console et PageSpeed Insights.