HTTP/2 améliore la livraison grâce au multiplexage des requêtes et à la compression des en-têtes. HTTP/3 utilise QUIC, qui peut isoler la perte d’un flux des autres et permettre la migration d’une connexion. Activer un protocole récent ne supprime toutefois ni calculs applicatifs, ni ressources lourdes, ni rendu. Vérifiez la version négociée et mesurez les parcours importants.
Identifiez les limites de HTTP/1.1
La sémantique HTTP définit méthodes, états, en-têtes et ressources ; le transport organise leur circulation. HTTP/2 ou HTTP/3 ne change pas l’opération GET et ne rend pas une réponse cacheable automatiquement. Diagnostiquez donc séparément transport et politique de cache.
HTTP/1.1 permet des connexions persistantes, mais son usage courant en navigateur n’entrelace pas librement les réponses sur une connexion. Le pipelining conserve des contraintes d’ordre et n’a pas constitué une solution générale pratique. Les navigateurs ouvrent plusieurs connexions avec des limites propres à leur implémentation. Chacune peut ajouter établissement et concurrence réseau.
Cela a encouragé regroupement des fichiers et multiplication des hôtes. Ces choix réduisaient parfois l’attente, tout en ajoutant gros bundles, DNS et connexions. Un protocole moderne modifie cet équilibre sans justifier la suppression aveugle des anciennes optimisations.
Le guide du temps de réponse serveur distingue attente de connexion et attente applicative. Si la génération HTML domine, le principal délai peut subsister presque intégralement.
Comprenez le multiplexage HTTP/2
HTTP/2 transporte des messages sous forme de trames binaires sur des flux. Plusieurs flux partagent TCP et avancent sans attendre la fin de chaque réponse complète. HPACK réduit la répétition des champs d’en-têtes.
Le multiplexage ne crée pas une bande passante illimitée. Les flux se partagent la capacité et dépendent de l’ordonnancement et du contrôle de flux. Demander immédiatement chaque ressource optionnelle peut concurrencer une image ou feuille de style critique. Découverte et priorité restent nécessaires malgré une cascade réseau différente.
HTTP/2 conserve le flux ordonné de TCP. Lorsqu’une perte crée un trou, TCP doit le réparer avant de livrer les octets suivants dans l’ordre, retardant parfois des flux HTTP indépendants. Ce blocage en tête de ligne du transport diffère de l’ordre des réponses HTTP/1.1 et explique un avantage possible de HTTP/3.
Server push appartient à l’histoire de HTTP/2, mais ne constitue pas une optimisation générale sur laquelle compter dans les navigateurs modernes. Ne le substituez pas à une découverte claire des ressources. Vérifiez les capacités réellement utilisées et privilégiez les mécanismes pris en charge.
Situez les apports de QUIC
HTTP/3 utilise QUIC, transport sécurisé multiplexé sur des datagrammes UDP. QUIC apporte flux fiables, récupération des pertes et contrôle de congestion. Utiliser UDP ne signifie donc pas perdre sans réparation des octets de réponse. Le chiffrement est intégré à l’établissement.
La perte d’un flux ne force pas les autres à attendre ses données comme dans HTTP/2 sur TCP. Congestion commune, capacité réseau et dépendances du protocole demeurent. HTTP/3 n’élimine pas tous les blocages et n’est pas systématiquement plus rapide sur une liaison avec pertes.
Les identifiants QUIC peuvent maintenir une connexion lors d’un changement de chemin, selon support et validation. Passer du Wi-Fi au réseau mobile est un scénario à tester, pas une promesse de continuité universelle. Certaines infrastructures restreignent UDP : le repli reste essentiel.
La reprise de connexion peut autoriser des données précoces, dites 0-RTT. Cela ne concerne pas chaque première visite et comporte des risques de rejeu nécessitant des protections. Ne l’activez pas sans discernement pour paiements ou changements de compte. Un déploiement HTTP/3 n’exige pas toutes les fonctions optionnelles.
Ces propriétés distinguent les protocoles.
| Propriété | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport habituel du navigateur | TCP, avec TLS pour HTTPS | TCP avec TLS | QUIC sur UDP |
| Réponses parallèles sur une connexion | Limitées par leur ordre | Flux multiplexés | Flux QUIC multiplexés |
| Compression des en-têtes | Ni HPACK ni QPACK | HPACK | QPACK |
| Isolation des pertes | Ordre TCP | TCP peut toucher tous les flux | Livraison plus indépendante |
| Blocages applicatifs | Subsistent | Subsistent | Subsistent |
Vérifiez la version réellement négociée
Dans Network de Chrome DevTools, activez Protocol depuis le menu des colonnes. Rechargez puis inspectez séparément document et ressources importantes. h2 et h3 décrivent la requête concernée. Les origines d’une même page peuvent employer plusieurs versions.
Si un CDN termine la connexion, la colonne décrit navigateur vers périphérie. Le CDN peut utiliser un autre protocole vers l’origine. Un document h3 ne prouve pas le support HTTP/3 du serveur d’origine ; un transport plus ancien derrière le CDN n’annule pas tous les gains côté visiteur. Le guide CDN et cache périphérique détaille cette distinction.
Le navigateur peut découvrir HTTP/3 via Alt-Svc ou des mécanismes DNS compatibles. Première requête et suivantes peuvent différer. Connexions existantes, annonces conservées, certificats et UDP bloqué influencent le résultat. Notez si le test utilise une nouvelle connexion.
Contrôlez les capacités de curl : toutes les compilations ne prennent pas HTTP/3 en charge.
curl --version
curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://example.com/
curl --http3-only -sS -o /dev/null -w '%{http_version}\n' https://example.com/La requête exclusivement HTTP/3 interdit volontairement le repli et peut révéler un problème réseau ou de support. C’est un diagnostic, pas une reproduction intégrale du navigateur. La version affichée après succès est plus probante que l’option demandée.
Activez le protocole à la couche que vous contrôlez
Sur hébergement administré ou CDN, partez de la documentation actuelle et du panneau de gestion. Vérifiez hôte et segment concernés, certificat valide, connexion d’origine et repli HTTP/2. Un interrupteur activé et une requête h3 réussie sont deux preuves distinctes.
Apache HTTP Server 2.4 avec mod_http2 documente Protocols. Ce fragment permet à un hôte virtuel TLS d’annoncer HTTP/2 avec repli HTTP/1.1.
Protocols h2 http/1.1Conservez la configuration TLS et les certificats. mod_http2 ne démontre pas la prise en charge de HTTP/3, fonction distincte. Vérifiez paquet installé et frontal compatible avant de choisir où terminer le trafic.
Dans Nginx, la directive indépendante http2 on existe depuis 1.25.1. HTTP/3 exige le module correspondant et une bibliothèque TLS compatible ; la documentation qualifie le module d’expérimental. Placez ces directives dans un bloc TLS existant avec certificats valides et modules requis.
Ce fragment active HTTPS sur TCP et QUIC sur le même numéro de port, avec des transports différents.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';Intégrez les listeners sans les dupliquer, surtout entre hôtes partageant une adresse. Vérifiez l’héritage avant add_header. Autorisez UDP 443 dans pare-feu et équilibreurs tout en conservant TCP 443. La durée de l’annonce est illustrative et ne prouve pas l’accessibilité QUIC.
Validez avec nginx -t, puis depuis un client externe avant extension. Compilation, TLS et données précoces varient ; utilisez la documentation de la version installée. Ni ce fragment ni la syntaxe validée ne constituent une configuration de sécurité complète.
Réévaluez sharding, sprites et gros bundles
Le domain sharding répartit les ressources sur plusieurs hôtes pour multiplier les connexions. Avec multiplexage, il peut ajouter DNS et connexions inutiles et limiter leur réutilisation. Consolidez après contrôle des certificats, caches, priorités et résultats réels. La coalescence parfois possible ne rend pas tous les hôtes gratuits.
Les sprites regroupent des images et peuvent convenir à un design. De grands sprites risquent néanmoins de télécharger des pixels inutiles et d’invalider des éléments indépendants. Regrouper tout JavaScript réduit parfois les requêtes en obligeant chaque route à recevoir et traiter des fonctions inutilisées.
Évitez aussi une fragmentation extrême : requêtes, en-têtes, compression et dépendances ont toujours un coût. Préférez des frontières fonctionnelles et comparez premier chargement et navigation répétée. Le guide du cache navigateur explique l’effet de fichiers stables avec empreinte.
Mesurez au-delà d’un rechargement rapide
Comparez appareils et réseaux représentatifs avec mêmes versions, états de cache et conditions serveur. Incluez connexions neuves, reprises, visites répétées et chemin sans HTTP/3. Enregistrez le protocole réel, pas seulement le réglage prévu.
Mesurez établissement, TTFB, fin des ressources critiques et performance visible. Ne modifiez pas simultanément routage CDN, compression, cache et protocoles pour attribuer un résultat. Un cache plus chaud ou un autre nœud peut sinon ressembler à un gain de transport.
Documentez réglages et repli dans la liste de contrôle des performances. Approfondissez avec la collection sur les performances serveur et la spécification HTTP/3. Conservez le déploiement si les parcours restent fiables et les mesures soutiennent son bénéfice, même inférieur aux avantages théoriques.
