Clutch Time – A New Web Performance Metric?
Recently there has been a lot of discussion on the usefulness of current web performance metrics. We all got used to First Impression, onLoad and Fully Loaded time. With dynaTrace Ajax Edition we also provide all this metrics. Joshua Bixby wrote a very good post an why they do not really tell us what we eventually want to know.
The major question we all want to answer is when the user is ready to use a page . While the current metrics help us to understand the behavior of a page, they cannot provide this information. Looking at the different metrics we find some shortcomings with all of them.
First Impression time tells us when the user gets the first visual of the page. While this tells us that the user sees something it does saywhat he sees nor whether he could interact with the page.
OnLoad time is the time when the onLoad event triggers. This is a good indicator to know when this code starts being executed. With dynaTrace we can look a bit deeper to see when a specific function has been executed. The effects of this timer on end users cannot be defined in general. In some case this is the point when JavaScript code begins to build the page in others is the time when progressive enhancement of the page content kicks in. Steve Souders has written an excellent blog about rendering vs JS execution . So in one case this metric is highly important and in other cases it is not.
Fully Loaded time tells us when all content including all downloads (and execution) triggered by onLoad handlers is finished. So this metric provides a hint when we are done downloading and executing all we need. Ok, there might still be additional content which is downloaded even later, but we get pretty close. The effect on the end-user is difficult to determine. The application developer will know best what this means for end-user experience.
So while all these metrics provide some important insight they still cannot provide the ultimate answer. I see this becoming a more and more important topic in web performance space. So the questions “When are ready to go?” still remains. Using an anlogy to driving I called this the clutch time – the time we lift our foot and start driving.
The hard part is to define how to measure it in a technically correct way. Using dynaTrace Ajax Edition we have tried several approaches but did not find the ultimate answer yet. For each approach there is at least one situation where it does not work as it seems. This is mainly caused by the huge number of different ways of how to build a page.
While I am not providing a final answer here is what our definition of clutch time is:
- First Impression Time if there is no blocking JavaScript execution thereafter or any DOM manipulation causing reflow in the onLoad method
- First drawing event after the last DOM manipulation in the onLoad event handler, if there is no JavaScript execution after that.
- End of continuous JavaScript execution either after First Impression Time if there is no onLoad DOM manipulation or end of JavaScript execution in the onLoad handler.
While I am sure that this definition is far from perfect it is a good starting point. I am looking forward to ideas on how to improve the measurement.



Thanks for taking the time to describe your metric! I suspect “clutch time” could gain an extra grace period since once a user sees the page as ready for interaction, you probably have 100 ms or so before they actually try and do anything, giving you a window to execute more javascript without hurting the experience. I’m not sure this is enough to change any recommendations or guidelines. What do you think?
At first I did not know what you meant by First Impression Time, but found the answer (first render event fires) on one of your community pages: https://community.dynatrace.com/community/display/PUB/Best+Practices+on+Web+Site+Performance+Optimization
Ryan,
I get your point. As far as I know however any execution longer than 10ms is seen by the user us a slight interruption of activity. I would keep the calculation however take this into account during analysis
btw. thank you for posting the link
Using boomerang, the application developer can specify at what point of time their page is usable, and use that as their round trip measurement.
With dynaTrace we have our own markers. However as I love the idea behind boomerang I think it makes perfect sense to detect the specific boomerang call and use it for calculation.
Guess, I have to look a bit closer at boomerang now. I always wanted to, but you know time is the issue not missing interest.
We should talk how dynaTrace can leverage boomerang information in testing environments.
naturally both tools have a place to play. if we could get all our users to install dynatrace and beacon data back, that would be pretty good, but failing that, boomerang works well. it’s not as useful in a testing environment because there are already far better tools.
I think each website or app is different (could be different user base, different feature set, different requirements, amount of client side js code that executes onload…)
For that reason, I think the developer should be aware of the “standard” load times markers as well as custom markers. And from that point pick the marker that makes sens to use as “clutch time”.
We talked about this at velocity. I can show you what I mean at next sfwebperf meetup.
JP,
I agree. The point I want to make is that more people claim current metrics do not work. So I tried to come up with a definition that makes sense.
I remember our Velocity conversation and also think that the developer best defines clutch time himself. I am just trying to get some benchmark results.
I won’t be at the meetup tomorrow as I have an appointment in the evening. However I would be happy to talk.
// Alois
Thanks for the link, Alois. And good to know that some of us are on the same page when it comes to identifying more meaningful metrics. I think it’s a good sign that there’s more interest in developing tools that measure clutch time (or what I call “time to interact” on my site), but at the end of the day, I think the most effective thing a site owner can do is actually watch how their pages load, object by object, in real time and from an end user’s perspective.
I wrote a new post where I highlight ways of doing this:
http://www.webperformancetoday.com/2010/10/06/creating-web-performance-test-visuals/
I think each website or app is different (could be different user base, different feature set, different requirements, amount of client side js code that executes onload..
Hi,I’m do the research about web performance since 1 year ago.And dynatrace is the most sex tool I have used.
In our company,we use the first screen time as metric of web performance.That means the time until the first screen have rendered of page.There are some company provide this monitor service.Such as http://rpc.networkbench.com/rpc/home.do
Postes this to my blog also. Greetings from the Speedy DNS
I think the problem is that we try to determine on a scientific way what moment in loading the page is the moment a user has enough info to start working. This, however isn’t a scientific question, but a psychologic question.
No one will wait until the last ad is loaded, but some users do wait until the browser says ready loading.
I think the metric to use would be an average time between the first moment the page is usable (the superfast and experienced users) and the moment the page is fully loaded (the granny’s).
Thanks for sharing a great information about metrics ,dyna trace is the most popular and the excellent tool i have been using so far .
I think dyna trace is great we work with it for a long time! More company’s should be working with this fine piece of soft.