Que sont gzip et HTTP/3, et que faut-il améliorer en premier pour les performances de chargement des pages web ?

gzip permet de réduire la quantité de données à transmettre en compressant les fichiers texte d’une page web, tandis que HTTP/3 est un protocole qui modifie la façon dont les requêtes multiples sont gérées et les pertes de paquets traitées en délivrant HTTP sur QUIC. Les deux peuvent aider au chargement des pages, mais ils ne résolvent pas le même problème. Plutôt que de demander « Lequel est plus rapide, gzip ou HTTP/3 ? », il est plus juste de se demander d’abord où se situe le goulot d’étranglement de la page actuelle : octets transférés, pertes réseau, réponse serveur, images, rendu ou JavaScript.www.rfc-editor.org↗datatracker.ietf.org↗

L’une des idées reçues les plus fréquentes en pratique est que l’activation de HTTP/3 accélère automatiquement l’ensemble d’un site web. HTTP/3 peut constituer une amélioration fondamentale importante, mais il ne remplace pas les solutions à une image trop volumineuse au-dessus de la ligne de flottaison, à du CSS ou JavaScript bloquant le rendu, ou à une réponse serveur lente. À l’inverse, si un site ne compresse pas du tout ses réponses textuelles, l’activation de gzip ou Brotli peut réduire sensiblement le volume transféré avec une modification de configuration relativement limitée.web.dev↗developer.mozilla.org↗

Qu’est-ce que gzip exactement ?

gzip est un codage de contenu (Content-Encoding) très répandu pour HTTP. Un serveur compresse au format gzip le contenu HTML, CSS, JavaScript, JSON, SVG et similaire d’origine avant de l’envoyer, puis le navigateur le décompresse et utilise le contenu d’origine. La spécification HTTP Semantics définit gzip comme un codage de contenu utilisant une compression de la famille LZ77 et un CRC 32 bits.www.rfc-editor.org↗www.rfc-editor.org↗

Le point essentiel est que le type logique du fichier ne change pas. Par exemple, même lorsqu’un serveur fournit app.js avec gzip, le navigateur exécute en définitive le même JavaScript. Ce qui change est le nombre d’octets qui transitent sur le réseau. Lorsqu’un fichier est plus petit, son téléchargement prend moins de temps sur une bande passante limitée, et cela peut aussi réduire la consommation de données mobiles de l’utilisateur.www.rfc-editor.org↗developer.chrome.com↗

Comment les navigateurs et les serveurs choisissent-ils une méthode de compression ?

Les navigateurs utilisent l’en-tête de requête Accept-Encoding pour indiquer les formats de compression qu’ils peuvent décoder. En fonction de cette liste et de ses priorités, le serveur sélectionne une représentation adaptée et ajoute à la réponse un en-tête tel que Content-Encoding: gzip ou Content-Encoding: br. br désigne Brotli.www.rfc-editor.org↗developer.mozilla.org↗

Si un serveur ou un CDN fournit des réponses différentes pour une même URL selon la méthode de compression, il est courant d’envoyer Vary: Accept-Encoding afin que les caches les distinguent. Sinon, une représentation compressée stockée pour un client pourrait être réutilisée de manière inappropriée pour une requête dont les conditions diffèrent.www.rfc-editor.org↗

Voici un flux conceptuel :

1. Le navigateur déclare les formats pris en charge, tels que Accept-Encoding: br, gzip.
2. Le serveur ou le CDN choisit une version Brotli, gzip ou non compressée du fichier.
3. Il identifie le format sélectionné dans Content-Encoding, avec le corps de réponse.
4. Le navigateur décompresse la réponse pendant ou après sa réception, puis poursuit l’analyse HTML, l’application du CSS et l’exécution de JavaScript.

gzip peut réduire le temps de transfert dans ce processus, mais il n’élimine pas le temps consacré par le navigateur à l’analyse et à l’exécution de JavaScript. La compression est une composante de la performance, non une solution à chaque source de délai.developer.chrome.com↗web.dev↗

Quels fichiers bénéficient de gzip ?

gzip convient particulièrement aux textes contenant de nombreuses chaînes et structures répétées. Les données avec beaucoup de répétitions, comme les balises HTML, les sélecteurs CSS, les identifiants et la syntaxe JavaScript, ainsi que les noms de champs JSON, peuvent devenir bien plus petites à transférer après compression. Les recommandations générales de performance web conseillent également d’appliquer la compression aux ressources textuelles et d’exclure les éléments déjà compressés.developer.mozilla.org↗web.dev↗

Pour les formats qui effectuent déjà eux-mêmes une compression, tels que JPEG, WebP, AVIF, la vidéo, l’audio et les archives compressées, appliquer gzip une seconde fois peut apporter peu de bénéfices. Il en va de même pour les petits fichiers. web.dev explique que les ressources inférieures à environ 1 KiB peuvent être compressées de façon inefficace ou n’apporter aucune économie significative.developer.mozilla.org↗web.dev↗

Il est ici important de distinguer la taille transférée de la taille d’origine. Dans le panneau Network des outils de développement, vous pouvez comparer la taille du téléchargement compressé avec la taille non compressée et vérifier l’en-tête de réponse Content-Encoding afin de confirmer que la compression a réellement été appliquée.developer.chrome.com↗

En quoi gzip et Brotli diffèrent-ils ?

Brotli n’est pas le successeur de gzip ; c’est un autre algorithme qui peut être sélectionné en parallèle de gzip pour la compression de contenu HTTP. Sur le Web moderne, il est courant de privilégier Brotli pour les ressources textuelles tout en proposant gzip aux clients qui ne peuvent pas utiliser Brotli. Comme les navigateurs envoient Accept-Encoding et que les serveurs négocient le résultat, différentes représentations compressées peuvent être envoyées pour une même URL selon le client.developer.mozilla.org↗developer.mozilla.org↗

En général, Brotli peut produire des résultats plus petits que gzip pour le texte web. Cela ne signifie toutefois pas toujours une amélioration proportionnelle de la vitesse globale perçue de la page. Si les octets économisés sont peu nombreux, ou si le goulot d’étranglement réside dans les images, le traitement serveur ou l’exécution JavaScript, passer de gzip à Brotli peut avoir un effet limité. Sur les serveurs qui compressent dynamiquement, des paramètres augmentant le taux de compression peuvent aussi accroître l’utilisation du CPU et la latence de réponse. Les ressources statiques devraient donc être précompressées lors de l’étape de build ou via le CDN, tandis que les réponses dynamiques doivent être réglées selon la charge réelle.web.dev↗web.dev↗

Autrement dit, les critères de sélection se rapprochent davantage des points suivants que de « Brotli est toujours meilleur » :

• Si les ressources textuelles sont volumineuses et qu’il y a beaucoup de primo-visiteurs, envisagez de servir à la fois Brotli et gzip.
• Si un CDN fournit déjà une compression adaptée, ne compressez pas à nouveau le même contenu dans l’application.
• Pour un service dynamique dont le CPU serveur est contraint, mesurez l’équilibre entre le niveau de compression et le TTFB.
• Si les images et les vidéos représentent une part importante de la page, l’optimisation des médias peut passer avant la compression de texte.

Que change HTTP/3 ?

HTTP/3 est une norme qui conserve la sémantique requête-réponse de HTTP tout en remplaçant TCP par QUIC comme fondement de transport. QUIC fonctionne sur UDP, mais ce n’est pas simplement une manière d’envoyer HTTP sur UDP. Il fournit des fonctionnalités telles que l’établissement de connexion, le chiffrement, la fiabilité, le contrôle de congestion et les flux multiplexés, et HTTP/3 utilise ces fonctions pour transmettre les messages HTTP.datatracker.ietf.org↗developer.mozilla.org↗

HTTP/1.1 présentait des limitations importantes dans la gestion des requêtes sur une seule connexion, ce qui a généralisé l’utilisation de plusieurs connexions TCP en parallèle. HTTP/2 a amélioré cela en multiplexant plusieurs requêtes sur une seule connexion TCP. Toutefois, comme TCP garantit la livraison dans l’ordre des données reçues, lorsqu’un paquet est perdu sur une connexion, les données qui arrivent ensuite ne peuvent pas être remises à l’application dans l’ordre avant la récupération de cette perte. Avec HTTP/2, ce délai au niveau TCP peut affecter plusieurs flux HTTP.datatracker.ietf.org↗www.rfc-editor.org↗

Le QUIC d’HTTP/3 gère une livraison fiable et ordonnée par flux. En conséquence, la perte de données sur un flux n’oblige pas nécessairement les flux non liés à s’arrêter eux aussi. La RFC 9000 explique que lorsqu’un paquet est perdu, seuls les flux contenant des données de ce paquet sont bloqués en attendant la retransmission, tandis que les autres flux peuvent continuer.www.rfc-editor.org↗

Dans quelle mesure l’expression « élimine le blocage de tête de ligne » est-elle exacte ?

HTTP/3 traite principalement le blocage de tête de ligne à la couche de transport sur l’ensemble de la connexion. Il est inexact d’interpréter cela comme la disparition de toute attente.

D’abord, l’ordre reste important au sein d’un même flux. Si une partie antérieure est perdue sur le même flux, par exemple le corps d’un document HTML ou une grande image, les données ultérieures de ce flux ne peuvent pas être pleinement utilisées tant que l’ordre requis n’est pas rétabli. Ensuite, si des données de plusieurs flux étaient incluses dans un même paquet QUIC, la perte de ce paquet peut retarder plusieurs de ces flux simultanément.www.rfc-editor.org↗

Les bénéfices d’HTTP/3 peuvent donc être particulièrement visibles sur les réseaux où se produisent des pertes ou des réordonnancements de paquets. En revanche, lors de la consultation d’une petite page sur une connexion filaire à faible latence et faible taux de perte, la différence avec HTTP/2 peut être faible ou varier selon les conditions de mesure. En effet, HTTP/3 n’est pas une technologie qui réduit magiquement le nombre d’octets ; c’est une architecture qui réduit la mesure dans laquelle l’attente liée au transport se propage.datatracker.ietf.org↗www.rfc-editor.org↗

En quoi QPACK d’HTTP/3 diffère-t-il de gzip ?

HTTP/3 inclut un mécanisme de compression d’en-têtes appelé QPACK. Cela peut facilement faire croire qu’HTTP/3 inclut gzip, mais ils s’appliquent à des cibles différentes. QPACK est conçu pour représenter efficacement les champs d’en-tête des requêtes et réponses HTTP, tels que Cookie, Content-Type et Cache-Control. gzip et Brotli sont des codages de contenu qui compressent les corps de réponse, comme HTML, CSS et JavaScript.datatracker.ietf.org↗www.rfc-editor.org↗

HPACK d’HTTP/2 repose sur l’hypothèse que l’état de compression des en-têtes est livré dans l’ordre, mais cette hypothèse est difficile à appliquer sans modification à l’architecture de flux indépendants de QUIC. QPACK utilise des flux unidirectionnels distincts pour gérer l’état de la table dynamique, ce qui permet aux implémentations d’équilibrer l’efficacité de compression et le risque de blocage des en-têtes.datatracker.ietf.org↗datatracker.ietf.org↗

Du point de vue des performances réelles des pages, il est utile de considérer leurs rôles ainsi :

• gzip et Brotli : réduisent le volume transféré des corps textuels.
• QPACK : améliore l’efficacité de transmission des en-têtes de requête et de réponse.
• HTTP/3 et QUIC : réduisent la propagation vers les autres requêtes des délais de transport liés aux requêtes multiples et aux conditions de perte.
• Mise en cache : évite de transférer à nouveau les ressources déjà reçues.
• Optimisation des images et du code : réduit le volume de travail à télécharger et traiter dès le départ.

Il ne s’agit pas d’options concurrentes à choix unique ; ce sont des approches complémentaires pour des goulots d’étranglement différents.

Quels sont les goulots d’étranglement les plus importants pour la vitesse perçue d’une page web ?

La vitesse de chargement perçue par les utilisateurs n’est pas un nombre unique. Le temps jusqu’à l’envoi du premier octet par le serveur, le temps jusqu’à ce que le contenu principal au-dessus de la ligne de flottaison devienne visible et le temps jusqu’à ce que les boutons et champs répondent peuvent chacun être retardés par des causes différentes. En particulier, LCP (Largest Contentful Paint) représente le moment où la plus grande image, le plus grand bloc de texte ou la plus grande vidéo dans la zone d’affichage est rendu, ce qui le rend utile pour évaluer l’expérience de page initiale.web.dev↗

Un LCP lent ne signifie pas toujours que la compression réseau en est la cause. web.dev recommande de séparer le TTFB, le délai de chargement de la ressource, le temps de chargement de la ressource et le délai de rendu de l’élément lors du diagnostic du LCP. Par exemple, même si une image se télécharge rapidement, un CSS volumineux peut bloquer le rendu, ou le thread principal peut être trop occupé par de longues tâches JavaScript pour afficher l’image.web.dev↗

Lorsque l’image au-dessus de la ligne de flottaison est le goulot d’étranglement

Le plus grand élément au-dessus de la ligne de flottaison est souvent une image, par exemple une grande photo produit sur une fiche produit, une image principale sur la page d’accueil d’un site d’actualités ou une bannière sur une page de voyage. Dans cette situation, l’activation de gzip aide peu pour les fichiers JPEG, WebP ou AVIF eux-mêmes. Une approche plus efficace consiste à fournir des images dimensionnées selon leurs dimensions d’affichage, à utiliser des formats modernes appropriés et à éviter de retarder l’image LCP avec loading="lazy". Si nécessaire, vous pouvez fournir une indication de priorité avec fetchpriority="high", mais attribuer une priorité élevée sans discernement à de nombreuses images peut au contraire créer de la concurrence.web.dev↗web.dev↗

Lorsque CSS et JavaScript sont le goulot d’étranglement

Le CSS a des caractéristiques de blocage du rendu, car il empêche l’apparition d’un contenu non stylisé. Toutefois, un CSS excessivement volumineux, un CSS non nécessaire à la vue initiale et des scripts chargés de façon synchrone peuvent retarder l’affichage du contenu principal. Même après la fin du transfert, de gros bundles JavaScript sollicitent le thread principal du navigateur pour l’analyse, la compilation et l’exécution ; réduire uniquement la taille de téléchargement avec gzip peut donc ne pas suffire.developer.chrome.com↗web.dev↗

Les performances JavaScript doivent donc être examinées séparément de la compression. Il est notamment possible de supprimer le code inutilisé, de charger à la demande les fonctionnalités inutiles pour la vue initiale, de découper les longues tâches et, lorsque cela est possible, d’utiliser le rendu côté serveur ou le prerendering afin que le HTML initial expose le contenu et les ressources essentiels à la découverte. Toutefois, le rendu côté serveur peut aussi augmenter le temps de traitement serveur et affecter le TTFB ; les changements d’architecture doivent donc être évalués par la mesure.web.dev↗

Lorsque la réponse serveur et la mise en cache sont le goulot d’étranglement

Lorsque le TTFB est long, le navigateur a du mal à découvrir les ressources suivantes avant de recevoir le HTML. Les causes courantes comprennent un serveur éloigné, un traitement long de la base de données et de la personnalisation, des redirections inutiles et des possibilités de mise en cache inexploitées. HTTP/3 peut améliorer une partie de l’étape de transfert dans cette situation, mais il ne réduit pas directement le temps nécessaire au serveur pour générer la première réponse.web.dev↗

La mise en cache a une nature différente des autres améliorations de performance. gzip envoie les mêmes données sous une forme plus petite, HTTP/3 modifie les caractéristiques de connexion utilisées pour fournir les données, et le cache évite de les envoyer à nouveau lors de visites répétées admissibles. Pour un service où les visiteurs récurrents représentent une part élevée, une politique de cache adaptée peut créer une différence perçue plus importante que le changement d’algorithme de compression. Toutefois, les stratégies de cache des réponses qui changent fréquemment ou varient selon l’utilisateur, comme le HTML, doivent être conçues avec davantage de prudence.www.rfc-editor.org↗developer.chrome.com↗

Quel est le classement pratique des améliorations de performance selon l’impact perçu ?

Il n’existe pas de classement fixe applicable à tous les sites. Les résultats diffèrent selon la composition de la page, la proportion de primo-visiteurs et de visiteurs récurrents, les réseaux des utilisateurs, l’emplacement des serveurs et la configuration existante. Néanmoins, pour des pages de contenu, de commerce et de services typiques présentant encore des goulots d’étranglement majeurs, l’ordre d’analyse suivant est pratique.

1. Identifiez ce qui retarde le contenu essentiel au-dessus de la ligne de flottaison. Examinez d’abord la taille, le moment de découverte et la priorité de l’image LCP ; le CSS bloquant le rendu ; le JavaScript synchrone ; et le rendu côté client inutile.web.dev↗
2. Examinez le temps de réponse serveur et la mise en cache. Vérifiez le TTFB, les redirections, l’implantation du CDN, la mise en cache des ressources statiques et les délais de traitement du backend.web.dev↗www.rfc-editor.org↗
3. Vérifiez la compression des textes pour HTML, CSS, JavaScript et JSON. S’ils ne sont pas compressés, appliquer gzip ou Brotli est très prioritaire. S’ils sont déjà correctement compressés, les gains supplémentaires dans ce même domaine peuvent être limités.developer.mozilla.org↗developer.chrome.com↗
4. Réduisez le volume de transfert total et optimisez la composition des requêtes. Nettoyez les grandes images, les scripts et les ressources tierces, et reportez les requêtes jusqu’au moment où elles sont réellement nécessaires. Les charges utiles réseau importantes sont associées à des temps de chargement longs.developer.chrome.com↗developer.chrome.com↗
5. Proposez HTTP/3, conservez une solution de repli HTTP/2 et validez avec le trafic réel. Comparez les résultats avant et après, en particulier sur mobile, dans les environnements à forte latence et pertes de paquets, et sur les pages avec de nombreuses requêtes simultanées.datatracker.ietf.org↗www.rfc-editor.org↗

Ce classement comporte des exceptions importantes. Si une application possède des réponses textuelles non compressées de plus de 1 Mo, appliquer gzip ou Brotli à l’étape 3 peut être la plus grande amélioration à court terme. À l’inverse, si une image principale pèse plusieurs Mo et que le texte est déjà compressé avec Brotli, l’optimisation des images est prioritaire. Si le serveur ne peut pas générer le HTML pendant plusieurs secondes, le travail sur le backend et le cache passe avant HTTP/3.developer.mozilla.org↗web.dev↗developer.chrome.com↗

Si vous ne comparez que gzip et HTTP/3

Si vous devez choisir entre ces deux technologies uniquement, la décision est relativement simple.

• Lorsque le texte n’est pas compressé : gzip ou Brotli vient généralement d’abord. Cela réduit la quantité de données à transmettre ; des bénéfices sont donc attendus sur toute connexion prise en charge.
• Lorsque la compression fonctionne déjà correctement : la valeur relative d’HTTP/3 augmente. Cependant, l’amélioration effective dépend de la qualité du réseau et de la structure des requêtes.
• Pour les pages riches en images et en vidéos : gzip ni HTTP/3 seul ne résoudra probablement le problème principal. L’optimisation des médias vient d’abord.
• Pour les grandes applications JavaScript : gzip n’est qu’un point de départ. Vous devez aussi examiner les coûts d’exécution après transfert afin d’obtenir une amélioration perçue durable.
• Pour les services comptant de nombreuses visites récurrentes : les taux de succès du cache peuvent être une variable plus importante que le changement de méthode de compression.

Par conséquent, aucune de ces conclusions — « gzip passe toujours avant HTTP/3 » ou « HTTP/3 est plus récent, donc il passe toujours avant » — n’est exacte. Une formulation plus précise est la suivante : la compression de contenu est la priorité de base pour le texte non compressé, tandis qu’HTTP/3 est une optimisation fondamentale susceptible d’apporter des bénéfices supplémentaires selon les conditions de transport et les modèles de requêtes.

Quelles contraintes faut-il prendre en compte lors de l’adoption d’HTTP/3 ?

Pour fournir HTTP/3, les serveurs, CDN, équilibreurs de charge, pare-feu et outils d’observabilité doivent pouvoir gérer convenablement QUIC et le trafic fondé sur UDP. Comme certains clients ou chemins réseau peuvent ne pas pouvoir utiliser HTTP/3, un déploiement progressif qui fournit également HTTP/2 ou HTTP/1.1 est généralement approprié. La norme HTTP/3 est fondée sur QUIC et définit le processus par lequel un client découvre un serveur HTTP/3 puis établit une connexion QUIC.datatracker.ietf.org↗

D’un point de vue opérationnel, il est important de ne pas juger la réussite sur la seule base d’un changement de protocole. Surveillez ensemble la part des connexions HTTP/3, les taux d’échec et de nouvelle tentative, le TTFB, le LCP, les taux d’erreur et l’utilisation du CPU. En particulier, lorsqu’un CDN ou un proxy se trouve devant l’origine, le protocole visible au serveur d’origine peut différer de celui réellement employé par le navigateur de l’utilisateur final ; l’observation côté client doit donc aussi être incluse.developer.chrome.com↗developer.chrome.com↗

Existe-t-il des considérations de sécurité liées à la compression ?

Oui. Même avec HTTPS, si une entrée contrôlée par un attaquant et des valeurs secrètes sont compressées ensemble dans le même contexte de compression, un attaquant peut parvenir à déduire le secret en observant les différences de longueur du texte chiffré. Les spécifications HTTP Semantics et HTTP/3 mettent en garde contre les situations où des données sensibles et des données contrôlées par un attaquant sont compressées ensemble, et identifient la désactivation de la compression pour les données sensibles ou la séparation des contextes de compression comme les mesures d’atténuation les plus fiables.www.rfc-editor.org↗www.rfc-editor.org↗

Cela ne signifie pas que chaque réponse gzip est dangereuse. La question essentielle est de savoir si des entrées utilisateur réfléchies, des secrets liés à l’authentification et des conditions permettant à un attaquant d’effectuer des requêtes répétées et d’observer les tailles de réponse existent simultanément. Les flux sensibles, tels que la connexion, le paiement et la récupération de compte, ne devraient pas recevoir mécaniquement les mêmes politiques de compression que les ressources statiques générales ; ils doivent être examinés avec la conception de sécurité.www.rfc-editor.org↗datatracker.ietf.org↗

Que dois-je mesurer sur mon site ?

Il est plus sûr de valider les améliorations de performance par l’expérience des utilisateurs réels qu’au moyen d’un unique score de laboratoire. Lighthouse est utile pour identifier rapidement des problèmes potentiels, mais il ne représente pas tous les utilisateurs réels à travers des réseaux, appareils, états de cache et régions divers. L’utilisation conjointe des outils de développement et de la surveillance des utilisateurs réels facilite la distinction entre hypothèses et résultats.developer.chrome.com↗developer.chrome.com↗

Vous pouvez examiner les performances dans l’ordre suivant :

1. Vérifiez l’état de transfert actuel. Dans le panneau Network, examinez Content-Encoding, la taille transférée et la taille d’origine des réponses HTML, CSS, JS et JSON importantes.developer.chrome.com↗
2. Vérifiez le protocole. Dans la colonne Protocol, confirmez si les requêtes utilisent effectivement h3, h2 ou http/1.1.
3. Segmentez les métriques utilisateur clés. Comparez le TTFB, le LCP et les métriques d’interaction par première visite ou visite récurrente, mobile ou ordinateur, région et type de réseau.web.dev↗web.dev↗
4. Modifiez une seule chose à la fois. Si vous déployez simultanément l’activation de gzip, la prise en charge de Brotli, le remplacement des images, le découpage JavaScript et l’activation d’HTTP/3, il est difficile d’identifier le changement qui a produit un effet.
5. Consignez également les effets secondaires. Surveillez aussi le CPU serveur, les taux d’erreur, les taux de succès du cache, ainsi que les taux d’échec de connexion ou de repli HTTP/3.

Par exemple, si le passage d’un bundle JavaScript non compressé à gzip réduit la taille transférée mais modifie à peine le LCP, le prochain goulot d’étranglement est probablement une grande image, le CSS ou l’exécution JavaScript plutôt que la compression. À l’inverse, si la longue traîne du LCP s’améliore pour les utilisateurs de réseaux mobiles après l’adoption d’HTTP/3, vous pouvez identifier des bénéfices dans les environnements à fortes pertes et forte latence, en plus d’observer les moyennes. Ces conclusions commencent par les goulots d’étranglement mesurés, non par le nom d’une technologie.web.dev↗www.rfc-editor.org↗

Résumé : considérez gzip et HTTP/3 comme des rôles complémentaires, non comme un concours de classement

gzip et HTTP/3 sont tous deux utiles aux performances web, mais la base de leur comparaison diffère. gzip réduit les octets transférés pour les réponses textuelles, tandis qu’HTTP/3 peut réduire l’impact des pertes réseau sur les requêtes multiples grâce aux flux multiplexés fondés sur QUIC. QPACK d’HTTP/3 est une compression d’en-têtes ; il ne remplace pas la compression des corps assurée par gzip et Brotli.www.rfc-editor.org↗datatracker.ietf.org↗datatracker.ietf.org↗

La priorité la plus pratique consiste à identifier d’abord le goulot d’étranglement réel parmi le LCP, le TTFB, le blocage du rendu, JavaScript, les images et le cache ; à mettre en place la compression de texte comme base si elle est absente ; puis à valider HTTP/3 dans des conditions d’utilisateurs réels. La performance ne consiste pas à ajouter une technologie récente : elle consiste à raccourcir le chemin le plus long que l’utilisateur doit attendre.web.dev↗developer.chrome.com↗

Pour aller plus loin

• Spécifications HTTP Semantics et de codage de contenuwww.rfc-editor.org↗
• Norme HTTP/3datatracker.ietf.org↗
• Norme de compression d’en-têtes QPACKdatatracker.ietf.org↗
• Spécification de transport QUICwww.rfc-editor.org↗
• Recommandations sur les performances web et l’optimisation du LCPweb.dev↗
• Vue d’ensemble de la compression HTTPdeveloper.mozilla.org↗