L'expérience utilisateur (UX) est une dimension essentielle de toute plateforme numérique. Si les utilisateurs apprécient la manière dont ils interagissent avec un produit ou un service, que ce soit en ligne ou dans le monde réel, il y a de bonnes chances pour qu'ils l'utilisent plus souvent et le recommandent autour d'eux. En matière d'expérience utilisateur sur les sites web ou sur tout autre type de plateforme numérique, la vitesse joue un rôle essentiel (voire primordial) au sein des principales caractéristiques comme l'accessibilité, la clarté et le plaisir (voir fig. 1). Des temps de réponse prolongés peuvent amener les utilisateurs à détourner leur attention et parfois même à abandonner le processus que vous souhaitiez les voir réaliser.
Figure 1 : éléments importants de l'UX
La vitesse et la réactivité sont essentielles non seulement du point de vue des visiteurs, prospects ou clients, mais également du point de vue des fonctions support comme les rédacteurs de contenus ou les webmasters. Pour ces derniers, tout retard au sein du système a une incidence non seulement sur leur propre productivité mais également sur certaines activités commerciales clés : pensons simplement au lancement d'une campagne marketing ou à la mise à niveau des spécifications d'un produit, activités pour lesquelles la date de publication des contenus est cruciale.
Définir la performance web
Dans la plupart des projets, la performance web est définie dans la liste des exigences techniques. Pourtant, la définition des performances recherchées pour une application web peut représenter un véritable défi et nécessiter une bonne communication entre les différentes parties prenantes.
La performance d'un site web pourrait être spécifiée tout d’abord ainsi :
Tous les pages du site devraient être chargés en moins de 2 s
Cette exigence est loin d'être optimale. Pour pouvoir être utilisée comme une exigence technique valable, la définition de la performance web doit être plus précise et plus stricte, et il convient de tenir compte des différents éléments qui influencent son analyse :
- Par exemple, le temps de chargement de la page web est ralenti par une mise à jour récente des contenus qui doivent être à nouveau présentés et enregistrés dans la mémoire cache. Par contre, le chargement d'une page à partir du cache garantit une meilleure performance dans la mesure où les informations sont chargées beaucoup plus rapidement, même s'il s'agit de la même page.
- La qualité du réseau de l'utilisateur doit également être prise en considération. Avec une connexion plus lente, les contenus mettent plus de temps à charger. Même si cela n'est pas lié directement à la performance du site web, cela affecte malgré tout l'expérience utilisateur.
- Le moment où l'on considère qu'une page est « chargée » n'est pas exactement défini, cela dépend donc des critères utilisés.
Vu le nombre de facteurs qui entrent en ligne de compte, il convient plutôt de prendre en considération la forte dispersion des temps de chargement et d'en tenir compte pour définir les exigences en matière de performance (voir fig. 2).
Figure 2 : répartition des temps de chargement d'une page web (source : Google)
En conséquence, une définition plus ciblée pourrait être la suivante :
« L'indice de vitesse pour 95 % des chargements de la page devrait être de 3 s avec une connexion rapide 3G (25 Mbps). L'indice de vitesse pour les 5 % restants de la page devrait être inférieur à 6 s avec le même type de connexion. »
Cette définition permet d'analyser les tests de performance de manière bien plus précise et de limiter les discussions superflues.
Dans la définition ci-dessus, l'indice de vitesse représente la vitesse moyenne à laquelle les parties visibles de la page sont affichées (exhaustivité visuelle). Il tient compte de la performance perçue par l'utilisateur et renseigne ainsi sur l'expérience utilisateur.
Dans la figure 3 ci-dessous, la partie visible du site Internet s'affiche entièrement au bout de 445 ms et l'utilisateur peut commencer à l'utiliser ou à interagir avec les contenus. Pendant ce temps, le reste de la page est chargé sans déranger l'utilisateur.
Figure 3 : différentes étapes du processus de chargement de la page
Mesurer les performances
Le temps total de chargement est conditionné non seulement par le temps nécessaire pour livrer les contenus de la page depuis le serveur web vers le navigateur, mais également par l'efficacité avec laquelle le navigateur est capable de présenter les contenus de la page.
Lorsqu'on parle de performances web, on distingue généralement deux domaines : d'un côté les performances front-end, qui se rapportent à tous les éléments du processus de chargement de la page directement associés au rendu du navigateur, de l'autre, les performances back-end, qui concernent les opérations exécutées par le serveur pour générer les contenus de la page.
Performances front-end
Bien entendu, les performances front-end tournent autour du téléchargement des fichiers HTML, CSS et JavaScript et de la combinaison de ces ressources pour présenter la page de manière à ce que le visiteur puisse y accéder et interagir avec ses contenus.
De nos jours, de nombreux outils sont disponibles pour mieux contrôler ces processus. Ces outils fournissent des informations précises sur la manière dont le navigateur exécute le processus de rendu de la page. Un exemple bien connu est Chrome DevTools (voir fig. 4), qui permet non seulement de visualiser la structure de la page mais offre également une bonne vision du processus de téléchargement des ressources par le biais du réseau, y compris la simulation de différentes vitesses de réseau.
Figure 4 : Chrome DevTools
Notre expérience montre que les éléments suivants sont les principaux freins aux performances front-end :
- Taille de fichier importante : les images représentent souvent le plus grand volume de données chargées sur un site web. La compression et/ou compilation des images, JavaScript et les feuilles de style peuvent considérablement diminuer la taille des fichiers et réduire ainsi les temps de téléchargement.
- Nombre important de ressources intégrées (images, JavaScript, feuilles de style, etc.) : chaque ressource intégrée consomme un certain temps système à la connexion, à la gestion de file d'attente, aux requêtes DNS, etc. (voir fig. 5). Cette consommation peut être réduite en combinant ou en éliminant des ressources intégrées.
- Ressources bloquant le rendu de la page (chemin critique du rendu ralenti) : ces ressources intégrées empêchent la construction du DOM (Document Object Model) et le rendu de la page. Une réduction de ces ressources peut améliorer considérablement la vitesse du site web en permettant au visiteur de visionner et d'interagir plus rapidement avec le contenu de la page (indice de vitesse).
- Mauvais réglage du cache : rendus et téléchargements superflus peuvent être éliminés par des réglages optimisés du cache provoquant réduction des temps de latence et amélioration des performances.
Figure 5 : temps de requête/réponse d'une page de navigateur
Performances back-end
La figure ci-dessus montre les éléments qui composent le TTFB (Time To First Byte) :
- Latence de connexion
- Vitesse de connexion
- Temps nécessaire pour que le serveur rende et présente les ressources
Si la valeur du TTFB du document HTML principal est élevée (Google recommande de la maintenir en-deçà de 200 ms), notre intérêt doit se porter sur les performances du serveur web. L’optimisation du back-end peut être requise.
Les facteurs influant sont alors :
- optimisation du processus de rendu de la page dans le CMS
- nouvelle configuration des composants logiciels au niveau inférieur de la pile du serveur (conteneur d'application, base de données, mise en antémémoire back-end, etc.)
- restructuration de l'infrastructure matérielle (équilibrage de charge, etc.)
Quelques mots sur la mise en antémémoire
La mise en antémémoire est souvent utilisée pour masquer les faibles performances back-end. Parfois efficace, cette méthode n’est pas généralisable. Par exemple elle n’est pas la solution si la page demandée n'est pas (encore) chargée dans le cache ou si des contenus personnalisés sont nécessaires pour répondre à la requête (pensons aux visiteurs authentifiés ou aux rédacteurs de contenus).
Pour cette raison, la mise en antémémoire devrait être utilisée uniquement pour améliorer un système qui fonctionne déjà bien. Un exemple de bon emploi est l'introduction d'un cache proxy inverse comme Varnish pour traiter des pointes de trafic très importantes et minimiser la charge sur l'infrastructure back-end.
Test de charge
Les tests de performance devraient être effectués de manière continue et automatisée dès les premières étapes de la construction d'une application pour prévenir les mauvaises surprises au cours du projet.
Lorsque l'on prend des mesures d'optimisation des performances sur une application existante, il est essentiel de contrôler les progrès en réalisant des tests de performance avant et après chaque modification effectuée.
Dans tous les cas, il est important de définir précisément l'objectif du test de performance : ce qui doit être testé exactement et dans quelles conditions.
Exemple : test de charge avec JMeter
Supposons qu’on analyse le temps mis par le système back-end pour générer des pages souvent consultées par 500 utilisateurs simultanés en moyenne. On ne s’intéresse ni au processus de rendu du navigateur ni à la vitesse/latence de connexion. Apache JMeter est alors un bon outil pour ce test de charge.
Dans cet exemple précis, nous tenons compte de ce qui suit :
- Consulter l'outil d'analyse (le cas échéant) pour savoir quelles sont les pages les plus consultées. Ces pages peuvent être incluses dans le scénario de test de charge.
- Exécuter le test de charge sur la même infrastructure matérielle que celle de production afin d'éliminer l’influence de la qualité de connexion sur les résultats.
- Configurer JMeter de manière à ne pas télécharger les ressources intégrées (images, CSS, etc.), dans la mesure où nous nous intéressons seulement à l'efficacité du back-end sur le rendu HTML.
- Vérifier dans l'outil d'analyse le temps passé par les utilisateurs sur le site web et le nombre de pages consultées pendant leur session. Déduire de ces données la durée moyenne de visite d’une page web et ajouter un minuteur JMeter en conséquence.
La manière dont nous configurons l'outil de test de charge est essentielle pour obtenir des résultats représentatifs et tirer des conclusions correctes.
Conclusion
L'expérience utilisateur est un facteur distinctif grandissant pour les entreprises. En conséquence, la performance des plateformes numériques devient également de plus en plus importante pour les sites web et les applications. Il est alors essentiel de définir sans ambiguïté des exigences et d’automatiser des tests de charge afin de vérifier les performances à différentes étapes du projet.
Cet article nous a donné l'occasion d'identifier différents facteurs qui influencent les performances, en distinguant les performances front-end et back-end des sites web. Les problèmes de front-end sont généralement moins difficiles à identifier et à résoudre que les problèmes de back-end, dans la mesure où ces derniers nécessitent des connaissances approfondies dans différents domaines (comme la maîtrise en matière de CMS utilisé, d'infrastructure matérielle ou de pile d'applications) pour mener correctement l'audit des performances.
Updated