User timing

January 22 2015 By Posted in Expertise

Conventional passive methods measure the time between a user action that results in page loading (such as a click on a URL) and the onload event. In particular this is the case of any method where the script is injected automatically into the web site that is being monitored, as is done by APM tools. This approach is perfect for sites that have a classic kind of design. It is much less perfect when the dynamic aspect of the site calls upon asynchronous loading techniques. Thus, for an Ajax call, the time the request takes is not counted. And yet the time to access these data will affect the user’s experience.

 

One current trend is to design sites around a single HTML page that serves as a skeleton. The dynamic part is ensured by JavaScript and Ajax type requests. From the point of view of conventional passive monitoring, such a site would generate a single navigation. The other events, even if their point of departure can be tied to a user action, will not cause an onload, and therefore no measurement either. The user’s perception may therefore be negative because of slow access to a web service, but APM would be unable to detect it because the only information available is the potentially very short loading time of the first page.
RUM BI makes it possible to surpass such limitations by allowing the site designer to set his or her own timers. Then the times that are really important for improving service can be measured, drawing upon the analysis power of business intelligence tools.

 

A time can be started using this command:

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

Here is an example of implementation with a jQuery Ajax call:

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)
{
}
});

 

The custom timers open up new monitoring possibilities. The impact of any remote object can be measured, even when it comes from outside sites, or how fast a “post” is. The waterfall chart below is one example. The conventional operation of passive monitoring would cause the timer to stop at the moment of the onload event, indicated by the vertical blue line. Immediately following this event, the measurement is sent to RUM BI (step 1).

 

RUM BI

 

Here RUM BI was configured to measure the speed of an additional action (a GET toward YouTube), which takes place after the onload (step 2). Following this event, an additional measurement ticket is issued (step 3).

 

The JavaScript internal functions of the site can also be checked, for example to measure their impact on different platforms or execution contexts. Furthermore, it is always possible to embed the RUM BI script in apps designed on HTML5/JavaScript sites. In this way, all of the custom timers remain active in compiled Android or iOS apps thanks to PhoneGap or Cordova.

 

Alexandre Bourret, Innovation Catalyst

Leave a Reply

Your email address will not be published