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 les performances de vos services web ?

Devez-vous passer en HTTP/2 pour améliorer les performances de vos services 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...
Features appYuser : Mobile vs Desktop et aide au choix du T

Features appYuser : Mobile vs Desktop et aide au choix du T

Mobile vs Desktop : qui vit la meilleure expérience ? Il est désormais possible de visualiser la satisfaction utilisateur en fonction du type de périphérique utilisé : depuis un mobile ou un ordinateur. Cela permet de cibler très facilement les cas d’usages qui posent problèmes. L’exemple ci-dessus met en évidence une expérience utilisateur moins bonne lorsque les utilisateurs se connectent depuis des mobiles.   Comment choisir le temps d’affichage optimum de vos pages Web ? L’évaluation des niveaux de satisfaction de vos utilisateurs est directement liée au choix du temps cible T (Norme Apdex), temps qui correspond à l’affichage complet de la page sur le poste de l’utilisateur. Nous avons mis à votre disposition une aide en ligne qui permet de définir ces temps cibles en fonction des typologies de vos pages mais aussi en s’appuyant sur des études comportementales des internautes et surtout sur nos retours d’expériences clients. L’aide en ligne est accessible dans la configuration de votre site. En face de T par défaut, il vous suffit de cliquer sur le point d’interrogation. Features appYuser : Mobile vs Desktop et aide au choix du T was last modified: avril 21st, 2017 by Aurélien...