Comment superviser les performances de votre application web : la meilleure méthode est-elle le RUM (Real User Monitoring) ou le monitoring synthétique ?
Il existe de nombreuses façons de contrôler la façon dont votre application ou site Web est rendue à vos utilisateurs. « Quelle est la meilleure façon de superviser les performances de votre site web ? » est une question fréquente. Nous entendons deux réponses très courantes en matière de performance web : Les tests synthétiques et le Real User Monitoring (RUM). Quelle est la meilleure solution pour vous ?
Tout d’abord, Tous les développeurs web effectuent certains tests avant de mettre en ligne ou de publier leur dernière version. Les questions que nous souhaitons aborder ici sont les suivantes :
- en fonction de la structure de votre Platforme web, du profil de vos utilisateurs et de l’importance des performances web, comment devez-vous les surveiller ?
- ce que vous pouvez attendre de chaque type d’outil de monitoring de la performance web (monitoring synthétique et real user monitoring – RUM) ?
- les avantages et inconvénients de chaque méthode
Commençons par l’approche la plus simple pour tester les performances d’un site web.
Chrome DevTools
Tout développeur web ou dépanneur a un jour utilisé Firebug (touche F11 de Firefox) ou Chrome DevTools. Cette vue vous donne une image claire de la façon dont la page est chargée sur votre machine et offre certaines options comme la désactivation du cache, la simulation de différentes conditions de réseau et l’affichage avec plusieurs options de taille d’écran.
C’est un bon début, comme on peut le voir :
- Les temps de chargement globaux (LCP, FCP, PLT, …)
- Le poids de la page globale et la taille de chaque ressource, comment elle est compressé (ou pas)
- The rendering path and the eventual long tasks and slow resources
L’inconvénient de ce système est qu’il affiche toutes les performances en fonction des ressources de la machine du développeur/testeur (RAM pour le traitement des scripts par exemple), de la connectivité et de l’emplacement géographique de cette machine.
Il existe un risque important que les utilisateurs réels de l’application disposent de moins de ressources, d’écrans plus petits, d’une connectivité plus faible, etc.
Enfin, ces outils fournissent beaucoup de données, mais elles ne sont pas faciles à interpréter.
Vous trouverez ci-dessous une capture d’écran de l’affichage du réseau de l’entreprise. DevTools:
PageSpeed Insights
Il existe une deuxième approche qui consiste à tester depuis un autre endroit en utilisant un service gratuit ou payant. Dans ce cas, le test peut être effectué à partir d’un endroit éloigné ; parfois, le service peut être offert à partir d’une multitude d’endroits afin d’évaluer l’impact de cette différence sur la performance web perçue par les utilisateurs.
De bons exemples de ces services sont PageSpeed Insights from Google.
La limite de cette approche est qu’elle est toujours exécutée à partir d’emplacements bénéficiant d’une très bonne connectivité (c’est-à-dire des machines hébergées dans le cloud ou dans des centres de données avec un accès relativement direct aux dorsales) et que ces machines disposent d’un ensemble relativement important de ressources pour rendre la page.
Si ces 2 approches représentent de bonnes pratiques, elles ont un inconvénient commun : il s’agit de tests manuels réalisés à la demande ; ils ne représentent pas les changements appliqués à votre application, les conditions changeantes de l’infrastructure publique entre vos utilisateurs et votre plateforme d’hébergement.
Vous verrez ci-dessous une capture d’écran des résultats de PageSpeed Insights :
Monitoring synthétique des performances du web
Le monitoring synthétique consiste à rejouer régulièrement des scénarios utilisateurs et à surveiller la bonne exécution de l’application et sles temps de réponse. Les tests synthétiques peuvent être portés à grande échelle en multipliant le nombre de sites à partir desquels l’application est testée.
Il peut également offrir plusieurs options de test, comme le choix du dispositif utilisateur émulé ou du navigateur utilisé pour exécuter le test.
Principaux avantages
- Les tests reproductibles facilitent l’interprétation des mesures (même lieu, mêmes pages testées, etc.).
- Le scénario utilisateur peut représenter un ensemble complet d’actions de l’utilisateur qui correspondent à une transaction métier.
Principaux défis
- Les tests synthétiques nécessitent la configuration des scénarios. Configurer les bons scénarios de test (suffisamment pour représenter tout ce qui vaut la peine d’être contrôlé et pas plus que ce que vous pouvez maintenir à long terme).
- Maintenance : si votre application évolue rapidement, vos tests doivent aussi évoluer. Il s’agit là d’un deuxième écueil : le coût de maintenance du monitoring synthétique.
- La supervision synthétique n’est pas très adaptée pour vous guider vers la cause première en cas de plainte des utilisateurs ; il s’agit plutôt d’un système d’alerte proactif qui vous prévient lorsque quelque chose ne fonctionne pas comme attendu.
- Malgré toutes les options de test, vous aurez du mal à ce que vos tests synthétiques reflètent la variété des utilisateurs et des transactions que l’on peut observer sur votre application.
Suivi des utilisateurs réels
Le suivi des utilisateurs réels consiste à collecter des analyses de performance à partir des appareils de vos utilisateurs, qui reflètent toutes les transactions effectuées sur votre application.
Voici un court article qui décrit le fonctionnement de R.U.M. En résumé, un script que vous intégrez dans votre code HTML donne les instructions aux navigateurs de vos utilisateurs pour qu’ils envoient les données de performance disponibles via les API du W3C à votre plateforme Real User Monitoring.
Principaux avantages
- Compréhension complète de votre audience et du profil de l’utilisateur (localisation géographique, connectivité, appareil, navigateur, …)
- Visibilité complète de la manière dont l’expérience (temps de réponse / erreurs) est liée aux profils des utilisateurs.
- Excellent pour décomposer les performances des utilisateurs afin d’isoler l’origine des dégradations.
- Montre 100% des transactions, sans aucune configuration requise –> la mise en œuvre et la maintenance sont faciles.
- Fonctionne également pour les applications de pages simples et complexes
Principaux défis
- Volume de données : vous recevez beaucoup de données, mais vous devez les stocker… et les analyser !
- La quantité de données que vous pouvez faire pivoter dans de nombreuses dimensions différentes (temps, lieu, connectivité, appareil, navigateur, transaction, etc.) rend l’interprétation des données un peu plus compliquée que la lecture d’une simple série temporelle.
Comment surveiller quoi ? RUM ou monitoring synthétique
| Synthétique | Suivi des utilisateurs réels (RUM) | |
| Comment |
|
|
| Avantages | Facile à interpréter
Idéal pour les alertes proactives sur un ensemble simple de pages ou de transactions. |
Mise en œuvre instantanée
Visibilité complète de toute l’audience Idéal pour le dépannage et la recherche d’optimisations. Idéal lorsque les scénarios sont difficiles à élaborer ou que la couverture des activités des utilisateurs (SPA) est insuffisante. |
| Inconvénients | Visibilité limitée sur l’utilisation réelle et l’expérience
Maintenance des scénarios |
Plus difficile à interpréter
Plus de volumes de données à stocker |
| Cas d’utilisation adéquats | Sites web relativement simples
Alerte proactive sur un ensemble simple de pages à tester |
SPA
Mise en œuvre complexe Profils d’utilisateurs hétérogènes |
La stratégie de Kadiska : combiner le meilleur des deux mondes !
La vision de Kadiska est de combiner le monitoring des utilisateurs réels et le monitoring synthétique :
- Notre position chez Kadiska est de combiner le RUM et les tests synthétiques : la surveillance des utilisateurs réels (RUM) permet d’avoir une visibilité complète de l’audience d’une application, de comprendre les facteurs de l’expérience numérique, les transactions et le profil de l’utilisateur qui sont satisfaisants ou non, et d’isoler le facteur qui fait que ce n’est pas assez bon (partie de la plateforme en cause: application, CDN, tierce partie, transaction et ce qui provoque la mauvaise réponse – réseau, traitement du serveur, transfert de données, mise en file d’attente, etc…)
- Des tests synthétiques intelligents pour tester votre application, le réseau et l’infrastructure cloud afin de trouver la cause profonde du problème et de savoir comment le résoudre.
