- From: James Simonsen <simonjam@chromium.org>
- Date: Tue, 30 Nov 2010 18:21:30 -0800
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <AANLkTimMN8phQVemQbz3v_bY_v7kUYqJ-=t=9chT6ZPO@mail.gmail.com>
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