Dans l’histoire de la web performance, le Load Time fait partie des premiers indicateurs qui ont permis de mesurer le temps de chargement des pages web. Puis d’autres KPI ont fait leur apparition pour évaluer la perception de vitesse tels que le Speed Index, le Time To Interactive… remisant le Load Time sur une étagère un peu poussiéreuse au fond du cagibi. Retour sur cette métrique webperf qui a joué un rôle important mais qui ne suffit plus pour évaluer la vitesse de votre site, et nous allons voir pourquoi.
Qu’est-ce que le Load Time
En théorie, le Load Time est une métrique webperf qui permet de connaître le temps nécessaire à une page web pour se charger totalement. En cela, il diffère du Speed Index qui permet de mesurer le temps de chargement des éléments au-dessus de la ligne de flottaison.
La durée de chargement exprimée par le Load Time commence au moment où l’internaute envoie la requête, et elle prend fin quand tous les éléments sont téléchargés, les scripts JavaScript exécutés, les CSS analysés, et les images non lazyloadées rendues. Entre ces deux événements, voici ce qui se passe :
- L'internaute saisit une URL ou clique sur un lien
- Le navigateur envoie une requête au serveur
- Le serveur traite la requête
- Le serveur envoie une réponse au navigateur
- Le navigateur commence à recevoir la page (cet événement est marqué par le TTFB)
- Le navigateur analyse, charge et affiche le contenu
- Et enfin… la totalité de la page est disponible, la roue sur la barre d’adresse s’arrête de tourner.
Que se passe-t-il quand la page a fini de se charger ? L’événement JS Load de l’objet window est déclenché.
Nous évoquions en introduction la dimension théorique du Load Time, et vous la comprendrez peut-être d’autant mieux à présent. Comme nous venons de le voir, au moment où l’événement On Load est généralement déclenché, les bannières de cookies s’affichent, les publicités et élément de tracking s’activent, les contenus multimédias se lancent…
Ainsi, il s’agit bien d’une évaluation théorique du temps de chargement complet, puisque comme nous venons de le voir, au moment où l’événement On Load est déclenché (que nous allons aborder un peu plus tard dans le waterfall), la page n’a en réalité pas totalement fini de se charger.
Pourquoi le Load Time était important, et pourquoi il ne l’est plus
A partir de 2010, des APIs sont nées permettant de collecter des données sur les temps de chargement dans les navigateurs (Performance Timing a évolué vers Navigation Timing en 2012). Au fil du temps, les métriques se sont concentrées sur la perception de vitesse pour mieux représenter l'expérience utilisateur.
Pour une meilleure UX, vous pouvez optimiser votre Front-End et ainsi, d’une part alléger vos pages pour qu’elles se chargent plus rapidement, mais aussi hiérarchiser l’ordre d’apparition du contenu ou la façon dont il se charge afin d’améliorer la perception de vitesse.
Par exemple : vous pouvez indiquer au navigateur comment charger le JavaScript et les images, mettre en cache des éléments statiques pour rendre leur affichage plus rapide…
Vous pouvez aussi différer le chargement du JavaScript, et du coup augmenter votre Load Time, mais le contenu de la page (hors JavaScript, donc) pourra s’afficher plus tôt et ainsi améliorer cette perception de vitesse.
Dans l’absolu, plus les contenus pertinents sont disponibles rapidement pour vos utilisateurs, plus leur engagement sera fort. C’est l’une des raisons pour lesquelles ce qui se passe au-dessus de la ligne de flottaison est primordial.
Pourquoi ? Parce que ce qui compte en termes d’UX, c’est la vitesse à laquelle les éléments pertinents sont visibles dans le viewport (et encore mieux : cliquables !), et c’est justement ce que le Speed Index et le First Contentful Paint (FCP) permettent de mesurer, bien mieux que le Load Time.
Ainsi, prendre en compte uniquement le temps de chargement complet d’une page n’a que peu d’intérêt et ne peut pas être une base de travail pertinente pour améliorer votre expérience utilisateur.
Comment mesurer le Load Time ?
WebPageTest permet de mesurer le Load Time qui s’exprime en secondes. Cette métrique est présente tout en haut du waterfall, et symbolisée dans ce même waterfall par une ligne bleu foncé qui indique le chargement complet de la page (Document Complete).
Comme la plupart des KPI webperf, le Load Time dépend de votre serveur et de la bande passante dont vous disposez, du design de votre page, son poids, la façon dont elle est conçue… Mais aussi la zone géographique de l’internaute, son équipement, son navigateur, et du nombre de Third Parties et de leur temps de réponse…
Load Time : comment vous situer ?
Selon HTTP Archive, qui évalue l’état du web, le onLoad moyen en 2020 est de 18,5 s sur mobile et sur 7 s sur desktop. Cette différence s’explique évidemment par le fait que les processeurs sont moins puissants sur mobile et que la qualité du réseau n’est pas toujours au rendez-vous.
Cet écart entre mobile et desktop est encore plus grand que pour d’autres indicateurs puisqu’il s’agit de charger non seulement les éléments au-dessus de la ligne de flottaison, mais bien l’intégralité de la page. Il peut donc y avoir du pain sur la planche si les pages proposent beaucoup de contenu et de scripts tiers.
Malgré tout, même si cette métrique n’est pas la plus importante pour évaluer la vitesse de votre site - et elle ne devrait en aucun cas être la seule pour les raisons que nous venons d’évoquer -, voyons comment l’améliorer.
Comment améliorer le Load Time ?
Pour que vos pages se chargent plus rapidement, voici quelques astuces essentielles que vous pouvez appliquer :
- compressez vos fichiers HTML, images, JavaScript… pour réduire leur taille ; minifiez, ou selon les cas scindez, vos fichiers CSS et JavaScript;
- limitez les Third Parties, chaque contenu qui doit être récupéré chez un tiers demande davantage de temps à votre navigateur pour chercher et afficher les données ;
- utilisez un CDN pour rapprocher le contenu de vos utilisateurs ;
- diminuez le nombre de requêtes ou préchargez celles qui sont les plus critiques ;
- préchauffez votre cache.
Soulagez vos équipes techniques,
automatisez l'application de ces optimisations webperf !
Mesurez les effets de notre moteur sur la vitesse d'affichage de vos pages :
