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.
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 :
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 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
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.
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 :
Figure 5 : temps de requête/réponse d'une page de navigateur
La figure ci-dessus montre les éléments qui composent le TTFB (Time To First Byte) :
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.
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.
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.
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 :
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.
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.