Déploiement HTTP/2 avec Akamai : cas client

Déploiement HTTP/2 avec Akamai : cas client

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...
Devez-vous passer en HTTP/2 pour améliorer vos performances web ?

Devez-vous passer en HTTP/2 pour améliorer vos performances web ?

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 à...