Web Performance Potential Future Work

As discussed during TPAC I created an initial list of uses cases which should be supported by future specifications. The use cases split between those for  for production and development use. Development for the sake of simplicity includes testing as well as troubleshooting in production. Besides different scenarios the main distinction is that  in a development setting the user would agree to expose more information – probably violating privacy concerns – to get deeper insight into the inner workings of the application.

The following list provides a starting point of use cases. If you feel that there are additional ones please post them as a reply.  For the convenience of commenting I numbered each use case.

Perf 1 - We want to be able to measure when content is visible to the user (Prod/Dev)

Understanding download times is not enough to measure how long it takes for a user to see content on the screen. Therefore we need a way to get notified when rendering and layout calculation happens in the browser.

Perf 2- We want to understand how and whether the execution of JavaScript code impacts site loading and execution of user actions (Prod/Dev)

Network details alone are not enough to understand what consumes time during the loading of a page. This still leaves blank spots where we do not know what the browser is doing. Therefore we need a way to understand when and which JavaScript code is executed.

Perf 3 – We want to measure the total duration of user interaction although it contains async. parts like XHRs or timers   (Prod/Dev)

We need a way to identify how different JavaScript executions that form a bigger logical unit tie together to understand the overall user response time.  This can be best achieved by providing a means to piggy back transaction IDs across asynchronous invocation contexts.

Perf 4 - We want to get the details (headers and body) of networks requests to perform detailed performance diagnosis (Dev)

While the resource timing spec provides insight into the timings of resources we still miss important information needed to optimize a web application. We need to see HTTP Headers to understand protocol details, encodings etc. as well as the content to find problems like non-minified JavaScript, images which are too big etc. This will enable building tools like YSlow etc. based on a standardized browser independent API.

Perf 5 – We want a way to analyze why a specific JavaScript execution (block or user event) is slow (Dev)

This use case is an extension of Perf 2.  In order to be able to diagnose actual JavaScript related problems we need a way to get the detailed trace of a JavaScript execution including method parameters etc. This requires the browser to provide a means for an analysis tool to instrument JavaScript code and DOM interactions to collect performance data.

Perf 6 – We want to be able to understand the performance impact of (future) HTML 5 APIs. (Prod/Dev)

This use case targets getting insight into new HTML 5 API like IndexDB to understand the performance impact of using these APIS.  It definitely needs more research and a more detailed investigation

Perf 7 – We need to understand the performance cost of CSS animations (Prod/Dev)

Many dynamic UI changes that in the past required JavaScript can now be performed using CSS. We need a means to get insight into the performance characteristics of this animations.

Perf 8 – We need insight into the memory behavior of a web application. (Prod/Dev)

Memory Leaks and excessive memory usage has been a problem in browsers for a long time. We need a means to create a memory dump and perform allocation analysis to pinpoint memory problems.

Perf 9 – We need to be able to analyze the root cause of a JavaScript error (Prod/Dev)

Today we can already register global error handlers. However in many cases the information available does not allow to diagnose the problem. Script parse errors do not return the expression that led to a failure and for script errors we need details of the actual code – especially for dynamically generated scripts.

Perf 10 – We need an easy way to get notified when a user triggers events  (like button clicks) in order to time them properly (Prod/Dev)

Today it is hard to find when a user triggers a certain action. The only way is to register event handlers by walking the whole DOM. While being hard to ensure we really get all events it also has a significant performance impact on the page. A simple callback mechanism would resolve these problems

Please comment on the use cases and provide feedback.

// Alois