HTTP/1.1 ouvrait une poignée de connexions et envoyait une requête à la fois sur chacune : chaque fichier supplémentaire coûtait donc une place dans la file. HTTP/2 les envoie toutes d'un coup sur une seule connexion, et ce seul changement rend plusieurs vieilles optimisations inutiles ou nuisibles.

L'activer

listen 443 ssl;
http2 on;

Il exige TLS dans tous les navigateurs : il arrive donc avec le certificat que vous avez déjà. Rien d'autre n'a besoin de changer.

Ce qui cesse d'être vrai

Concaténer tous les scripts en un fichier, et les sprites CSS, servaient à réduire le NOMBRE de requêtes. Sous HTTP/2, ce nombre ne coûte presque rien — et un gros paquet signifie qu'une ligne modifiée invalide l'ensemble pour chaque visiteur.
  • Livrez plusieurs petits fichiers qui se mettent en cache indépendamment.
  • Ne répartissez pas sur plusieurs domaines : c'était une astuce pour obtenir plus de connexions parallèles, et cela coûte désormais une poignée de main de plus par domaine.
  • N'intégrez que ce dont le premier rendu a réellement besoin.

HTTP/3

listen 443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400';

HTTP/3 fonctionne sur UDP. Son vrai gain est sur les réseaux peu fiables — le mobile surtout — où un paquet perdu ne bloque plus tout le reste de la connexion.

Vérifiez ce que vous servez

curl -sI --http2 https://yourdomain.com | head -1
curl -sI --http3 https://yourdomain.com | head -1
Ni l'un ni l'autre ne rend rapide une page lente. Si le TTFB est de 900 ms, le protocole n'est pas le problème, et passer à HTTP/3 ne changera rien de perceptible.