HTTP/2 et HTTP/3 : impact réel sur le crawl et le SEO

Googlebot supporte HTTP/2 depuis novembre 2020 et crawle déjà plus de 50 % du web via ce protocole. En pratique, un site e-commerce de 25 000 pages servi en HTTP/1.1 impose au crawler d'ouvrir des dizaines de connexions TCP séquentielles là où HTTP/2 multiplexa les requêtes sur une seule. La différence n'est pas théorique : elle se mesure en pages crawlées par seconde, en TTFB perçu par Googlebot, et in fine en vitesse d'indexation.

HTTP/1.1, HTTP/2, HTTP/3 : ce qui change pour un crawler

Le goulot HTTP/1.1

HTTP/1.1 impose une contrainte dure : une requête par connexion TCP à la fois (ou au mieux, du pipelining rarement implémenté). Les navigateurs contournent le problème en ouvrant 6 connexions parallèles par domaine. Googlebot fait pareil, mais avec des limites imposées côté Google pour ne pas surcharger les serveurs.

Sur un site de 25 000 pages produit, chaque connexion nécessite un handshake TCP (1 RTT) puis un handshake TLS 1.2 (2 RTT supplémentaires). Pour un serveur hébergé à 40 ms de RTT des datacenters Google, chaque nouvelle connexion coûte ~120 ms avant le premier octet utile. Multipliez par le nombre de connexions nécessaires pour explorer un catalogue dense : le crawl budget temporel s'effondre.

Le multiplexing HTTP/2

HTTP/2 résout le head-of-line blocking au niveau applicatif. Une seule connexion TCP transporte des centaines de streams concurrents. Googlebot peut ainsi requêter simultanément le HTML d'une page catégorie, ses images, son CSS critique — tout via la même connexion TLS déjà établie.

Le gain concret pour le crawl :

• Moins de connexions ouvertes = moins de charge serveur = Google peut augmenter le crawl rate sans déclencher de 503.
• Compression HPACK des headers HTTP. Sur un site où chaque réponse transporte 2 Ko de headers (cookies, CSP, cache-control), HPACK réduit cet overhead à quelques dizaines d'octets après la première requête.
• Server Push (désormais déprécié dans Chrome, mais toujours dans la spec) permettait d'envoyer des ressources critiques sans attendre la requête. En pratique, peu utilisé et retiré de la plupart des implémentations.

HTTP/3 et QUIC : la fin du head-of-line TCP

HTTP/3 remplace TCP par QUIC (basé sur UDP). Le gain fondamental : la perte d'un paquet sur un stream ne bloque plus les autres streams. En HTTP/2 sur TCP, un seul paquet perdu stoppe tous les streams multiplexés le temps de la retransmission — c'est le head-of-line blocking de la couche transport.

Pour un crawl à grande échelle, HTTP/3 apporte aussi le 0-RTT connection resumption. Googlebot qui revient crawler votre site 10 minutes après sa dernière visite peut reprendre la connexion QUIC sans handshake. Le premier octet de la première requête arrive après 0 round-trip.

Google a confirmé en 2022 que Googlebot commence à supporter HTTP/3 de façon expérimentale. Le support n'est pas universel côté crawler, mais la trajectoire est claire : QUIC est le transport par défaut de Chrome depuis 2020, et Googlebot suit les capacités de Chrome.

Configurer HTTP/2 et HTTP/3 sur vos serveurs

Nginx : HTTP/2 et HTTP/3

Depuis Nginx 1.25.0, HTTP/3 est intégré nativement (sans module tiers). Voici une configuration production pour un site e-commerce :

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;

    server_name www.boutique-luminaires.fr;

    ssl_certificate     /etc/ssl/certs/boutique-luminaires.fr.pem;
    ssl_certificate_key /etc/ssl/private/boutique-luminaires.fr.key;

    # TLS 1.3 obligatoire pour HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # Header Alt-Svc pour annoncer HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # QUIC transport parameters
    quic_retry on;
    ssl_early_data on;

    # Optimisation HPACK / QPACK
    http2_max_concurrent_streams 128;

    location / {
        proxy_pass http://backend_nextjs;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }

    # Assets statiques avec cache long
    location ~* \.(js|css|webp|avif|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        add_header Alt-Svc 'h3=":443"; ma=86400' always;
    }
}

Points critiques dans cette config :

• listen 443 quic reuseport : active QUIC. Le flag reuseport est indispensable en production pour répartir les paquets UDP entre les workers Nginx.
• add_header Alt-Svc : sans ce header, aucun client ne découvrira que votre serveur supporte HTTP/3. Les navigateurs (et potentiellement Googlebot) font d'abord une connexion HTTP/2, lisent le header Alt-Svc, puis basculent en QUIC lors des requêtes suivantes.
• quic_retry on : active la validation d'adresse QUIC, indispensable contre les attaques par amplification UDP.
• ssl_early_data on : active le 0-RTT TLS 1.3. Attention au risque de replay attack sur les requêtes non-idempotentes. Pour un site principalement en lecture (crawl SEO), le risque est négligeable.

Apache : HTTP/2

Apache supporte HTTP/2 via mod_http2 depuis la version 2.4.17. HTTP/3 n'est pas supporté nativement — il faut un reverse proxy (Nginx, Caddy, ou un CDN comme Cloudflare).

# /etc/apache2/conf-available/http2.conf
Protocols h2 h2c http/1.1

# Augmenter les streams concurrents (défaut: 100)
H2MaxSessionStreams 128

# Taille de la fenêtre initiale (optimisation pour gros payloads)
H2WindowSize 1048576

# Désactiver le push (déprécié)
H2Push off

<VirtualHost *:443>
    ServerName www.boutique-luminaires.fr
    SSLEngine on
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

    # Si un CDN gère HTTP/3 en amont
    Header always set Alt-Svc 'h3=":443"; ma=86400'
</VirtualHost>

Vérification immédiate

Après déploiement, vérifiez que le protocole est bien actif :

# Vérifier HTTP/2
curl -sI --http2 https://www.boutique-luminaires.fr | grep -i "^HTTP/"
# Attendu : HTTP/2 200

# Vérifier HTTP/3 (curl 7.66+ avec support QUIC)
curl -sI --http3 https://www.boutique-luminaires.fr | grep -i "^HTTP/"
# Attendu : HTTP/3 200

# Vérifier le header Alt-Svc
curl -sI https://www.boutique-luminaires.fr | grep -i "alt-svc"
# Attendu : alt-svc: h3=":443"; ma=86400

# Test avec openssl pour valider TLS 1.3
openssl s_client -connect www.boutique-luminaires.fr:443 -tls1_3 < /dev/null 2>&1 | grep "Protocol"
# Attendu : Protocol  : TLSv1.3

Impact mesuré sur le crawl : scénario réel

Le contexte

Un site de mobilier design — appelons-le MaisonModerne.fr — gère 18 000 pages : 12 000 fiches produit, 400 pages catégorie, 2 000 pages de contenu éditorial, et le reste en pages techniques (CGV, filtres à facettes maîtrisés). Le site tourne sur Next.js avec SSR, derrière un Nginx en reverse proxy, hébergé sur des instances OVH à Gravelines.

En janvier, l'infrastructure servait tout en HTTP/1.1. Le passage en HTTP/2 a été fait en février, puis HTTP/3 activé via Cloudflare en mars.

Les métriques avant/après

Crawl stats (Google Search Console > Paramètres > Statistiques d'exploration) :

Métrique	HTTP/1.1 (janvier)	HTTP/2 (février)	HTTP/3 via CDN (mars)
Pages crawlées/jour (moyenne)	3 200	4 800	5 400
Temps de réponse moyen (ms)	620	380	310
Requêtes de crawl/jour	4 100	5 600	6 200
Erreurs serveur (5xx) / jour	12	3	1

Le passage HTTP/1.1 → HTTP/2 a produit l'amélioration la plus significative : +50 % de pages crawlées par jour et -39 % de temps de réponse moyen. L'ajout de HTTP/3 a apporté un gain incrémental de +12 % supplémentaire sur le volume de crawl.

L'explication technique est directe. En HTTP/1.1, chaque requête de crawl nécessitait potentiellement une nouvelle connexion TCP+TLS. Le serveur Nginx plafonnait à ~200 connexions concurrentes avant de commencer à queuer. Googlebot, respectant le crawl rate limit, se limitait à ~6 connexions simultanées. En HTTP/2, ces 6 connexions transportent chacune des dizaines de requêtes multiplexées — le throughput explose sans augmentation de charge serveur.

Impact sur l'indexation

Les nouvelles fiches produit, qui prenaient 8 à 14 jours pour apparaître dans l'index, sont passées à 3-5 jours. Ce n'est pas uniquement grâce au protocole : le crawl plus rapide signifie que Google découvre les nouvelles URLs plus tôt via le sitemap et les liens internes. C'est un effet indirect mais mesurable. Le crawl budget, souvent considéré comme un mythe sur les petits sites, devient un vrai levier quand vous dépassez 10 000 pages.

Les erreurs 5xx réduites ont aussi un impact : chaque 503 pendant le crawl gaspille une requête et envoie un signal négatif sur la fiabilité du serveur. Google peut réduire le crawl rate d'un site qui retourne régulièrement des erreurs. La réduction des connexions TCP grâce au multiplexing a directement diminué la pression sur le serveur et les erreurs associées.

HTTP/2 Server Push est mort — et c'est tant mieux

Chrome a retiré le support de HTTP/2 Server Push en Chrome 106 (septembre 2022). La fonctionnalité, séduisante en théorie (envoyer le CSS critique avant même que le navigateur ne le demande), posait des problèmes insolubles en pratique :

• Pas de moyen fiable de savoir si le client a déjà la ressource en cache. Résultat : push systématique = gaspillage de bande passante.
• Interactions complexes avec les CDN qui devaient relayer le push.
• Les alternatives (<link rel="preload">, Early Hints 103) résolvent le même problème plus proprement.

Early Hints (103) : le remplacement fonctionnel

HTTP 103 Early Hints est supporté par Chrome, et Cloudflare le propose nativement. Le principe : le serveur envoie un premier paquet de réponse avec les headers Link avant même d'avoir fini de générer la réponse finale.

# Nginx : Early Hints pour les ressources critiques
location / {
    # Envoie les Early Hints avant de proxy vers le backend
    add_header Link "</css/critical.css>; rel=preload; as=style" early;
    add_header Link "</fonts/inter-v12-latin-700.woff2>; rel=preload; as=font; crossorigin" early;

    proxy_pass http://backend_nextjs;
}

En termes de SEO, Early Hints améliore le LCP en permettant au navigateur de commencer à télécharger CSS et fonts pendant que le serveur génère le HTML. Sur MaisonModerne.fr, le LCP médian des pages catégorie est passé de 2,8 s à 2,1 s après activation des Early Hints pour le CSS critique et la police principale. Cela rejoint directement les enjeux de chargement des fonts et d'optimisation des images.

Diagnostiquer le protocole utilisé par Googlebot

Vérifier dans les logs serveur

La méthode la plus fiable : analyser les logs d'accès de votre serveur. Nginx enregistre le protocole via la variable $server_protocol :

# Format de log enrichi avec le protocole
log_format seo_analysis '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_user_agent" '
                        'proto=$server_protocol '
                        'rt=$request_time '
                        'uct=$upstream_connect_time';

access_log /var/log/nginx/access_seo.log seo_analysis;

Puis filtrez les requêtes Googlebot :

# Identifier le protocole utilisé par Googlebot
grep "Googlebot" /var/log/nginx/access_seo.log | \
  grep -oP 'proto=\K[^ ]+' | \
  sort | uniq -c | sort -rn

# Résultat typique en 2026 :
#   8432 HTTP/2.0
#   2156 HTTP/1.1
#     87 HTTP/3.0

# Temps de réponse moyen par protocole pour Googlebot
for proto in "HTTP/1.1" "HTTP/2.0" "HTTP/3.0"; do
  avg=$(grep "Googlebot" /var/log/nginx/access_seo.log | \
    grep "proto=$proto" | \
    grep -oP 'rt=\K[0-9.]+' | \
    awk '{sum+=$1; n++} END {if(n>0) printf "%.3f", sum/n}')
  echo "$proto : ${avg}s avg response time"
done

Sur un site correctement configuré en 2026, vous verrez la majorité du crawl en HTTP/2. Si tout reste en HTTP/1.1, votre configuration TLS ou votre ALPN (Application-Layer Protocol Negotiation) est probablement cassée.

Chrome DevTools : protocole colonne par colonne

Dans l'onglet Network de Chrome DevTools, ajoutez la colonne "Protocol" (clic droit sur les headers de colonnes). Vous verrez h2 ou h3 à côté de chaque requête. Utile pour vérifier rapidement qu'une page spécifique est bien servie en HTTP/2+.

Screaming Frog et la détection de protocole

Screaming Frog n'affiche pas directement le protocole HTTP utilisé (il crawle en HTTP/1.1 par défaut dans ses connexions). Pour valider le support HTTP/2 à grande échelle, combinez avec un script :

# Vérifier HTTP/2 sur toutes les URLs d'un export Screaming Frog
while IFS= read -r url; do
  proto=$(curl -sI --http2 -o /dev/null -w '%{http_version}' "$url" 2>/dev/null)
  echo "$proto $url"
done < urls_from_screaming_frog.txt | grep "^1.1" > urls_still_http1.txt

echo "URLs encore en HTTP/1.1 :"
wc -l urls_still_http1.txt

Les edge cases et pièges techniques

CDN et protocole de bout en bout

Un piège classique : votre CDN (Cloudflare, Fastly, AWS CloudFront) sert HTTP/3 au visiteur, mais communique avec votre origin en HTTP/1.1. Googlebot se connecte au CDN en HTTP/2 ou HTTP/3, mais le temps de réponse reste limité par la connexion CDN→origin.

Pour maximiser le gain, assurez-vous que la connexion origin supporte aussi HTTP/2. Sur Cloudflare, vérifiez que "HTTP/2 to Origin" est activé dans les paramètres réseau. Sur CloudFront, configurez l'origin protocol policy sur "HTTPS only" avec une origin qui supporte ALPN h2.

Firewall et UDP pour HTTP/3

HTTP/3 utilise UDP sur le port 443. Si votre infrastructure est derrière un firewall qui bloque UDP:443 (cas fréquent en entreprise ou sur certains hébergeurs), HTTP/3 sera silencieusement indisponible. Les clients retomberont sur HTTP/2 via TCP. Pas de dégradation visible, mais pas de gain non plus.

Vérifiez :

# Tester si UDP 443 est ouvert depuis l'extérieur
# (depuis un serveur externe)
echo -ne '\x00' | nc -u -w2 www.boutique-luminaires.fr 443 && echo "UDP open" || echo "UDP blocked"

HSTS et le coût du premier chargement

HTTP/2 et HTTP/3 nécessitent HTTPS. Si votre site n'a pas encore de header HSTS (Strict-Transport-Security), chaque première visite commence par une requête HTTP, suivie d'une redirection 301 vers HTTPS. Ce round-trip supplémentaire est particulièrement coûteux en HTTP/3 où le 0-RTT n'est possible qu'en HTTPS direct.

Cela rejoint directement les enjeux de HTTPS et SEO et de chaînes de redirections. Ajoutez HSTS avec preloading pour éliminer ce coût :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Cas où HTTP/2 n'apporte presque rien

Sur un site de 200 pages avec un temps de réponse serveur de 80 ms, le gain du multiplexing est marginal. Googlebot crawlera la totalité du site en quelques minutes quel que soit le protocole. Le gain de HTTP/2/3 se manifeste principalement sur :

• Les sites avec un grand nombre de pages (>5 000) où le crawl budget temporel compte.
• Les sites avec un TTFB élevé (>500 ms) où la réduction des handshakes est significative.
• Les sites avec beaucoup de ressources par page (e-commerce avec de nombreuses images produit) où le multiplexing réduit la cascade de chargement.

Mesurer l'impact sur les Core Web Vitals

HTTP/2 et HTTP/3 n'améliorent pas directement vos Core Web Vitals dans le sens où ce n'est pas un facteur de ranking isolé. Mais la réduction de latence impacte mécaniquement le LCP (le navigateur reçoit le HTML et les ressources critiques plus vite), l'INP (les scripts se chargent plus tôt, le main thread est prêt plus vite) et le CLS (les fonts et images avec dimensions arrivent avant que le layout ne soit peint).

Le multiplexing HTTP/2 élimine aussi la pratique du domain sharding (répartir les assets sur cdn1.example.com, cdn2.example.com pour contourner la limite de 6 connexions HTTP/1.1). Si vous faites encore du domain sharding, HTTP/2 le rend contre-productif : vous forcez l'ouverture de connexions TLS séparées par domaine alors qu'une seule connexion multiplexée serait plus efficace.

Supprimez le sharding, consolidez vos assets sur un seul domaine (ou votre domaine principal), et laissez HTTP/2 faire son travail.

Monitoring et détection de régressions

Le passage à HTTP/2 ou HTTP/3 peut régresser silencieusement. Un upgrade Nginx qui réinitialise la config, un changement de CDN qui désactive QUIC, un certificat TLS expiré qui fait tomber ALPN — autant de scénarios où votre site repasse en HTTP/1.1 sans alerte visible.

Mettez en place un monitoring actif. Un check synthétique toutes les heures qui vérifie le protocole négocié et alerte en cas de régression vers HTTP/1.1. Un outil de monitoring comme Seogard, qui surveille en continu les headers de réponse et les performances serveur, détecte ce type de régression avant qu'elle n'impacte votre crawl budget sur plusieurs jours.

Surveillez aussi vos logs serveur avec le format enrichi présenté plus haut. Un dashboard Grafana ou Datadog qui track la répartition des protocoles Googlebot par jour vous donnera une vision claire de l'adoption côté crawler.

---

HTTP/2 est le minimum attendu en 2026 pour tout site de plus de quelques milliers de pages. HTTP/3 apporte un gain incrémental mais réel, surtout pour les utilisateurs mobiles et les crawlers sur des connexions à latence variable. La configuration est accessible — quelques lignes Nginx suffisent — mais le vrai enjeu est de s'assurer que ça reste en place dans le temps, déploiement après déploiement.