Re: Web Performance Potential Future Work

Hey Alois,

Great ideas. Comments inline in blue:

Von: Alois Reitbauer <alois.reitbauer@dynatrace.com<mailto:alois.reitbauer@dynatrace.com>>
Datum: Wed, 23 Nov 2011 02:58:47 -0800
An: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Betreff: 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.

I'm thinking about possible usecases – is there really any? There isn't so much time usually between creating an element, appending it to a visible DOM structure and the display of said element. I couldn't think of a use case, and I'm working on highly performing game code.

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.

Agreed. It would be nice to be able to programmatically track the UI thread and find out what is happening at any given point in time.

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.

+10. I couldn't agree more. I always found it weird that I can create a DOM Image, but do not have access to the underlying image resource being downloaded (in a direct way). I want this badly. I want to find out if there's an Etag or a last-modified header, and what the response looked like.

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

Yes. Going a step further, you will need to proactively work with the working groups implementing and designing those APIs to address issues before they hurt. At best, there should always be a performance goal for any given spec.

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.

Yes, with one addition – we should do this in comparison to the 'default' way of animating those same properties using JavaScript. I, for instance, made the observation that it really doesn't matter much, but I only tested this specific behavior on WebKit. Would be interesting to see some facts.

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.

Memory allocation and more importantly, garbage collection is one of our biggest bottlenecks, writing a game engine in JavaScript. Being able to thoroughly debug this is by far the most wished-for feature for many of our engineers. +1.

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

I don't really understand this one. Can you elaborate further?

Thanks!
Paul

Please comment on the use cases and provide feedback.

// Alois