User timing

22 janvier 2015 Par Posté dans Expertise

Les méthodes passives classiques mesurent le temps entre une action utilisateur entraînant un chargement de page (tel qu’un clic sur une URL), et l’événement ‘onload’. C’est notamment le cas de toute méthode où le script est injecté de manière automatique dans le site web à monitorer, tels que fourni par les outils d’APM. Cette approche est parfaite pour les sites de conception classique. Elle l’est beaucoup moins lorsque l’aspect dynamique du site fait appel à des techniques de chargement asynchrones.

 

Ainsi, dans le cas d’un appel Ajax, le temps pris par cette requête n’est pas pris en compte. Pourtant le temps d’accès à ces données aura un impact sur la perception utilisateur. Une tendance actuelle est de concevoir les sites autour d’une page HTML unique servant de squelette. La partie dynamique est assurée par le JavaScript et des requêtes type Ajax. Du point de vue d’un monitoring passif classique, un tel site ne générera qu’une seule navigation. Les autres événements, même si leur point de départ peut être lié à une action utilisateur, ne feront pas l’objet d’un onload, et donc d’une mesure. La perception utilisateur peut donc être négative à cause d’un accès trop lent à un web service, l’APM ne sera pas en mesure de le détecter car la seule donnée disponible est le temps potentiellement très court de chargement de la première page.

 

RUM BI permet de dépasser cette limitation en permettant au concepteur du site de définir ses propres chronomètres. Il peut dès lors mesurer les temps qui lui importent réellement dans l’amélioration de son service, tout en utilisant la puissance d’analyse des outils de Business Intelligence.

 

Un chronomètre peut être démarré en utilisant cette commande :

clobs.startTimer(‘Nom_de_l_univers’);

Un chronomètre nommé Nom_de_l_univers est alors déclenché. Plusieurs chronomètres peuvent fonctionner indépendamment, en utilisant un nommage différent. Dans l’interface RUM BI, les données seront agrégées à l’intérieur de l’univers Nom_de_l_univers.

Pour arrêter le chronomètre Nom_de_l_univers, la commande suivante est employée :

clobs.stopTimer(‘Nom_de_l_univers’);

Cet arrêt provoque l’envoi d’un ticket de mesure vers les collecteurs d’ip-label. Cette mesure sera agrégée dans l’univers portant le nom ‘Nom_de_l_univers’

 

Exemple

Voici un exemple d’implémentation sur un appel Ajax en jQuery :

clobs.startTimer(‘ajax_get’);//Les données sont prètes à être envoyées
$.ajax({
url : “AJAX_POST_URL”,
type: “GET”,

dataType: “JSON”,
data : formData,
success: function(data, textStatus, jqXHR)
{
//données – reponse du server
clobs.stopTimer(‘ajax_get’);//Le serveur a répondu, on arrête le chronomètre
},
error: function (jqXHR, textStatus, errorThrown)
{
}
});

 

Les chronomètres custom offrent de nouvelles possibilités de monitoring. Il est possible de mesurer l’impact de n’importe quel objet distant, même provenant de sites tiers, ou encore la rapidité d’un “post”. Le waterfall ci-dessous en donne un exemple. Le fonctionnement classique du monitoring passif conduirait à arrêter le chronomètre au moment de l’événement “onload”, visualisé par la ligne verticale bleue. Suit immédiatement après cet événement l’envoi de la mesure vers RUM BI (étape 1).

 

 

Ici, RUM BI a été configuré pour mesurer la rapidité d’une action supplémentaire (un GET vers YouTube), qui se passe après le “onload” (étape 2). Suite à cet événement, un ticket de mesure supplémentaire est envoyé (étape 3).

Les fonctions internes javascript du site peuvent également être contrôlées, par exemple pour en mesurer l’impact sur différentes plateformes ou contextes d’exécution. Enfin, il est toujours possible d’embarquer le script RUM BI dans les apps conçues à partir de sites HTML5 / Javascript. Ainsi, tous les chronomètres custom resteront actifs dans les apps Android ou iOS compilées grâce à PhoneGap ou cordova.

 

 

Laisser un commentaire

Votre adresse email ne sera pas publié