Les technologies de développement Web ont beaucoup évolué durant les 30 dernières années. Les pages Web des sites des années 90 étaient surchargées d’images et le contenu était très condensé. Les navigateurs n’avaient pour rôle que d’afficher les pages qui étaient envoyées par le serveur Web.
Voici comment la structure simple d’une application Web des 90’
Ici, le navigateur affiche la page html demandée. Lorsqu’une action utilisateur effectue une action et déclenche une requête, il est simple de mesurer le temps de réponse entre le navigateur et le serveur, le navigateur lui-même est capable de le faire.
Aujourd’hui, les choses sont différentes. D’après les calculs d’Amazon, 1s de temps de réponse de plus sur leurs applications ferait perdre 1.6 milliards de dollars à l’entreprise. L’expérience utilisateur est donc dans le cœur des débats, notamment pour les sites e-commerce (182 000 en France en 2018). Les entreprises font donc face à des clients toujours plus exigeants, et les technologies ont évolué dans ce sens.
Malgré cette attente des utilisateurs, il faut de plus en plus de requêtes pour afficher une page Web, et la taille des pages chargées est de plus en plus conséquente. Pour afficher une page d’un site, il faut en moyenne 75 requêtes.
Evolution du nombre de requêtes par page depuis 2011
Depuis les années 2010, de nouveaux Frameworks Javascript comme Angular, React,et VueJS (pour ne citer que les 3 plus connus) permettent le développement d’applications très riches et ergonomiques pour les utilisateurs. Ceci implique également que les navigateurs soient capables de suivre la cadence, car l’émergence de ces outils a aussi impacté la structure des nouvelles applications.
Ces frameworks permettent d’architecturer les applications dites Single Page Application, en créant des components et en respectant le modèle MVC (Modèle, Vue, Contrôleur). Le principe est d’avoir une application qui ne charge qu’une fois la page, et qui charge ses données d’entrée pour les manipuler ensuite. Ce ne sont alors plus des serveurs d’application, mais des APIs et microservices qui sont contactés par le navigateur. Contrairement aux premières applications, les pages HTML ne sont plus envoyées par le serveur Web. L’application est découpée en plusieurs petites briques qui sont chargées de récupérer du contenu spécifique, qui transite au format json/XML à la demande de l’utilisateur. Tout le reste est géré par le framework et le javascript est dominant sur le front.
Qu’est ce qui a changé ?
Il est autant simple de tester et mesurer les performances d’une application classique qu’il est difficile de mesurer celles d’une Single Page Application (SPA). La logique serveur a été déportée côté client :
Avec l’explosion du javascript sur les navigateurs ces dernières années, et des structures d’applications très différentes, fournir un temps de réponse sur une page n’est plus assez représentatif. Pour les architectures en microservices/API (très souvent ce qui se cache derrière une SPA), c’est la capacité transactionnelle du serveur qui va être importante à mesurer. Effectivement il ne reste que des services capables de fournir des données rapidement, et une base de données. Plus de serveur Web, ou d’application déployée sur un serveur d’application car tout est géré par le framework sur le front.
En principe, les SPA chargent le contenu le plus important au début de la navigation. Le reste du contenu peut être téléchargé au fil de l’eau selon les actions de l’utilisateur. Les échanges client-serveur sont plus nombreux et il est difficile de mesurer leur temps de réponse.
Ici, les zones 1, 2 et 3 peuvent être chargées à différents moments. Soit l’application permet d’afficher des données dans ces zones en cliquant sur un bouton, soit les développeurs feront en sorte de ne charger le contenu qu’une fois que l’utilisateur ait scrollé jusqu’ici (lazy loading). Dans les deux cas, la page est déjà chargée, et le reste des données arrive au fil de l’eau.
Du point de vue du testeur, il devient difficile de mesurer le temps de réponse d’une page étant donné que son contenu est modifié dynamiquement en permanence.
Mesure du temps de réponse sur un site normal
Mesure du temps de réponse sur une SPA
Comment tester ces applications ?
Si on tient à avoir des indicateurs sur l’expérience utilisateur, il faut utiliser des outils de tests fonctionnels comme Selenium ou Ranorex, qui sont capables de mesurer le temps d’affichage des éléments sur le navigateur. Couplés aux outils de tests de performance, ils pourront ainsi fournir des métriques issues du DOM alors que l’application est soumise à une forte charge. (Il faut prendre en compte la difficulté de réaliser des tests fonctionnels sur une SPA… mais ceci est un autre sujet)
Pour tester le backend, nous parlerons de tests de composants. Evidemment une application Web classique sera testée depuis le navigateur, mais ici, il est important de connaitre la capacité transactionnelle. Son but est de fournir rapidement de la donnée, un point c’est tout (Si l’application est développée dans un contexte de CI/CD, il est alors préférable de tester les composants dès leur développement).
Il faut donc tester l’application sous deux angles différents : les tests de composant pour connaitre la capacité des services backend et les tests bout en bout pour mesurer les performances de l’application et l’expérience utilisateur.
Sources
https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales
https://www.alsacreations.com/actu/lire/1778-frameworks-javascript-angular-react-vue.html
