2015 : l’IETF publie la spécification RFC 7540, qui standardise HTTP/2. Presque dix ans plus tard, une part significative des hébergements mutualisés qui accueillent encore des sites WordPress ne proposaient toujours pas ce protocole par défaut, ou le proposaient de façon incomplète. Ce décalage entre standardisation et adoption réelle mérite d’être raconté, car il éclaire aussi la lenteur avec laquelle les infrastructures d’hébergement grand public évoluent.
Comprendre les freins qui ont retardé cette adoption permet de mieux anticiper le rythme, probablement similaire, avec lequel les protocoles plus récents comme HTTP/3 s’imposeront à leur tour sur ce même segment d’hébergement.
Ce que promettait HTTP/2 dès son origine
Par rapport à HTTP/1.1, HTTP/2 introduisait le multiplexage des requêtes sur une seule connexion TCP, éliminant le besoin historique de concaténer les fichiers CSS et JavaScript pour limiter le nombre de connexions simultanées. Pour un site WordPress chargé de multiples feuilles de style et scripts provenant d’extensions différentes, ce changement représentait un gain potentiel important, sans nécessiter la moindre modification du code applicatif.
Le premier frein : le TLS obligatoire de fait
Bien que la spécification HTTP/2 n’impose pas techniquement le chiffrement TLS, tous les navigateurs majeurs ont choisi de n’implémenter le protocole que par-dessus une connexion HTTPS. Cette décision, prise pour des raisons de sécurité et de compatibilité réseau, a directement lié l’adoption de HTTP/2 à la généralisation du HTTPS, qui restait loin d’être systématique sur le mutualisé au milieu des années 2010, à une époque où un certificat SSL représentait encore un coût et une démarche technique supplémentaire pour beaucoup de propriétaires de sites.
Ce n’est qu’avec l’arrivée d’autorités de certification gratuites et automatisées, dont Let’s Encrypt à partir de 2016, que le HTTPS est devenu la norme par défaut sur la plupart des hébergements mutualisés, ouvrant enfin la voie à une adoption large de HTTP/2 sans surcoût pour l’hébergeur ni pour le client final.
Le deuxième frein : la mise à jour du logiciel serveur
Activer HTTP/2 nécessite un serveur web compatible : Apache à partir de la version 2.4.17 avec le module mod_http2, ou Nginx à partir de la version 1.9.5. Or de nombreux hébergeurs mutualisés, gérant des parcs de serveurs mutualisés à grande échelle avec des milliers de comptes clients actifs, ont historiquement retardé la montée de version de leurs serveurs web pour des raisons de stabilité et de compatibilité avec des configurations clientes anciennes, parfois pendant plusieurs années après la disponibilité technique du support HTTP/2.
Ce qui a fini par accélérer le mouvement
- La pression concurrentielle entre hébergeurs, HTTP/2 devenant un argument commercial visible dans les offres.
- L’intégration native de HTTP/2 dans les outils de mesure de performance grand public, rendant son absence visible et pénalisante dans les rapports d’audit.
- La généralisation des CDN proposant HTTP/2 par défaut en frontal, contournant partiellement la limitation du serveur d’origine pour les ressources statiques.
- La simplification progressive des chaînes d’outils serveur (panels d’hébergement intégrant HTTP/2 en une case à cocher plutôt qu’une configuration manuelle).
Ce que révèle cette histoire sur le rythme du mutualisé
Un protocole standardisé au niveau international ne devient une réalité pour la majorité des sites WordPress que lorsque son adoption ne demande plus aucun effort ni coût perceptible à l’hébergeur ni au client final : c’est la vraie condition qui accélère un changement d’infrastructure à grande échelle.
Pour aller plus loin
Ce décalage entre standardisation d’un protocole et son adoption réelle sur le segment mutualisé, le plus contraint économiquement du marché de l’hébergement, illustre un schéma qui se reproduit à chaque évolution majeure de l’infrastructure web. Il invite à la prudence quand on évalue la vitesse à laquelle un nouveau standard, aussi prometteur soit-il sur le papier, se généralisera réellement sur l’ensemble du parc de sites WordPress existants, très hétérogène par nature.
