Mesurer les performances de HTTP/3 dans le monde réel

Jusqu'à présent, dans cette série, j'ai expliqué en détail comment QUIC et HTTP/3 ont surmonté les problèmes de sécurité et de confidentialité qui affectent le protocole de contrôle de transport (TCP) et HTTP/2 de manière à être à l'épreuve du temps. Dans ce billet, j'examinerai leur comparaison en ce qui concerne la caractéristique peut-être la plus importante de tout protocole : la performance.

Bien qu'il soit encore un peu tôt pour répondre définitivement à cette question, étant donné que la plupart des comparaisons (publiques) entre HTTP/2 et HTTP/3 sont basées sur des tests en laboratoire plutôt que sur des déploiements dans le monde réel, nous disposons de quelques points de données qui peuvent nous éclairer.

Tout d'abord, le document original de Google décrivant les mécanismes de base de QUIC fait état d'une réduction moyenne de 8 % du temps de chargement des résultats de recherche Google sur ordinateur de bureau et de 3,6 % sur mobile. Et pour les 1 % d'utilisateurs les plus lents de Google, le chargement était jusqu'à 16 % plus rapide. En ce qui concerne le streaming vidéo sur YouTube, les chercheurs ont constaté jusqu'à 20 % de réduction du blocage vidéo (lorsque la lecture de la vidéo doit s'arrêter pour attendre l'arrivée de nouvelles données) dans des pays tels que l'Inde.

À première vue, ces chiffres ne semblent pas être des améliorations considérables. Toutefois, à l'échelle de Google, ils peuvent facilement se traduire par des millions de revenus supplémentaires, car les performances Web sont liées à l'engagement des utilisateurs et aux conversions de visites.

Deuxièmement, Wix, un outil de création de sites web puissant et populaire, a mené des expériences comparant HTTP/2 à HTTP/3 sur les millions de sites web de ses clients. En examinant principalement les temps d'établissement de la connexion, ils ont constaté des améliorations allant jusqu'à 33 % en moyenne et souvent plus dans le 75e percentile (figure 1). Pour certains pays, comme les Philippines, cela peut avoir un impact significatif - plus de 250 ms. De même, en examinant une autre mesure populaire des performances du web, appelée Largest Contentful Paint (LCP), ils ont constaté des améliorations allant jusqu'à 20 % dans le 75e percentile, réduisant souvent la valeur LCP de plus de 500 ms (soit environ un cinquième des 2 500 ms recommandés par Google comme valeur cible). Ce n'est pas si mal pour passer à un nouveau protocole !

Enfin, mon employeur Akamai, le plus grand réseau de diffusion de contenu (CDN) au monde, teste et optimise HTTP/3 depuis plusieurs années. En général, nous constatons des gains similaires en termes de vitesse d'établissement des connexions. En outre, nous avons examiné le débit moyen (utilisation effective de la bande passante), qui devrait également être amélioré grâce, par exemple, à la meilleure détection et récupération des pertes de paquets de QUIC.

Pour un grand client média d'Akamai, lors d'un événement de streaming en direct de football européen également populaire en Amérique latine, nous avons constaté un débit nettement plus élevé sur HTTP/3 que sur HTTP/2 (tableau 1). Par exemple, nous avons constaté qu'environ 69 % des connexions HTTP/3 atteignaient un débit de 5 Mbps ou plus (indiqué par Netflix comme le seuil minimum pour le streaming vidéo Full HD), contre seulement 56 % des connexions HTTP/2. Dans la pratique, cela signifie que les flux vidéo seront d'une meilleure qualité visuelle et/ou qu'il y aura moins de décrochages sur HTTP/3.

Comme HTTP/3 nécessite un processus d'amorçage(à l'aide d'une fonction appelée alt-svc), il peut être difficile de faire une comparaison nette entre HTTP/2 et HTTP/3. En outre, de nombreuses grandes entreprises ne sont pas disposées à partager des chiffres bruts pour des raisons commerciales.

Néanmoins, le fait que des entreprises telles que Google, Meta, Apple, Twitch et de grands CDN comme Akamai, Cloudflare et Fastly déploient ces protocoles à grande échelle devrait être un bon indicateur des avantages pratiques (en termes de performances) qu'ils apportent. En effet, QUIC et HTTP/3 sont (beaucoup) plus coûteux à héberger sur leurs plateformes, car ils nécessitent plus de temps d'unité centrale et de mémoire que TCP et HTTP/2, en raison, par exemple, de leur cryptage plus étendu. Ce coût est (apparemment) suffisamment compensé par les avantages que les protocoles apportent à leurs résultats.

Dans mon prochain article, j'examinerai l'impact de ces dépenses et d'autres facteurs limitatifs lorsqu'il s'agit de déployer QUIC et HTTP/3, et je me demanderai si cela les retiendra.

Robin Marx est expert en protocoles et performances web chez Akamai. Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l'Internet Society.