Mesurer les performances des applications web monopages (SPAs) s'avère être une source de défis uniques. Philip Tellis et Nicholas Jansma ont exploré le sujet en profondeur lors de la conférence Velocity à Amsterdam, en proposant un contexte et des conseils spécifiques sur comment mesurer les performances de ce genre d'applications.
Tellis est l'auteur de la populaire bibliothèque boomerang et architecte en chef chez SOASTA. Jansma est architecte logiciel senior chez SOASTA, un éditeur de solutions orientées performances.
Tellis et Jansma définissent une limite claire entre hard navigation et soft navigation. Hard navigation correspond au cas du chargement initial d'une SPA, en incluant le chargement initial des routes. Soft navigation caractérise les changements de route suivants.
Pour mesure quelque chose, nous devons savoir lorsque les évènements de début et de fin ont lieu. Ceci est un vrai défi pour les SPAs, du fait de la nature même des soft navigations. L'évènement onload n'a plus d'importance, car la majeure partie de l'activité a lieu après cet évènement. Les soft navigations ne sont pas de vraies navigations, au sens premier du terme, à savoir vous pouvez changer l'URL du navigateur sans vraiment naviguer vers une nouvelle page et donc générer un évènement onload. Et les navigateurs n'ont pas d'API qui indiquent si et quand toutes les ressources - à savoir les images, scripts, css, vidéos - ont été chargées. Savoir quand débute et se termine une soft navigation de manière automatisée nécessite d'être inventif.
Une nouvelle soft navigation peut être détectée de différentes manières. L'historique du navigateur peut être modifié. Les frameworks SPA peuvent générer leurs propres évènements de routage. Par exemple, AngularJS envoie $routeChangeStart. L'utilisateur peut cliquer sur un élément du DOM, ou une requête ajax (XHR - XmlHttpRequest) peut provoquer une modification du DOM. Et ces changements ne provoquent pas vraiment de soft navigation. Tout dépend de la cascade d'évènements qui s'en suit, pouvant ainsi engendrer le chargement de ressources, des modifications significatives du DOM ou un changement notable de l'historique du navigateur.
Ce qui constitue l'évènement de fin d'une soft navigation dépend du contexte. Cela peut être la fin du chargement des ressources, la possibilité pour l'utilisateur d'intéragir avec le contenu de la page ou n'importe quel autre évènement. Tellis et Jansma recommandent de suivre l'état du réseau en interceptant les requêtes XHR et les récupérations implicites de ressources via des éléments du DOM comme les balises images. Boomerang propose ainsi le plugin auto_xhr qui gère ces 2 scenarii. Le plugin proxifie l'objet XHR pour suivre les requêtes server et tire également parti du Mutation Observer pour suivre les changements notables du DOM (entre autres : les changements d'attributs src et href) qui annoncent des changements de ressources.
Il est important de détecter les chargements de ressources, mais aussi de savoir le temps que le navigateur met à faire le rendu de ces cahngements (par exemple : afficher une image). Effectuer un setTimeout(..., 0) permet au navigateur d'effectuer le rendu avant de mesurer les performances :
var xhr = new XMLHttpRequest(); xhr.open("GET", "fetchstuff"); xhr.addEventListener("load", function(){ $(document.body).html(xhr.responseText); setTimeout(function() { var endTime = Date.now(); var duration = endTime - startTime; }, 0); }); var startTime = Date.now(); xhr.send();
Ce niveau de complexité a des chances de changer dans les années à venir. Le WHATWG (Web Hypertext Application Technology Working Group) travaille sur le standard Fetch, qui vise à unifier la façon dont les ressources sont récupérées en proposant une API consistante.
L'API User Timing est une API standardisée pour mesurer les performances. Cette API propose les meilleures solutions pour réaliser des mesures efficaces et adaptées au métier. L'inconvénient est qu'elle nécessite de coder chaque métrique manuellement.
Pour les hard navigations, les navigateurs proposent déjà plusieurs API de mesure du temps. L'API Navigation Timing donne des informations détaillées sur les hard navigations. L'API Resource Timing offre des informations sur le temps de chargement des ressources. Mais malheureusement, rien concernant la détection du chargement de ressources. Ces API ne sont juste pas adaptées au contexte des SPAs.
Les diapositives de cette présentation sont disponibles sur SlideShare.