- 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