Tester les performances d’un client web

Published in

Leanovia

5 min readMar 17, 2021

Le paysage applicatif et les stacks techniques ont largement évolué ces dernières années. Par ces évolutions, les tests de performances, couramment exécutés côté serveurs, garantissent toujours une certaine sécurité en évitant les incidents en production mais peuvent se montrer insuffisants pour garantir une bonne expérience utilisateur.

Le temps d’attente ressenti par les utilisateurs est majoritairement dû à deux facteurs :

Les temps de réponses de l’application :Cela inclut le téléchargement du contenu statique, les requêtes visant à récupérer des données métiers et tout ce qui engendre un traitement du coté du serveur d’application.
Les temps de traitement coté client : Cela inclut non seulement le temps d’affichage des contenus téléchargés mais également l’évaluation et l’exécution des fichiers javascript.

Dans le cas des tests de charge, même si ils ne sont pas toujours implémentés, ils font de plus en plus partie des bonnes pratiques au sein des DSI et prennent de plus en plus de place au sein du cycle de vie applicatif. Dans le cas de l’analyse des performances côté client, ils se font beaucoup plus rares bien qu’ils puissent grandement améliorer le ressenti des utilisateurs. C’est donc précisément ces tests que nous allons évoquer.

Comment évaluer les performances de mon application ?

Pour une première estimation des performances d’un client web, il est plus commode d’utiliser les outils déjà présents sur votre poste. Pour cela l’outil Lighthouse fournit un premier aperçu complet des performances de votre application.

En plus de vérifier les normes d’accessibilités, les SEO ainsi que le respect des bonnes pratiques, Lighthouse permet de générer un rapport présentant des métriques significatives pour les utilisateurs :

First Contentful Paint : Le temps d’affichage des premiers éléments visibles par l’utilisateur.
Speed Index : Le temps d’affichage global de tout ce qui est visible par l’utilisateur.
Time to Interactive : Temps nécessaire pour que l’utilisateur puisse interagir avec la page.

L’outil fournit également des recommandations et pointe les différentes opportunités à saisir pour améliorer les performances.

Sur les sites accessibles depuis internet, il est également possible de faire les mêmes tests depuis l’application PageSpeed Insight développée par Google.

Tester les Single Page Application (SPA)

Dans le cas d’une SPA, il peut être impossible d’utiliser Lighthouse car celui-ci recharge la page pour récolter les métriques. D’autres outils d’analyse sont disponibles, et parmi eux, Sitespeed.io répond parfaitement à ce besoin.

Sitespeed.io nous permet d’incorporer des scripts qui simuleront la navigation de l’utilisateur ce qui nous permet d’accéder à une partie précise de l’application dans le cas d’une SPA. Sitespeed.io est composé de plusieurs outils, dont :

Browsertime : C’est le coeur même de la solution, c’est cet élément qui permet de récupérer les métriques relatives aux performances (Speed index, First contentful paint, etc…).
Coach : Qui dispense des conseils pour améliorer votre site web tant sur les performances, l’accessibilité que sur sa politique de confidentialité.

Pour améliorer directement les performances de votre application web, le coach pourra détecter automatiquement des éléments problématiques, par exemple :

Les tâches consommant trop de temps CPU.
Les ressources devant être optimisées.
Les politiques de cache à modifier.

Utilisation

Application classique

En admettant que vous vouliez lancer sitespeed.io à l’aide de podman (ou docker), vous pouvez lancer un scan avec la commande suivante :

Exemple de commande Podman permettant de lancer Sitespeed.io.

Single Page Application

Dans ce cas, il faudra exécuter un script javascript qui simulera l’activité de l’utilisateur comme ci-dessous:

Exemple de script permettant de parcourir l’application.

On démarrera le test avec la commande :

Exemple de commande podman permettant de lancer le script définit précédemment.

Résultats

Les commandes Podman indiquent que les rapports sont générés dans le dossier ‘/sitespeed’ du répertoire courant au format html.

à partir de ces résultats on peut :

Récupérer les métriques de performances.
Télécharger les traces HAR.
Accéder aux recommandations du Coach.

Dans le cas de notre test, le coach nous conseille automatiquement de :

Redéfinir explicitement la taille des images.
Changer la politique de chargement des scripts JS pour éviter un bloquage de l’affichage du contenu.
Optimiser la politique de cache.
Et d’autres conseils…

Pour chacun de ces conseils, le coach liste également les ressources concernées. Les différentes recommandations ne sont pas toujours applicables en fonction des singularités de votre application, elles permettront néanmoins de donner différents axes d’améliorations aux développeurs.

Autres applications de Sitespeed.io

Sitespeed.io peut également être utilisé comme un agent de supervision active. Dans un prochain article, on détaillera comment utiliser l’outil comme une sonde. On supervisera les performances d’une application en stockant et visualisant ces métriques dans Graphite et Grafana au sein d’un environnement Kubernetes.

Conclusion

De nombreux outils sont disponibles pour tester les performances des applications web. Avec ces scans, il est possible de définir rapidement des axes d’améliorations pour fournir une expérience utilisateur toujours meilleure.

TL ; DR

Sur les applications utilisant des frameworks javascript, les tests de charges classiques ne sont pas suffisants pour assurer une bonne expérience utilisateur. Il est à ce moment intéressant d’utiliser des outils comme :

Lighthouse et les outils développeurs Google en général.
Sitespeed.io qui permet de mener des audits plus approfondis notamment sur les SPA.
PageSpeed : Qui permet de mener des audits sans installer d’outil, seulement sur des pages visibles depuis internet.