Boomerang est un framework JavaScript de mesure des temps de chargement côté client. C’est-à-dire qu’il mesure la performance de votre application web d’un point de vue utilisateur final. À l’image du boomerang, il revient vers le serveur en vous montrant comment vos utilisateurs ou vos visiteurs perçoivent votre site ou votre application.
Dans un message précédent, je vous expliquais comment intégrer Boomerang avec Piwik – un outil d’analyse d’audience. De manière à collecter les mesures des temps de réception et de calcul de page web. Ces mesures, insérées dans la base de données Piwik, peuvent alors être rapprochées aux rapports sur la fréquentation de votre site Internet ou de votre application intranet.
Le but de cet article est de présenter le framework Boomerang de manière plus détaillée.
Pourquoi un tel framework ?
Boomerang a été réalisé par l’équipe performance de Yahoo!. Après avoir mis au point YSlow, l’idée était d’offrir aux développeurs d’application web un minimum de mesures à remonter vers le serveur. Alors que YSlow permet de faire des mesures depuis le poste du développeur, Boomerang permet de remonter la mesure de la performance perçue par les utilisateurs de l’application.
Google a proposé il y a quelques temps une nouvelle norme de mesure des temps de réponse et de chargement sur un navigateur. Cependant, d’ici à ce que cette norme soit acceptée et surtout implementée sur tous les navigateurs (il y a encore pas mal d’Internet Explorer 6 sur le net), il faut avoir de quoi faire des mesures de manière uniforme et que cela fonctionne avec un maximum de navigateurs.
L’avantage de ce framework est qu’il s’adapte à tous les cas de figure. Il s’appuie sur les API des navigateurs qui implémentent déjà cette norme et tente d’exposer des mesures pertinentes dans le cas des navigateurs les plus anciens. On notera ces exemples d’implémentation de la norme :
- Internet Explorer 9 implémente la norme WebTiming via l’objet window.msPerformance.
- Les versions récentes de Google Chrome implémentent la norme WebTiming via l’objet window.webkitPerformance. Boomerang se base sur la méthode window.csi() pour les versions plus anciennes.
- Mozilla devrait l’implémenter via window.mozPerformance dans Firefox.
- …
Boomerang permet de réaliser d’autres mesures telles que la latence et la bande passante. Différents cas de figure sont présentés dans la documentation comme la mesure des performances du contenu dynamique…
Exemples de code
Les informations collectées par Boomerang peuvent être exploitées de différentes manières :
- Affichage dans la page web (insertion par JavaScript).
- Remontée des informations dans la log du serveur web.
- Envoi des temps via des variables personnalisées d’un outil d’analyse d’audience.
- …
Remonter les informations vers un serveur
L’implémentation de Boomerang est assez simple :
- Récupérer le code de Boomerang et le mettre dans l’arboresence de votre projet.
- Dans chaque page de l’application (idéalement un insert de type header ou footer), initialiser Boomerang.
- Optionnellement, modifier les options afin de charger d’autres plugins ou de modifier le comportement du framework.
- Indiquer l’emplacement de la balise. Il peut s’agir d’un fichier anodin de manière à n’afficher les informations de performance que dans le fichier de log du serveur Web. On peut indiquer un fichier dynamique (PHP, JSP, ASP…) dans le cas où l’on souhaite implémenter son propre collecteur.
Utilisation d’un élément fictif
L’exemple de base consiste à indiquer — en tant que balise — un fichier de ressource qui n’aura aucun impact sur l’application ou la bande passante (par exemple une image d’un pixel) :
<script src="js/boomerang/boomerang.js" type="text/javascript"></script>
<script type="text/javascript">
BOOMR.init({
beacon_url: "http://mon-serveur/mon-application/images/dummy.jpg"
});
</script>
Dans le fichier de log du serveur Web, on retrouve l’accès à cette ressource. Les paramètres d’appels (qui ne servent pas à invoquer une page dynamique, mais seulement à laisser une trace dans le fichier du journal d’accès) contiennent les temps de réponse collectés par le framework. Il ne reste plus qu’à écrire un script capable de les extraire et de les afficher dans un format plus lisible. Pourquoi ne pas écrire un plugin AWStat (si le cœur vous en dit) ? Cela vous permettrait de rapprocher les temps de réponse de l’analyse d’audience statique effectuée par l’outil.
127.0.0.1 - - [02/Feb/2012:12:52:51 +0100] "GET /mon-application/images/dummy.jpg?v=0.9&u=http%3A%2F%2Flocalhost%2FApp%2FSample.html&rt.start=navigation&t_done=500&t_resp=30&t_page=471&r=&bw=NaN&bw_err=NaN&lat=10&lat_err=0.57&bw_time=1328183572 HTTP/1.1" 200 -
Développer son propre collecteur
Si vous m’avez suivi jusqu’ici, vous comprendrez qu’il suffit de remplacer le fichier de type image (de l’exemple précédent) par un fichier de type dynamique (PHP, ASP, JSP…) dans lequel on exploiterait les paramètres envoyés par Boomerang (voir plus loin) pour les mettre dans une base de données de reporting.
beacon_url: "http://mon-serveur/mon-application/collector.php"
Via un outil d’analyse d’audience
Voir mon article précédent qui donne un exemple concret avec Piwik. C’est la solution que je préfère. Elle permet de bénéficier des autres données de la base de l’outil (audience, visites, …) plus simplement et en temps réel.
Synthèse des paramètres envoyés par Boomerang
Histoire de vous faciliter la lecture du code proposé dans l’article, je reproduis ici un extrait de la documentation de l’API et des deux principaux plugins.
boomerang parameters
- v – Version number of the boomerang library in use.
- u – URL of page that sends the beacon.
roundtrip plugin parameters
- t_done – [optional] Perceived load time of the page.
- t_page – [optional] Time taken from the head of the page to page_ready.
- t_resp – [optional] Time taken from the user initiating the request to the first byte of the response.
- t_other – [optional] Comma separated list of additional timers set by page developer. Each timer is of the format name|value
- t_load – [optional] If the page were prerendered, this is the time to fetch and prerender the page.
- t_prerender – [optional] If the page were prerendered, this is the time from start of prefetch to the actual page display. It may only be useful for debugging.
- t_postrender – [optional] If the page were prerendered, this is the time from prerender finish to actual page display. It may only be useful for debugging.
- r – URL of page that set the start time of the beacon.
- r2 – [optional] URL of referrer of current page. Only set if different from r and strict_referrer has been explicitly turned off.
- rt.start – Specifies where the start time came from. May be one of cookie for the start cookie, navigation for the W3C navigation timing API, csi for older versions of Chrome or gtb for the Google Toolbar.
bandwidth & latency plugin
- bw – User’s measured bandwidth in bytes per second
- bw_err – 95% confidence interval margin of error in measuring user’s bandwidth
- lat – User’s measured HTTP latency in milliseconds
- lat_err – 95% confidence interval margin of error in measuring user’s latency
- bw_time – Timestamp (seconds since the epoch) on the user’s browser when the bandwidth and latency was measured
Un mot d’avertissement
Comme illustré avec le nom des objets qui implémentent la norme WebTime, chaque éditeur de navigateur prend un chemin différent et offre plus ou moins de détails dans les mesures effectuées. C’est pour cela (c’est vrai pour toutes les nouvelles normes) que ce genre de frameworks sont très utiles. Ils offrent une couche d’abstraction vis-à-vis du navigateur. Les éditeurs de navigateurs sont aussi pris d’un coup de folie qui les font multiplier les versions, abandonner des implémentations, offrir de nouvelles fonctionnalités, refondre leur API… Tout cela pour donner une impression d’innovation perpétuelle.
Il vous faut donc suivre de près l’évolution de ce genre de frameworks, notamment en suivant l’actualité des versions au risque d’avoir des données incomplètes.
Pour plus d’informations
Comme d’habitude, voici les pointeurs qui m’ont aidés dans la rédaction de cet article :
- Obtenir Boomerang
- Documentation de Boomerang : How tos, Use Cases, l’API Boomerang…
- Message de lancement du projet sur YDN
- Autre post de l’équipe de développement sur YDN.