Note: This is a draft and may changed at any time. Previous charter is available.
- 1 Scope
- 2 Deliverables
- 2.1 Specifications
- 2.1.1 Navigation Timing
- 2.1.2 Performance Timeline
- 2.1.3 Resource Timing
- 2.1.4 User Timings
- 2.1.5 Page Visibility
- 2.1.6 Timing control for script-based animations
- 2.1.7 Efficient Script Yielding
- 2.1.8 Resource Priorities
- 2.1.9 Beacon
- 2.1.10 Diagnostics
- 2.1.11 Pre-render (link rel=prerender)
- 2.1.12 Display Performance
- 2.1.13 Async scroll
- 2.1.14 HTTP Archive (HAR) format
- 2.2 Other Deliverables
- 2.3 Milestones
- 2.1 Specifications
- 3 Dependencies and Liaisons
- 3.1 W3C Groups
- 3.2 External Groups
As Web browsers and their underlying engines include richer capabilities and become more powerful, web developers are building more sophisticated applications where application performance is increasingly important. Developers need the ability to assess and understand the performance characteristics of their applications, and they need the ability to write more efficient applications, using well-defined interoperable methods.
The Web Performance Working Group's deliverables include user agent features and APIs to measure and improve aspects of application performance. These deliverables will apply to desktop and mobile browsers and other non-browser environments where appropriate and will be consistent with Web technologies designed in other working groups including HTML, CSS, WebApps, DAP and SVG.
In order to advance to Proposed Recommendation, each specification is expected to have two independent implementations of each of feature defined in the specification. Out of Scope
The following items are not in scope:
- Does not provide a means to package and transmit the timing information back to a web service.
- Does not provide a method to profile and instrument server side code.
- Does not include performance data analysis techniques or algorithms.
The working group will deliver the following:
An interoperable means for site developers to collect real-world performance information from the user agent while loading the root document of a webpage. The user agent captures the end to end latency associated with loading a webpage from a web server. This includes the time associated with fetching the document from the network to the time associated to load the document within the user agent. This might include:
- timing associated with the network;
- timings associated with loading the document; and
- information about how the page was loaded, for example number of network requests.
This specification defines an unified interface to store and retrieve performance metric data.
An interoperable means for site developers to collect real-world performance information from the user agent while loading resources as specified from the root document of a webpage. The user agent captures the end to end latency associated with loading resources from a web server. This includes the time associated with fetching the resource from the network and the time associated to load the resource within the user agent. This might include:
- timing associated with the network;
- timings associated with loading the resource in the document;
- a resource may be one of the following elements: iframe, img, script, object, embed and link.
A new version of this specification will be produced to take into account media objects.
An interoperable means for site developers to capture timing information with a developer supplied name. The user agent captures the time stamp at the point and time specified in the code executing in the user agent.
An interoperable means for site developers to programmatically determine the current visibility of a document and be notified of visibility changes.
Timing control for script-based animations
An interoperable and efficient means for web page authors to write script-based animations where the user agent is in control of limiting the update rate of the animation.
Efficient Script Yielding
An interoperable means for site developers to efficiently yield and receive control flow.
An interoperable means for site developers to give the user agent hints on the download priority of resources.
An interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data will be eventually sent.
An interoperable means for site developers to get web browser diagnostics information on their web applications, like error logging and memory leaks type information.
An interoperable means for site developers to instruct the web browser to preload a web page while keeping it hidden to improve user perceived performance.
An interoperable means for site developers to get frame rate and throughput of the display type of information.
An interoperable means for site operators to smoothly scroll the viewport in the same way users can through the UI and monitor the scrolling performance. This will enable operators to properly benchmark and test their site's scrolling performance.
HTTP Archive (HAR) format
This specification defines an archival format for HTTP transactions that can be used by a web browser to export detailed performance data about web pages it loads.
In addition, the Working Group will review the specifications listed above to take into account Web Workers support.
Other non-normative documents may be created such as:
- Test suites for each specification;
- Primer or Best Practice documents to support web developers when designing applications with performance in mind;
- Best practice document explaining how data is commonly gathered between the client and the server.
Note: The following table has been updated with the new documents and according to the timetable of current documents. Milestones Note: The group will document significant changes from this initial schedule on the group home page.
|Performance Timeline||August 2011||September 2011||July 2012||April 2013||May 2013|
|Resource Timing||May 2011||August 2011||May 2012||April 2013||May 2013|
|User Timing||August 2011||September 2011||July 2012||April 2013||May 2013|
|Page Visibility||June 2011||July 2011||July 2012||February 2013||April 2013|
|Timing control for script-based animations||June 2011||February 2012||February 2013||April 2013||June 2013|
|Resource Priorities||June 2013||March 2014||September 2014||January 2015||February 2015|
|Beacon API||June 2013||March 2014||September 2014||January 2015||February 2015|
|Diagnostics API||June 2013||March 2014||September 2014||January 2015||February 2015|
|Pre-render extension||June 2013||March 2014||September 2014||January 2015||February 2015|
|Display performance API||June 2013||March 2014||September 2014||January 2015||February 2015|
|Asynchronous scrolling API||June 2013||March 2014||September 2014||January 2015||February 2015|
|HTTP Archive (HAR) format||April 2013||September 2013||December 2013||March 2014||May 2014|
Dependencies and Liaisons
Web Applications Working Group
This Working Group develops APIs for client-side development and for markup vocabularies for describing and controlling client-side application behavior. In particular, it develops DOM Core. The WebTiming proposal depends on the WebIDL specification.
HTML Working Group
This group will maintain and produce incremental revisions to the HTML specification. The HTML specification defines the window object.
CSS Working Group
The group develops and maintains CSS. Some of the deliverables, such as Page Visibility, may have impact on styling.
SVG Working Group
This group continues the evolution of Scalable Vector Graphics as a format and a platform.
Device APIs and Policy Working Group
This group create client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices services.
Web Application Security Working Group
This group will review the deliverables since performance measures can potentially leak important information.
Privacy Interest Group
This group monitors ongoing privacy issues that affect the Web, investigates potential areas for new privacy work, and provides guidelines and advice for addressing privacy in standards development.
ECMA Technical Committee 39 (TC39)
This is the group responsible for ECMAScript standardization, and related ECMAScript features like E4X. As the Web Performance Working Group will be developing ECMAScript APIs, it should collaborate with TC39.
Internet Engineering Task Force
The IETF is responsible for defining robust and secure protocols for Internet functionality, in particular HTTP.