- From: James Simonsen <simonjam@chromium.org>
- Date: Tue, 30 Nov 2010 11:42:55 -0800
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <AANLkTikpfjHWDYbaR7E+zJpxMP99BF4cZ-wf_h4nc6Ch@mail.gmail.com>
As mentioned during last week's conference call, I created a document outlining the different ideas that have been discussed. It's been helpful to during discussions here. I promised to post this publicly so that others could use it too. Obviously, we can mix and match proposals. For instance, Zhiheng suggested combining proposal #2 and proposal #4. Since creating this summary, I've talked to some other groups that would be users of Resource Timing. After talking to them, I want to go in a somewhat different direction. I will post those thoughts later today. In the meantime, here's my original summary. Please post corrections. Proposal 1: Load EventAdd the resource timing data to the event dispatched when a resource is loaded. Interfaceinterface LoadEvent : Event { readonly attribute ResourceTiming timing; }; Examples// Time all objects document.addEventListener(“load”, function(ev) { console.log(ev.target.src + “ finished loading at “ + ev.timing.loadEventStart); }, true); // Time specific object myImage.addEventListener(“load”, function(ev) { console.log(myImage.src + “ finished loading at “ + ev.timing.loadEventStart); }); Advantages - Reuses existing concepts - Page can pick and choose timing data - Minimal memory use Disadvantages - Must register early to collect all timing data (i.e. analytics) - Can’t time CSS subresources - Lots of garbage collection Proposal 2: DOMAdd the timing information to all DOM objects that load resources. Interfaceinterface HTMLImageElement : HTMLElement { … readonly attribute ResourceTiming timing; }; ... interface StyleSheet { … readonly attribute array[ResourceTiming] subresourceTiming; }; Examples// Time all objects nodes = document.getElementsByTagName(“*”); for (i = 0; i < nodes.length; ++i) if (nodes[i].timing) console.log(nodes[i].src + “ finished loading at “ + nodes[i].loadEventStart); for (i = 0; i < document.styleSheets.length; ++i) for (j = 0; j < document.styleSheets[i].subresourceTiming.length; ++j) console.log(document.styleSheets[i].subresourceTiming[j].src + “ finished loading at “ + document.styleSheets[i].subresourceTiming[j].loadEventStart); // Time specific object console.log(myImage.src + “ finished loading at “ + myImage.loadEventStart); Advantages - Reuses existing concepts - Timing data persists as long as objects do - Can measure CSS subresource timing Disadvantages - Analytics scripts won’t be able to get XHR timing - Timing data consumes memory even if page doesn’t want it - CSS subresources are a special case - If multiple elements point to same URL, hard to find the one that loaded from network Proposal 3: Timing EventHave a global timing event that is fired any time a resource loads. Timing events that occur before document.onload are queued and sent all at once after window.load is fired. Interfaceinterface ResourceTimingEvent : Event { readonly attribute array[ResourceTiming] timing; }; interface ResourceTimingCollector { void addEventListener(in EventListener listener); void removeEventListener(in EventListener listener); }; interface Performance { ResourceTimingCollector createResourceTimingCollector(); }; Examples// Time all objects collector = createResourceTimingCollector(); collector.addEventListener(function(ev) { for (i = 0; i < ev.timing.length; ++i) console.log(ev.timing[i].url + “ finished loading at “ + ev.timing[i].loadEventStart); }); // Time specific object collector = createResourceTimingCollector(); collector.addEventListener(function(ev) { if (ev.timing[i].url == myImage.src) console.log(myImage.src + “ finished loading at “ + ev.timing[0].loadEventStart); }); Advantages - Can measure all resources - Caches timing so analytics can register late and not lose data Disadvantages - Window.load is a special case - No interface to isolate one resource Proposal 4: Event LogKeep a log of timing information that can be queried. The log is capped at 1000 entries by default. Once full, an event is fired and the log is cleared. Interfaceinterface Performance { PerformanceResourceTimingList getResourceTimings ([optional] in unsigned short initiatorType); void setResourceTimingBufferSize (in unsigned long length); void clearResourceTimings(); attribute Function onbufferfull; }; interface PerformanceResourceTimingList { readonly attribute unsigned long length; getter ResourcePerformanceTiming(in unsigned long index); }; Examples// Time all objects function dumpTimings() { timings = getResourceTimings(); for (i = 0; i < timings.length; ++i) console.log(timings[i].url + “ finished loading at “ + timings[i].loadEventStart); } document.addEventListener(“bufferfull”, dumpTimings); // Time specific object myImage.addEventListener(“load”, function(ev) { timings = getResourceTimings(RESOURCE_IMG); for (i = 0; i < timings.length; ++i) if (timings[i].url == myImage.src) console.log(myImage.id + “ finished loading at “ + timings[i].loadEventStart); }); Advantages - Can measure all resources - Can selectively record by resource type Disadvantages - UA and page must manage event log - Difficult to find a specific resource - Needs a separate mechanism to know when entries are added - Consumes memory when unused Further Reading 1. http://test.w3.org/webperf/specs/ResourceTiming/ 2. http://lists.w3.org/Archives/Public/public-web-perf/2010Nov/0001.html
Received on Tuesday, 30 November 2010 19:43:27 UTC