RE: [Resource Timing] User feedback and a modified proposal

As a counter-example, at Facebook we're primarily interested in measuring every resource on the page. So I don't think your generalization is fair for all use cases.

I do think the idea of an event listener is pretty interesting, though, and if there's some way to set up the generic event listener that gets all events and does its own filtering, I think we'll be pretty happy. It seems like it would be easy to support this feature in addition to the event-per-resource.

If there's a concrete proposal I can circulate it around the team at Facebook for more concrete feedback.

                 --jason

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of James Simonsen
Sent: Tuesday, November 30, 2010 6:22 PM
To: public-web-perf
Subject: [Resource Timing] User feedback and a modified proposal

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