W3C

Web Performance Working Group Charter

The mission of the Web Performance Working Group, part of the Rich Web Client Activity, is to provide methods to enhance aspects of application performance of user agent features and APIs.

Join the Web Performance Working Group.

End date 31 May 2015
Confidentiality Proceedings are public
Initial Chairs Arvind Jain, Google,
Jason Weber, Microsoft
Initial Team Contacts
(FTE %: 5)
Philippe Le Hégaret
Usual Meeting Schedule Teleconferences: Weekly
Face-to-face: we will meet during the W3C's annual Technical Plenary week (if space available); an additional face-to-face meeting may be scheduled by consent of the participants
IRC channel: #webperf

Scope

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.

Success Criteria

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:

Deliverables

The working group will deliver the following:

Performance Timeline
This specification defines an unified interface to store and retrieve performance metric data.
Navigation Timing 2
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. The Group produced a first version of Navigation Timing.
Resource Timing 1 & 2
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.
User Timings
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.
Page Visibility
An interoperable means for site developers to programmatically determine the current visibility of a document and be notified of visibility changes.
Efficient Script Yielding
An interoperable means for site developers to efficiently yield and receive control flow.
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.
Resource Priorities
An interoperable means for site developers to give the user agent hints on the download priority of resources.
Beacon
An interoperable API 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.
Diagnostics
An interoperable means for site developers to get web browser diagnostics information on their web applications, like error logging and memory leaks type information.
Pre-render (link rel=prerender)
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.
Display Performance
An interoperable means for site developers to get frame rate and throughput of the display type of information.
Async scroll
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.

The specifications will include privacy and security considerations.

Other Deliverables

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.

Milestones

Milestones
Note: The group will document significant changes from this initial schedule on the group dashboard.
Specification FPWD LC CR PR Rec
Performance Timeline
Aug 2011 Sep 2011 July 2012 April 2013 May 2013
Resource Timing May 2010 August 2011 May 2012 April 2013 May 2013
User Timing May 2011 September 2011 July 2012 April 2013 May 2013
Page Visibility August 2011 September 2011 July 2012 February 2013 April 2013
Timing control for script-based animations June 2011 February 2012 March 2013 May 2013 July 2013
Resource Priorities June 2013 March 2014 September 2014 January 2015 February 2015
Beacon APIJune 2013 March 2014 September 2014 January 2015 February 2015
Diagnostics APIJune 2013 March 2014 September 2014 January 2015 February 2015
Pre-render extensionJune 2013 March 2014 September 2014 January 2015 February 2015
Display performance APIJune 2013 March 2014 September 2014 January 2015 February 2015
Asynchronous scrolling APIJune 2013 March 2014 September 2014 January 2015 February 2015
HTTP Archive (HAR) formatApril 2013 September 2013 December 2013 March 2014 May 2014

Dependencies and Liaisons

W3C Groups

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.
Web Applications Security Working Group
This Working Group develops security and policy mechanisms to improve the security of Web Applications, and enable secure cross-site communication. Performance measures can potentially leak important information related to security and privacy. The work on the Diagnostics API should be coordinated with the Content Security Policy 1.0 specification, which allows user agents to report policy violation.
HTML Working Group
This group will maintain and produce incremental revisions to the HTML language. The Web Performance Working Group uses many concepts from the HTML5 specification.
CSS Working Group
The group develops and maintains CSS, which is relevant for specifications such page visibility or Timing control for script-based animations.
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.
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.
Protocols and Formats Working Group
The mission of the PF Working Group is to ensure W3C specifications provide support for accessibility to people with disabilities.

External Groups

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. The Working Group should coordinate protocol-related work (e.g. profiles of hybi or HTTP) with the appropriate IETF WGs.

Participation

To be successful, the Web Performance Working Group is expected to have 10 or more active participants for its duration. The Chairs and specification Editors are expected to contribute one day per week towards the Working Group. There is no minimum requirement for other Participants.

The Web Performance Working Group will also allocate the necessary resources for building Test Suites for each specification.

The group encourages questions and comments on its public mailing lists, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.

Communication

Most Web Performance Working Group Teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its work on the public mailing list public-web-perf@w3.org (archive). The public is invited to post messages to this list.

Information about the group (deliverables, participants, teleconferences, etc.) is available from the Web Performance Working Group home page.

The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Web Performance Working Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Web Performance Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Changes


Philippe Le Hégaret

$Date: 2013/06/06 08:00:28 $