L'équipe concatène encore trente fichiers JavaScript « parce qu'HTTP/1 » — alors que nginx sert déjà HTTP/2 depuis deux ans. Le bundle monolithique casse le cache à chaque correctif. Parallèlement, un autre projet distribue ses assets sur static1, static2, static3 : trois handshakes TLS, le multiplexage est annulé par des habitudes héritées de HTTP/1.
HTTP/2 multiplexe plusieurs requêtes sur une seule connexion TCP/TLS. Fini la file d'attente des six emplacements parallèles de HTTP/1.1 — mais pas fini le JavaScript render-blocking ni les images de quatre mégaoctets. Comprendre le multiplexage, c'est savoir ce qu'il règle et ce qu'il laisse intact.
Multiplexage : ce qui change concrètement
Sous HTTP/1.1, les navigateurs limitaient les connexions parallèles vers un même domaine — d'où le domain sharding, les sprites CSS et la concaténation de fichiers. HTTP/2 ouvre des streams indépendants sur une connexion unique, avec compression HPACK des headers.
| Pratique HTTP/1 | Sous HTTP/2 |
|---|---|
| Domain sharding | Contre-productif |
| Sprites CSS | Moins nécessaire |
| Gros bundle unique | Modules + cache par hash |
| Six connexions keep-alive | Une connexion riche |
Le multiplexage accélère le transport — pas la taille des fichiers ni l'ordre d'exécution du JavaScript.
Un site qui charge douze scripts synchrones dans le <head> reste lent, HTTP/2 ou non. La contrainte réseau a changé ; la contrainte du chemin critique de rendu, elle, demeure.
Priorisation, blocage en tête de file et limites
HTTP/2 a souffert du blocage en tête de file au niveau TCP : la perte d'un paquet bloquait tous les streams. HTTP/3 (QUIC) améliore ce point en UDP. En pratique, réduire le nombre de scripts synchrones dans le <head> reste plus impactant que tweaker les priorités de streams côté nginx.
Les priorités de streams entre navigateur et serveur ont un effet réel modeste comparé à l'optimisation de l'image LCP ou au report du JavaScript non essentiel. Mesurez LCP, TBT et INP — pas seulement le protocole dans les headers de réponse.
CDN, terminaison TLS et origin
La terminaison HTTP/2 au CDN (Cloudflare, etc.) vers un origin HTTP/1.1 reste très courante : le client bénéficie du multiplexage, l'origin conserve une stack plus simple. Vérifiez la négociation ALPN avec :
curl -I --http2 https://votre-site.example
Sur un hébergement mutualisé sans HTTP/2 natif, un CDN gratuit devant l'origin suffit souvent. Comparez les offres via notre annuaire — le support ALPN h2 dépend du serveur web et du certificat, pas seulement d'une case dans le panel.
Le server push HTTP/2 est largement déprécié : Chrome l'a retiré, et le preload via <link rel="preload"> offre un contrôle plus fin sans gaspiller de bande passante sur des ressources déjà en cache.
HTTP/3 et migration progressive
HTTP/3 repose sur QUIC (UDP) et améliore les performances sur réseaux mobiles avec pertes de paquets. L'activation se fait progressivement côté CDN — Cloudflare, Fastly et autres l'activent sans refonte applicative. Votre code PHP ou Node.js n'a pas besoin de changer ; c'est la couche réseau qui évolue.
Retirez d'abord les pratiques HTTP/1 devenues nuisibles : sharding de domaines, bundles monolithiques, sprites inutiles. Ensuite, activez HTTP/3 si votre CDN le propose — c'est un bonus, pas un prérequis.
Checklist après activation HTTP/2
- Retirer le sharding de domaines sur les assets statiques.
- Découper les bundles de façon logique (par route ou par fonctionnalité).
- Preload l'image LCP, defer ou async le JavaScript non critique.
- Conserver la compression Brotli ou gzip — HTTP/2 ne compresse pas le corps des réponses.
- Aligner les headers de cache pour que le gain réseau ne soit pas annulé par des revalidations excessives.
Le sommet : badge HTTP/2, site toujours lent
Voici ce que le protocole affiché dans les DevTools ne garantit pas.
Comprendre le multiplexage, c'est arrêter d'optimiser pour HTTP/1 tout en continuant à optimiser contenu et chemin critique.
Décider et avancer sans angle mort
Sur une demi-journée, vérifiez que HTTP/2 apporte un gain réel :
- Confirmez que HTTP/2 est actif côté client (
curl --http2ou onglet Protocol dans les DevTools). - Supprimez le sharding de domaines sur les assets — mesurez LCP avant et après.
- Remplacez le bundle monolithique par des modules raisonnables avec hash dans le nom.
- Activez HTTP/3 via le CDN si disponible, sans attendre une refonte applicative.
- Comparez les hébergeurs avec TLS et HTTP/2 via l'annuaire et le comparateur.
Si le site reste lent après HTTP/2, le goulot d'étranglement est ailleurs — images, JavaScript, base de données. Le blog technique propose des guides complémentaires sur le cache et les formats d'image.
Questions fréquentes
HTTP/2 rend-il domain sharding inutile ?
Oui, en principe. Une connexion multiplexée sert plusieurs fichiers sans ouvrir de nouvelles connexions TCP/TLS. Le sharding recrée des handshakes coûteux et annule souvent le bénéfice du multiplexage. Gardez un origin ou un CDN HTTP/2 propre.
Faut-il encore concaténer CSS/JS ?
Moins qu'en HTTP/1.1, mais un bundle énorme conserve une granularité de cache médiocre : chaque modification invalide tout le fichier. Visez des modules raisonnables, pas quarante micro-fichiers non mis en cache.
Server push HTTP/2 est-il utile ?
Largement non. Chrome a retiré le support, et le preload via balise <link> offre un contrôle plus fin. Ne configurez pas le push nginx sans mesure d'impact sur la bande passante.
HTTP/2 partout nécessite quoi côté hébergeur ?
TLS avec ALPN h2, certificat valide, serveur web récent (nginx, Apache, Caddy) ou CDN terminant HTTP/2. En mutualisé, vérifiez le support dans le panel ; sinon, placez un CDN devant un origin HTTP/1.1.
HTTP/2 règle la file d'attente réseau — pas la file d'attente JavaScript.