This proposal defines a potential future standard as an addition to those currently developed by the W3C Web Performance Working Group. It’s goal to gain visibility into JavaScript execution via a browser provided API accessible via JavaScript.

Motivation

Current specifications of the Web Performance Working cover page loading related metrics. They however lack insight the dynamic behavior of Web page implemented in JavaScript. With an increasing amount of Third Party JavaScript code (social plug-ins, ads, etc.) being executed on Web pages this insight is getting more and more important. The increasing adoption of single page web applications where the majority of the user interactions happens via the execution of JavaScript code rather page loading also required better insight into the dynamic behavior of a web page.

Today developers are forced to manually instrument their code to get performance metrics following an approach like in the simple example below.

function myFunc (){
  logStart(“myFunc”);
  // do something useful
  logEnd(“myFunc”);
}

With the adoption of User Timing there will be a standardized way for collecting this kind of measures. There are, however, a number of drawbacks to this approach.

First of all it requires manual instrumentation of the code. This adds additional work for the developer, makes the code harder to read and is also error prone. The developer also has to test the monitoring code in addition to the actual application logic. Especially in cases where the user logic also involves asynchronous behavior a simple error to this monitoring code can easily happen. This then renders all monitoring data useless.

Another important issue is that this approach is restricted to code under the control of the developer Third Party JavaScript code cannot be modified using this approach. Thus we cannot get insight these code pieces, which we need to monitor as this code is a performance critical part of a web page.

The increasing adoption of asynchronously and deferred executed JavaScript also creates an additional blind spot as their execution cannot be analyzed but still has impact on page performance by blocking the UI thread for example.

As per today we have no efficient way to monitor and understand JavaScript execution characteristics of our code based on standard APIs. Therefore we have to add additional instrumentation to browsers enabling monitoring and analysis of JavaScript executions.

Integration into existing specification

The Performance Timeline provides a unified means to access performance data in the browser using JavaScript. All data defined by other Web performance standards can be accessed via this interface. The structure of a performance entry looks as follows

interface PerformanceEntry {
  readonly attribute DOMString name;
  readonly attribute unsigned long long startTime;
  readonly attribute unsigned short entryType;
  readonly attribute unsigned long long duration;
};

We can reuse this data structure for the purpose of reporting JavaScript execution times. We have to define an additional entry type which represents timings for JavaScript executions. The name field can then be used to provide further information.

The name field can be used to provide more details about the actual JavaScript execution. In case of file being executed the name of the root function(s) and the name of the file would be concatenated in the name field (e.g. initPage (commons.js)). The developer in this case has to ensure that the root functions of his JavaScript files are not obfuscated by minification. In case of an inline script the JavaScript function name would be used. If available it will be appended by the id of the script block on the page. While it is not common to use id attributes for script tags adding them comes with little additional effort. Once developers see the benefit they get they will be willing to take that this extra step.

An alternative approach is to split this information up into different fields. This will make the semantic much clearer and the interface cleaner. For the sake of simplicity the initial proposal just used what is already available by the standard.

Examples

This section presents a number of examples of typical usage scenarios of JavaScript code and how the execution time information will be represented by the JavaScript Timing API.

Execution of a function in inline script

<script id="”initPage”" type="text/javascript">// 
perfEntry{
  name: 'initFunc (initPage)',
  start: 100,
  duration: 50,
  type: EXEC_JS
}

Execution of inline JavaScript code

<script id="”initPage”" type="text/javascript">// 
perfEntry{
  name: '(initPage)',
  start: 100,
  duration: 50,
  type: EXEC_JS
}

Execution of JavaScript code from external file

…
…<script type="text/javascript" src=”my.js”>// 
perfItem{
  name: ‘myFunction (my.js)’,
  start: 700,
  duration: 200,
  type: EXEC_JS
}

Overhead Concerns

As this requires additional instrumentation in the browser it will come with some overhead. As there are no implementations so far it is hard to say how much. However browser extensions today like dynaTrace Ajax Edition can track even more data at a reasonable overhead. Nevertheless it is a serious concern and must be taken into account. This can be best evaluated by browser vendors.

In order to limit the overhead there should be the possibility to turn this feature on and off. The easiest way would be to use a specific HTTP Header like TRACE-JS. For single page applications it would be useful enable and disable tracing via JavaScript as there is only a single request for the initial HTML document.

Most likely not all data will be sent back the server for processing. Otherwise, the sheer amount of monitoring data will create massive load on Web servers. The data will be evaluated on the client side and only relevant information is sent back. A typical criteria to decide which data to send back is execution time. All events with an execution time below a certain threshold will be discarded. This massively reduces the amount of data sent will still providing insight into performance hotspots.

Conclusion

Extending the current W3C performance standards will provide long required insight into the dynamic behavior of web pages. Especially for single page applications and mobile HTML 5 apps this would be the first means to get the required insight for effective application monitoring. Using automatic instrumentation of JavaScript executions, there will not be any more need for manual instrumentation. This will reduce the potential of errors and increase the availability of performance data without further effort for application developers supporting a fast and easy adoption. Especially on mobile this will provide unprecedented insight into the runtime behavior of mobile web applications.

// ]]>