![Interaction Domain](http://www.w3.org/Icons/interaction)
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.
End date |
31 May 2016 |
Confidentiality |
Proceedings are public |
Initial Chairs |
Ilya Grigorik, Google Todd Reifsteck, Microsoft |
Initial Team Contacts
(FTE %: 5) |
Philippe Le Hégaret, Xiaoqian Wu |
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:
- method to profile and instrument server side
code;
- performance data analysis techniques or
algorithms.
Deliverables
The working group will deliver the following:
- Performance
Timeline
- This specification defines an unified interface to store and
retrieve performance metric data.
- Performance Observer
- This specification defines an interface to register a PerformanceObserver
callback to receive PerformanceEntry events. This is useful to allow
addition of PerformanceEntry sources to the platform.
- 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 Hints
- An interoperable means for site developers to give the user agent
hints on prioritization of download to prerender 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.
- Network Error Logging
- An interoperable means for site developers to register to have
network errors recorded by the user agent and sent to a uri.
- Preload
- An interoperable means for site developers to instruct the web
browser to preload a resource using link tag before script is executed.
- Frame Timing
- Previously named Display Performance, an interoperable means for site developers to get frame rate and
throughput of the display type of information.
In addition, the Working Group will review the specifications listed
above to take into account Web Worker and Service Worker 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
publication dashboard. |
Specification |
FPWD |
LC |
CR |
PR |
Rec |
@@
| @@
| @@
| @@
| @@
|
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 github issues and the public mailing
list public-web-perf@w3.org
(archive).
The
public is invited to contribute to the github repositories and post messages to the 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, @@@
Copyright© 2015 W3C®
(MIT, ERCIM, Keio, Beihang).
$Date: 2013-06-06 08:00:28 $