Calculer et apprécier les temps de chargement de page

Calculer et apprécier les temps de chargement de page

Prendre la parole sur le sujet, qui plus est sur un blog orienté développement (back ou front), n’est pas une chose facile. Cependant, je vais aborder une problématique souvent scrutée par les clients, que ce soit des profils marketing ou techniques : les temps de chargement de page.

Un peu d’historique

Le temps de chargement de page, c’est un vaste sujet sur lequel les clients peuvent avoir des inquiétudes. Pendant longtemps, le temps de chargement des sites internet était resté dépendant des performances de débit que l’on pouvait avoir chez soi (remember 56K). Mais aujourd’hui, avec les progrès qui ont été faits, avoir une connexion performante est une norme, et le sujet des temps de chargement a été reporté sur la façon dont le site a été construit.

Bien qu’on puisse retrouver des problématiques de débit avec les devices mobiles en connexion nomade (2G, 3G, Edge …), l’utilisateur est devenu sensible à l’optimisation du temps de chargement des pages : sensible à un tel point que beaucoup d’études ont montré les impacts du temps de chargement sur les visites, au niveau de la durée de visite, du taux de rebond et même au niveau des ventes faites sur le site.

Des sites de plus en plus lourds

La technologie aidant, il nous est possible aujourd’hui d’embarquer beaucoup plus de choses sur le site, dans le but d’offrir à l’utilisateur final une expérience plus complète. Mais à quel prix ? En 6 ans, le poids moyen des sites a quasiment triplé, passant d’une moyenne de 702Ko à 2332Ko (+232% d’évolution). La possibilité d’embarquer des typos, des images et des librairies au cœur de nos pages améliore l’expérience utilisateur, mais augmente sensiblement les temps de chargement. Paradoxalement, on se retrouve à dégrader cette expérience.

Les différentes étapes d’un chargement de page

Depuis 2012, le W3C (World Wide Web Consortium, principal organisme de normalisation) a déployé les informations de performance. L’idée étant de mettre à disposition les timings permettant de comprendre où et quand le site met du temps à se charger (DNS, redirection serveur, chargement du DOM, …) et ainsi l’optimiser et le réduire au maximum.

Ces informations ont été intégrées assez rapidement dans les outils de mesure. Cependant, comme il s’agit de données supplémentaires à traiter, par souci d’économie, les outils de mesure ne collectent pas cette donnée sur l’ensemble de l’audience. Les données sont échantillonnées et extrapolées, donc dépendantes d’un volume de trafic.

À titre d’exemple, Google Analytics n’échantillonne qu’à 1% son audience totale par défaut pour le mesurer. Celle-ci peut être configurée à 100% mais nécessite un paramétrage spécifique. Enfin, il existe des outils en ligne qui permettent de « noter » la performance d’un site, en termes de vitesse de chargement (Google PageSpeed Insight, …), où Lighthouse, qui est dans l’onglet « Audits » de la DevConsole Chrome. PageSpeed Insight est un outil Google qui pousse assez délibérément les éditeurs à adopter leur framework mobile : l’AMP doublé de la récompense de l’adoption de cette technologie sur le référencement.

Il est également important de noter que pas mal d’implémentations utilisent un outil de Tag Manager, donc les données de temps ne sont déclenchées et calculées qu’à l’exécution du script du Tag Manager. Ce comportement peut biaiser les données de timing. L’utilisation de performance.timing permet donc de baser sur des données embarquées dès l’appel de la page, sans dépendance de script.

Les différentes étapes d’un chargement de page

Afin de pallier aux problématiques d’échantillonnage et d’industrialiser la collecte d’un marqueur de temps qui soit fiable, nous avons mis en place un tout petit script qui permet de collecter l’information de « temps de chargement perçu par l’utilisateur » en se basant sur le schéma que nous avons vu juste au-dessus. L’idée est de calculer la valeur la plus pessimiste en faisant la différence entre le navigationStart et el LoadEventEnd, soit le timing le plus large possible, que l’on pourra affiner après.

Étant donné la quantité d’indicateurs de timings disponibles, il est très facile de créer des marqueurs spécifiques sur le processus de chargement, tel que le temps de réponse serveur, ou de redirection DNS… Le tout est de faire remonter cette donnée dans l’outil de mesure, afin d’avoir des moyennes de temps de chargement que l’on pourra recouper avec d’autres dimensions (comme les URLs).

Côté compatibilité, performance.timing est largement disponible, donc pas d’inquiétudes particulières sur des potentiels manque de données.

Réduire les temps de chargements : pourquoi ?

Avec les timings, il est maintenant facile de discerner à quel moment (technique) d’un chargement de page il y a un souci. Mais la vraie question serait de se demander quel est l’impact « réel » d’un chargement (trop) long, côté client final/performance. Nous avons cité rapidement quelques études en introduction sur les conséquences d’un temps de chargement élevé, pour finir par en détailler les conséquences.
Sur une étude menée par Ole Bossdorf (Head of BI chez Project A Ventures), l’auteur a mis en évidence la corrélation entre le temps de chargement de la première page et le taux de conversion du site, sur deux groupes d’entreprises de son portfolio (à taux de conversion comparables, dépendant de leur secteur d’activité).

Globalement, on va pouvoir catégoriser les impacts du temps de chargement d’un site en 3 grandes sections :
– L’impact sur la quantité des contenus consommés (pages vues par visite)
– L’impact sur la qualité des contenus consommés (taux de rebond)
– L’impact sur la performance du site (taux de conversion)

Également, Cliff Crocker, qui travaillait alors chez Walmart Labs, a publié une étude mettant en évidence cette corrélation en 2012 et les résultats étaient déjà assez clairs: on voit très clairement une chute notable du taux de conversion dès que le temps de chargement dépasse les 3 secondes.

SingleStone a fait une étude, ainsi qu’une batterie de tests plus poussée sur l’impact des temps de chargements, la perception de la marque et les comportements d’achat (ou de non-achat).

Enfin, Section, une plateforme de gestion de performance, s’est quant à elle penchée à travers son blog, sur l’impact du temps de chargement de page et sur le taux de rebond (la propension que l’utilisateur ne consulte qu’une seule page lors de sa visite), le nombre de pages vues et le chiffre d’affaires.

On note que la majeure partie des études sont menées par des acteurs qui proposent des solutions de performance. Utiliser ces incidences en tant qu’argument commercial est bien le signe de l’importance que revêt le temps de chargement pour les marques d’aujourd’hui.

Faire baisser les temps de chargement : un peu de concret

Maintenant qu’on a pu voir l’importance du temps de chargement, il serait intéressant de voir comment faire baisser ce temps, afin de globalement optimiser l’expérience des utilisateurs sur le site.

On a évoqué plus haut Google Page Speed Insight, outil de Google permettant d’avoir un mini audit d’une page. Ce n’est pas le seul outil: on peut citer Pingdom et GTMetrix qui permettent également d’avoir des insights sur la façon d’optimiser une page. Ces outils ont tous le même principe de fonctionnement, à quelques features près. Par exemple, GTMetrix permet de choisir une localisation de serveur test pour mécaniquement augmenter les temps de réponse serveur.

Cependant, on retrouve toujours plus ou moins les mêmes optimisations recommandées par les différents outils. Voici la liste (non-exhaustive) des bonnes pratiques pour optimiser sensiblement son temps de chargement de page.

– Optimiser le temps d’affichage des premiers éléments visibles:
L’idée principale de cette recommandation est de permettre à la page d’afficher le plus rapidement possible des éléments visibles de la page. Elle se matérialise le plus souvent par une priorisation des fichiers CSS, considérant les styles des premiers éléments visibles comme prioritaires, et le reste non. Concrètement, pas mal d’outils conseillent d’inliner le CSS des éléments au-dessus de la ligne de flottaison, pour que le moteur de rendu les affichent « correctement » dès le chargement de la page.

– Compresser les fichiers HTML/CSS/JS
Bon, là c’est du classique, l’idée est de virer les caractères inutiles d’un code, quelque soit le langage pour que la machine l’interprète plus vite. On oublie souvent que le code est généré par des humains face à une problématique de lisibilité. Ce n’est pas le cas de la machine … En termes de solution, une palanquée d’outils existent, pour ne citer que Compress My Code.

– Compresser correctement les images
Là encore, un grand classique. L’idée étant de réduire la taille finale d’une image, en faisant en sorte d’avoir un rendu final correct, le rendu visuel étant pour le coup important. Il existe différents algorithmes de compression de données, certains sans pertes, d’autres avec. Il est important de noter que la compression sans perte est plus utile pour préserver une précision d’image importante (donc utile pour les images qui nécessitent une interprétation/une analyse). D’autres scripts entraînent une faible perte, ce qui permet de faire baisser le poids des images sans en altérer la qualité de manière trop excessive. Parmi les outils en ligne, compressor.io est un compresseur en ligne de bonne qualité.

– Optimiser la mise en cache
Sur cette recommandation, on parle de cache navigateur, cet espace de « mémoire-tampon » qui permet de stocker des informations de la page ou de l’application pour ne pas avoir à les chercher plus tard, sur un rechargement. Plusieurs méthodes sont possibles pour activer cette mise en cache. Sur les CMS récents, des plugins sont disponibles et efficaces. On peut également faire des règles de mise en cache directement sur .htaccess grâce à mod_headers, un module Apache généralement disponible sur les infras web. Ce module fournit des directives permettant de contrôler et modifier (fusionner, remplacer ou supprimer) les en-têtes de requêtes et de réponses HTTP. Grâce à lui on peut créer des règles dans .htaccess.

Dans ce cas de figure, on a les fichiers images qui sont cachés pour une durée d’une semaine, et les JS et CSS pour un mois.

Il s’agit là des optimisations les plus souvent sollicitées dans Lighthouse, avec un point d’honneur sur le temps d’affichage des premier éléments rendus, qui fait désormais partie des critères de ranking du moteur de recherche.

Pensées de fin

Bien qu’un peu détachée des problématiques de développement, l’équipe data peut typiquement réfléchir et identifier ce genre d’indicateurs de temps de chargement sur les projets. On garde toujours en tête que nos métiers sont complémentaires et que ce genre d’exemples peuvent trouver d’autres champs d’application pour améliorer la qualité de nos plateformes.