HTTP/3 est officiel ! Quel impact sur la performance web ?

HTTP/3 est officiel ! Quel impact sur la performance web ?

Le protocole créé par Google longtemps intitulé “HTTP-over-QUIC” est officiellement renommé HTTP/3. Ce changement de nom est loin d’être anecdotique, car il s’accompagnera vraisemblablement dans un futur proche de son officialisation dans le standard HTTP. Dans cet article nous vous expliquons à quoi il correspond techniquement et les impacts auxquels vous pouvez vous attendre sur votre performance web. TCP/2 plutôt que HTTP/3 ? La nouveauté principale apportée par HTTP/3 c’est la possibilité d’utiliser QUIC plutôt que TCP pour échanger des messages HTTP. Qu’est-ce donc que le protocole QUIC ? Et qu’a-t-il de plus que nos bons vieux TCP et UDP ? TCP c’est le protocole de la couche transport le plus utilisé de nos jours en raison de sa fiabilité. En contrepartie, il s’accompagne d’une certaine lourdeur dans les phases d’établissement de connexion. UDP quant à lui n’apporte aucune garantie de fiabilité, mais n’a pas de phase d’établissement de connexion. QUIC est en quelque sorte une version de UDP plus complète, dont les garanties : fiabilité, vérification des erreurs, ordres des paquets sont équivalentes à celle de TCP. De plus le protocole TCP comporte de nombreuses fonctionnalités qui n’ont plus vraiment de sens de nos jours, et qui l’alourdissent inutilement.   “QUIC win” pour la performance web? D’un point de vue de la performance de vos pages web, les gains principaux se situeront à deux niveaux. D’une part, la phase d’établissement de connexion sera supprimée ce qui aura tendance à améliorer le temps de connexion (premier segment sur l’exemple appYuser) ainsi que le temps d’affichage (quatrième segment), notamment sur les sites qui utilisent de nombreuses ressources externes. D’autre part,...
Comment réduire le nombre de scripts bloquants dans vos pages web ?

Comment réduire le nombre de scripts bloquants dans vos pages web ?

On appelle scripts bloquants ou en anglais render-blocking script tous les fichiers JavaScript dont le chargement ou bien l’exécution perturbent le rendu d’une page web. Pour mieux comprendre cette définition, il convient de rappeler quelques notions sur le fonctionnement de JavaScript. Par défaut, lorsque l’interpréteur HTML rencontre un fichier JavaScript il s’arrête de réaliser le rendu de la page et passe la main à l’environnement d’exécution JavaScript. Le rendu ne reprend que lorsque l’exécution du script est terminée. C’est un comportement assez logique, JavaScript a en effet la capacité d’agir sur les éléments de la page, il serait donc incohérent de continuer le rendu alors qu’un script est potentiellement en train de l’altérer. Cet article vous présentera quelques méthodes vous permettant d’éliminer les scripts bloquants de vos pages web ou au moins d’en réduire l’impact sur la satisfaction de vos utilisateurs. Quel impact sur les performances web ? Un nombre de scripts bloquants important aura bien souvent tendance à détériorer la satisfaction utilisateur. Aussi importants soient-ils pour le bon fonctionnement de votre page web, leur exécution n’est pas forcement visible par l’utilisateur. En revanche il remarquera facilement que le rendu est bloqué. En effet, le blocage du rendu peut provoquer deux effets néfastes pour la satisfaction de l’utilisateur. D’une part, il est possible que le début d’affichage soit retardé, provoquant de longues secondes d’attente devant une page blanche. D’autre part, le rendu de la page pourra être saccadé, alternant entre phases ou le rendu est fluide et phases ou le rendu est figé. Dans les deux cas, et en se basant sur notre norme de mesure de la satisfaction utilisateur, on...
Que faut-il retenir de la dernière mise à jour de Page Speed Insights ?

Que faut-il retenir de la dernière mise à jour de Page Speed Insights ?

PageSpeed Insights (PSI), le très populaire outil d’audit des performances de page web en ligne de Google a reçu en ce début d’année 2018 une mise à jour majeure. Depuis toujours centré sur le respect des “bonnes pratiques” pour établir son score d’optimisation, PSI prendra désormais en compte des données provenant d’utilisateurs réels. Que contient exactement cette mise à jour ? Quel impact aura-t-elle sur le monde de la performance web ?  La vitesse réelle du site au cœur de la mise à jour Le point clé de cette mise à jour est l’ajout d’un niveau de vitesse en plus du score d’optimisation historique. L’évaluation de ce niveau est réalisé grâce à des statistiques sur les temps de chargement enregistrés par de vrais utilisateurs. Deux mesures sont prises en compte : First Contentful Paint (FCP) : Temps d’affichage du premier élément visuel de la page DOM Content Loaded (DCL) : Temps que met le HTML de la page à être chargée et parsée Chaque utilisateur se connectant à la page (depuis Google Chrome) générera donc de nouvelles données temporelles. C’est en prenant la valeur médiane de ces deux séries statistiques puis en les combinant que le niveau de vitesse est obtenu. De plus, les résultats du test proposent désormais une visualisation de la distribution des temps obtenus par les utilisateurs. Les données sont ensuite classées en trois catégories suivant les événements obtenus dans le rapport d’expérience utilisateur de Chrome : Rapide, Moyen et Lent           Copie d’écran 1 – Analyse PageSpeed Insights du site lemonde.fr Dans l’exemple ci-dessus, le site testé a un FCP median à...
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 à...
Feature appYuser – Courbe taux de conversion en fonction des temps d’affichage

Feature appYuser – Courbe taux de conversion en fonction des temps d’affichage

Tout le monde s’accorde à dire que la vitesse d’affichage des pages a un impact fort sur le taux de rebond et par conséquent sur le taux de conversion. Cela n’était plus à prouver mais à chiffrer !  De nombreuses études très sérieuses le prouvent, vous pouvez notamment lire un certain nombre de cas réels chiffrés chez notre partenaire Akamai. Nous avons sur la base de données réelles modélisé dans appYuser la courbe d’évolution du taux de conversion en fonction des temps d’affichage des pages. Il est ainsi possible d’évaluer le manque à gagner et l’effort pour revenir à un taux de conversion optimal ! Sur la base des données que nous recueillons, il nous est possible de compter le nombre de fois où la page s’est affichée par exemple entre 5 et 6 secondes et d’évaluer le taux de conversion correspondant (nous proposons des modèles en fonction des secteurs d’activité ou bien la courbe peut être étalonnée par nos clients avec leurs données spécifiques). L’exemple ci-dessous montre une page avec des performances quasi optimales de conversion. L’exemple suivant montre une page avec des performances trop souvent critiques et un taux de conversion plus faible. L’exemple ci-dessous montre une page avec des performances critiques et un taux de conversion très faible. L’étape d’après : Le module de diagnostic appYuser permet ensuite de proposer des améliorations très simples, priorisées par la valeur, pour revenir au juste effort dans une zone de conversion plus favorable. Le ROI est parfois spectaculaire ! Ce ROI est évalué avant de se lancer dans une phase d’optimisation, il est fonction du rapport de 2 critères (Potentiel d’amélioration du...