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

[Resource Timing] Summary of initial proposals

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 30 Nov 2010 11:42:55 -0800
Message-ID: <AANLkTikpfjHWDYbaR7E+zJpxMP99BF4cZ-wf_h4nc6Ch@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:56 GMT