Nous avons récemment déployé le protocole HTTP/2 chez un de nos clients en l’activant depuis leurs plateformes Akamai. Nous vous faisons profiter des résultats. Sans HTTP/2 Ci-dessous le waterfall très coloré de notre client avant HTTP/2 : Rouge : la ressource est bloquée Violet : résolution DNS Bleu : la ressource est en attente Vert : la ressource est en réception On observe des temps de blocage de plus en plus importants à mesure qu’on avance dans le temps (barres rouges). Avec HTTP/2 Le même extrait du waterfall de notre client avec HTTP/2 : Le multiplexage HTTP/2 est bien en place, ça marche ! Nous n’avons plus aucun temps de blocage et un affichage optimisé de la page. Reste maintenant à évaluer l’impact réel sur le ressenti utilisateur pour tous les contextes et usages grâce à appYuser. La ligne bleue correspond à l’événement DOM Content Loaded. Lire aussi : HTTP/3 est officiel ! Déploiement HTTP/2 avec Akamai : cas client was last modified: février 8th, 2019 by Aurélien...
HTTP/2 est une mise à jour du protocole HTTP qui vise à l’adapter au web moderne. En effet, ce protocole n’avait plus beaucoup bougé depuis 1999 et sa version 1.1, contrairement au web qui lui a énormément évolué. Pour répondre aux besoins d’internautes toujours plus exigeants, les pages sont de plus en plus lourdes et complexes. En 2016, une page effectuait en moyenne 100 requêtes (contre 80 en 2011) et pesait environ 2,1 Mo (800 Ko en 2011). A la base le protocole n’avait pas été conçu pour supporter des contenus aussi volumineux et complexes. Il était donc temps de faire quelque chose pour conserver des performances acceptables. Un peu plus de 2 ans après sa publication officielle, HTTP/2 tient-il vraiment ses promesses ? HTTP/2 vs HTTP 1.1 Le principal problème de HTTP 1.1 résidait dans sa gestion des connexions et des requêtes. Une connexion = Une requête = Une ressource. On doit ouvrir une connexion à chaque nouvelle requête, et faire une nouvelle requête pour chaque ressource. Ce fonctionnement a tendance à rallonger les temps de chargement puisque chaque requête doit attendre que la requête précédente soit complétée. Pour éviter les blocages, les navigateurs ouvrent plusieurs connexions concurrentes (généralement 6). Bien que ce soit une amélioration notable, on est encore très loin des 100 requêtes moyennes de nos sites récents. De plus, il ne s’agit pas non plus d’augmenter infiniment le nombre de connexion concurrentes puisque cela pourrait provoquer de la congestion TCP et pénaliser les autres applications. Ce fonctionnement a poussé les développeurs à utiliser de nombreux contournements pour réduire au maximum le nombre de requêtes. Certes plutôt efficaces, ils allaient bien souvent à...
Nous utilisons des cookies pour améliorer votre experience de navigation sur le site. Cookie settingsACCEPTER
Cookies et confidentialité
Privacy Overview
Ce site utilise des cookies pour améliorer votre expérience de navigation sur le site. Hors de ces cookies, les cookies classés comme nécessaires sont stockés dans votre navigateur car ils sont aussi essentiels au fonctionnement des fonctionnalités de base du site. Nous utilisons également des cookies tiers qui nous aident à analyser et à comprendre comment vous utilisez ce site. Ces cookies ne seront stockés dans votre navigateur qu'avec votre consentement. Vous avez également la possibilité de désactiver ces cookies. Toutefois, la désactivation de certains de ces cookies peut avoir une incidence sur votre expérience de navigation.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.