W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2010

[Resource Timing] User feedback and a modified proposal

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 30 Nov 2010 18:21:30 -0800
Message-ID: <AANLkTimMN8phQVemQbz3v_bY_v7kUYqJ-=t=9chT6ZPO@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
I talked to a few groups here that would be interested in using Resource
Timing. Here's a summary of the feedback they gave:

   - One group only cares about a couple of critical resources.
   - One group only cares about 1 critical XHR.
   - One group is more interested in when the user first sees elements
   "above the fold" on the site.
   - One group is more interested in Javascript parsing and execution time.

If I were to generalize these into requirements, here's what I'd come up
with:

   - Users want to know when a few specific user-visible events occur.
   - Users want to know why it took so long for those specific events to
   occur.

So, I'd like to revisit proposal #1 from my previous e-mail, but modify it
to accommodate the new requirements. Namely, adding new events and adding
relevant timing information to them.

There aren't existing events for all of the things users expressed interest
in, so we might need to add events like the following:

   - Element layout or rendering events
   - CSS subresource load events

Then, the relevant timing information will vary depending on the object. For
instance:

   - Scripts should include parsing time.
   - Images might include decoding time.
   - All resources should include network time (ResourceTiming from the
   draft spec).

We can append this information to each event objects in any number of ways.
The correct way is probably to have different ResourceTiming classes for
each one. Another option would be just to treat ResourceTiming as an array
of name, value pairs.

Finally, users will likely use some sort of analytics package to retrieve
this data. We just need to make sure they have some means of passing the
timing data to the analytics script, even before it loads. I'd propose that
pages append interesting timing data to a well known global variable. The
analytics script processes that variable periodically or on unload.

Example:

My site's code:

<script>
var AnalyticsTimingData = new Array;
function RecordTiming(ev) {
  AnalyticsTimingData.add(ev.timing);
}
myCriticalXHR.addEventListener("load", RecordTiming);
document.getElementById("myCriticalImage").addEventListener("render",
RecordTiming);
document.getElementById("myCriticalScript").addEventListener("load",
RecordTiming);
</script>
...
<script src="myanalyticshost.com/analytics.js<http://google.com/analytics.js>
">


Analytics code:

window.addEventListener("unload", function(ev) {
  for (timing in AnalyticsTimingData) {
    for (property in timing) {
      // Package timing data and send back to analytics server.
    }
  }
});

As a side-effect of this approach, we can still collect every bit of timing
data on the page; we just need to use event capturing. For instance, we can
collect every single load event with:

window.addEventListener("load", RecordTiming, true);

One downside to using events is that it puts more strain on the Javascript
engine. We'll be garbage collecting a lot of unused timing data and firing
more events. I suspect the modern Javascript engines won't have any problems
here though.

Thoughts?

James
Received on Wednesday, 1 December 2010 02:22:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:29 UTC