W3C Web Performance: Continuing Performance Investments

I discuss the W3C Workshop on Performance in this IE Blog post article.

The W3C Web Performance working group recently held the W3C Workshop on Performance on Thursday, November 8, 2012. The goal was to hear current challenges and proposals for new performance ideas for the working group to consider. There were 45 attendees from 21 organizations, including most browser manufactures (Microsoft, Google, and Mozilla), hardware organizations (Intel, Qualcomm, Nokia, Motorola), network organizations (Cisco, Akamai, F5), and top Web properties (GMail, Google Search, Bing, NetFlix, LinkedIn, Zynga, and more). Details on the presentations and discussions from the workshop can be found in this report.

Providing the ability to accurately measure the performance characteristics of Web applications and create power- and CPU-efficient applications is critical to Web performance. The W3C Web Performance working group worked on achieving those goals in its recently completed second chartered period. In under two years, the working group rapidly standardized and modern HTML5-enabled Web browsers implemented these eight interfaces: Navigation Timing, Resource Timing, User Timing, Performance Timeline, Page Visibility, Timing control for script-based animations, High Resolution Timeand Efficient Script Yielding. Internet Explorer 10 is the first browser to support all eight of these new APIs.

The working group has since been focused on gathering data to understand which areas to focus on in its third chartered period. In addition to the Workshop on Performance, the working group has invited performance experts to its weekly conference calls and has broadly surveyed the performance community on ideas.

Based on all the data gathered these past few months, the Web Performance working group has decided to focus on the following areas in the third chartered period:

  • Timing Metrics The working group will continue to improve the Timing interfaces, Navigation Timing, Resource Timing, User Timing and Performance Timeline. For example, we will consider providing Web workers support in the Timing interfaces and including information on video byte ranges in Resource Timing.
  • Efficient Script Yielding The working group will continue to improve on power- and CPU-efficient APIs, like the setImmediate API defined in the Efficient Script Yielding specification.
  • Prerender The working group will standardized the prerender feature which allows navigations to appear almost “instantly” in cases where the browser has high confidence that a user will visit an URL. The way this feature would work is that the browser will proactively navigate to a Web page in a hidden tab, when it sees the “prerender” link type or has high confidence that user will visit that link. When the user does visit that link, the browser will make the hidden tab visible, giving the perception of instant navigation.
  • Resource Priorities Today, browsers download resources in the priority order that they believe are most efficient in helping the page load occur quickly. However, developers may want to prioritize some resources over others. For example, downloading images above the fold may be of higher priority than those below the fold. Though, developers can give some hints to the browser on download priority, like using the “defer” and “async” attributes in markup, these concepts do not include most resources. To help the browser prioritize downloading resources, the working group is expanding the charter to include interoperable means for developers to give the browser hints on the download priority of resources.
  • Diagnostics Interfaces Developers are interested in learning how to make their Web applications faster and less error prone. The working group is expanding the charter to include interoperable means for developers to get browser diagnostics information on their Web applications. For example, using these interfaces a developer could understand where memory is leaking or what errors users are encountering on their Web applications.
  • Beacon Today, analytics scripts will block the current page from unloading by running in a loop in order to confirm that analytics data has been sent to a Web server. This behavior will delay the navigation to the next page, resulting in user perception of poor performance. To help developers avoid that pattern, the working group is expanding the charter to include an interoperable means for developers to asynchronously transfer data from the browser to a Web server, with a guarantee from the browser that the data will eventually be sent.
  • Display Performance Developers are interested in understanding the performance of their games and animations.

    The working group is expanding the charter to include interoperable means for developers to get frame rate and throughput of the display type of information.

This working group is a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers. Together with industry and community leaders who participate in the working group, we hope to continue to make rapid progress on interoperable standards that will benefit developers and everyone who uses the Web.

Jatinder Mann, Internet Explorer, Program Manager


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s