Q&A: Nav Timing and post-onload requests

October 30, 2012 11:29 am | 1 Comment

Today I got an email asking this question about window.performance.timing:

I’ve noticed that on all browsers (where timing is supported), the timing stops once the readyState of the document = ‘complete’.  Seems normal, but in many cases, I’ve seen web pages that load additional “stuff” via aysnc loading (mostly mktg tags) and the timing object doesn’t seem to reflect this additional load time.  Is this by design?

It’s a good question so I wanted to post my response for others who might be wondering the same thing.

An increasing number of websites load resources after the window.onload event. In fact, 8 of the world’s top 10 websites have post-onload activity: Google, Facebook, YouTube, Yahoo, Windows Live, Twitter, Tencent, and Amazon.

It makes sense that you’d want to capture this activity as part of any performance metrics, so why isn’t it already part of window.performance.timing? Remember we’re dealing with a W3C specification – the Navigation Timing specification to be exact. As with many specs, what seems intuitively simple is more difficult to capture in exact language. Looking at this processing model graph we see that the questioner is right – Navigation Timing stops at the window.onload event. We might think of extending the spec to have an “end of network activity” event that would include these post-onload requests.

Defining “end of network activity” is the tricky part. In the case of many sites, such as the 8 sites listed previously, the post-onload activity is a few HTTP requests. This is more straightforward. But what about sites that do a polling XHR every 5 seconds? Or sites that use Comet (hanging GET) or websockets? Their network activity never ends, so the Navigation Timing metrics would never complete.

There’s also a tension between wanting to capture this later activity but also wanting sites to send back information as quickly as possible. Many users (5-15% in my experience) quickly click through to the next page. For these users it’s important to fire the metrics beacon (AKA tag) before they leave the page. The two key questions for this issue become:

• How can post-onload activity be measured?
• When should the timing metrics be beaconed back?

It’s possible that Navigation Timing could be extended to have an “end of network activity” value. For sites that have infinite network activity the specification could have language that set this value in the absence of network activity for N (2?) seconds or after a maximum of M (10?) seconds after window.onload. I encourage people in favor of this idea to send email to public-web-perf@w3.org (with [NavigationTiming] at the start of the subject line).

Instead of a high level “end of network activity” measurement, web developers can get more fine grained measurements today. Many of the post-onload HTTP requests are scripts, images, and XHRs that can all be timed individually with JavaScript. In the future the Resource Timing spec will provide this per-request level of timing information. Developers of websites that have infinite post-onload activity can make their own decisions about what to include in their post-onload activity measurements.

With regard to when the timing metrics should be beaconed back, it’s important to send a beacon as quickly as possible to get information before the user does a quick click through. Therefore, I recommend sending the Nav Timing data in a beacon as part of window.onload. (See sample code in A Practical Guide to the Navigation Timing API.) For sites that want to measure post-onload activity, I recommend sending a second beacon with this additional information. Sending two beacons should have a minimal performance impact for the user, network, and backend server. If the delta in the number of first vs second beacons is within a tolerable range, then the website owner could choose to send only the latter beacon containing all the performance information.