Benchmarking Page Load Performance ================================== This version: http://www.hixie.ch/specs/onbenchmark/onbenchmark-1.0-pre4 Latest version: http://www.hixie.ch/specs/onbenchmark/onbenchmark Previous version: http://www.hixie.ch/specs/onbenchmark/onbenchmark-1.0-pre2 Editor: Ian Hickson, Opera Software Status of this document ----------------------- This is a draft proposal designed by Apple, Mozilla, and Opera, in order to get comparable benchmarking results across their three browsers. It has not been developed within a standards organisation and is not expected to be used in the field. The Benchmark Event ------------------- The "benchmark" event should be fired immediately after the page has loaded and painted. Note that the benchmark event is only relevant when the page is in foreground. If the page in question is in the background, benchmarking is largely irrelevant. In particular: All inline scripts and onload handlers should have run to completion before the benchmark event is fired (including any relevant DOM2 and DOM3 event observers). All subresources (stylesheets, alternate stylesheets, images, external scripts, background images, etc) should have loaded before the benchmark event is fired (because such resources have to be loaded before the 'load' event is fired, and the 'benchmark' event is fired after 'load'), unless such resources would not be loaded at all without further user action (for example, alternate stylesheets if these are loaded on demand, images while images are disabled, backgrounds for parts of the page that are not displayed if these are loaded on demand, etc). Note, however, that it can be a privacy violation bug to not load all backgrounds and other resources mentioned in a stylesheet, and that if alternate stylesheets are loaded on demand, scripts may need to load stylesheets synchronously if they try to access such sheets dynamically. The page must have painted and be displayed on the user's screen, including taking into account any changes caused by onload handlers. Upon meeting the above conditions, the UA should fire a "benchmark" event at the |document| node, which does not bubble, is not cancellable, and has no context information. In DOM3 Events processors, the "benchmark" event has the following namespace: http://www.hixie.ch/specs/onbenchmark If, and only if, the UA does not support DOM2 Events, the UA must instead execute script contained in the "onbenchmark" attribute on the node if the document is an HTML 4.x or XHTML 1.x document. UAs must never fire both the benchmark event and execute script in the aforementioned attribute. After the benchmark event has fired, assuming no timeouts have been set up, assuming no keyboard or mouse inputs, and assuming no animated resources form part of the page, the display should not change. This includes the browser's UI. For example, throbbers and status bars must be in their idle state at the time the benchmark event fires. Note: This is not a restriction on the implementation, it is an observation. If a UA has animated UI, then it is of course acceptable for that UI to continue to animate. The point is merely that the event should fire after the UI has been updated to tell the user that the page has finished loading. Asynchronous loads started during scripts that are fired before the benchmark event is fired, such as window.open() calls in onload handlers, as well as timeouts set up during the document load, should not be considered to block benchmark events from firing. (These should be avoided in benchmark test suites.) This specification does not attempt to specify whether the benchmark event should fire before or after timeouts are triggered. Every 'document' node should have the 'benchmark' event fired at it exactly once, except if the document is destroyed before the event could be fired. In the case of documents with frames whose document locations are not changed dynamically before their benchmark event is fired, the child frames should all receive their benchmark events before the parent document. Supporting this event must not cause any measurable difference in the time taken for the UA to render pages. Supporting this event must not cause any noticable change to the user's experience. Conceptually, it is expected that this event be implemented by changing the code that fires onload events so that it fires onload events, checks to see if any benchmark event observers are set up, and if so, forces a layout and paint of the document (if necessary) and then fires the benchmark event. However, in the absence of a benchmark event, and assuming asynchronous loads and timeouts do not actively try to navigate the UA away from the page, the behaviour should appear identical to the user. A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "BenchmarkEvent" and "1.0" (respectively) to determine whether or not this event module is supported by the implementation. In order to fully support this module, an implementation must also support the "Events" feature defined in the DOM Level 2 Events specification. Please refer to additional information about conformance in the DOM Level 2 Core specification. ------------------------------------------------------------------------