Navigation Timing

Web Performance APIs Rapidly Become W3C Recommendations

In this IE Blog post article, I discuss how the W3C Web Performance APIS are rapidly becoming W3C Recommendations with interoperable support for all major web browsers.

The W3C Web Performance Working Group recently published three specifications as W3C Recommendations with full implementations from all major browser vendors, advancing developers’ ability to accurately measure the performance of Web applications and make the Web faster. Over the last three years, companies including Microsoft, Google, Mozilla, Intel, Facebook, and others have been working towards standardizing the Navigation Timing, High Resolution Time, and Page Visibility interfaces in the Working Group. Rapid adoption of these recommendations demonstrates what’s possible when the industry and community come together through the W3C.

To make the Web faster, developers need the ability to accurately measure the performance characteristics of Web applications and the ability to effectively use the underlying hardware to improve the performance of their applications. To solve these problems, the Web Performance Working Group worked on 15 different specifications that address those issues. The table below shows the maturity level of all the specifications currently edited by the Working Group.

The Navigation Timing, Resource Timing, User Timing, and Performance Timeline specifications help developers accurately measure the timing of the navigation of the document, fetching of resources on the page, and developer script execution. Prior to these APIs, this data wasn’t easily obtainable. Navigation Timing was published as a W3C Recommendation, and all major browser vendors support it. The other three interfaces are currently at the Candidate Recommendation stage awaiting two full implementations from browser vendors. IE10 is currently the only browser that implements all of these interfaces, however, other vendors are working on implementations.

To ensure these performance metrics are measured in the most accurate way possible, the High Resolution Time specification allows developers to measure operations with sub-millisecond accuracy. This interface not only benefits accurate measurements of performance metrics, but also allows better frame rate calculations and synchronization of animations or audio cues. This interface has been published as a W3C Recommendation, with all major browser vendors implementing the performance.now() method defined in the specification.

The Page Visibility API allows for programmatically determining the current visibility state of the page. Developers can use this data to make better CPU- and power-efficiency decisions, e.g., throttling down activity when the page is in the background tab. This specification has also been published as a W3C Recommendation, with all major browser vendors implementing it.

The Timing Control for Script-Based Animations, and Efficient Script Yielding specifications help developers write more CPU- and power-efficient Web applications. The requestAnimationFrame API, from the Timing Control for Script-Based Animations specification, allows for creating more efficient JavaScript animations. All browser vendors fully support this interface, with the Working Group actively working on publishing this specification as a Candidate Recommendation. The setImmediate API, from the Efficient Script Yielding specification, allows developers to efficiently yield control flow to the user agent and receive an immediate callback, efficiently leveraging the CPU. IE10 is the first browser to implement this interface.

This year the Working Group also started to look at new ideas, with editor’s drafts of those ideas currently being discussed in the Working Group. The Beacon API is intended to help scripts asynchronously transfer data to a Web server without blocking the unload event, which can negatively impact the perceived performance of the next navigation. The Resource Priorities API defines a means for Web developers to give the browser hints on the download priority of resources to help improve the page load time. As a corollary to the Timing specs, the Navigation Error Logging and Resource Error Loggingspecifications help developers understand the errors and availability of their applications. The Navigation Timing Level L2 specification adds High Resolution Time and Performance Timeline support to Navigation Timing, and High Resolution Time L2 specification adds Web Worker support. These are just some of the drafts the Working Group is currently defining, with more specification drafts on Prerender and other diagnostics areas forthcoming.

The W3C Web Performance 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 help developers make the Web faster.

Thanks,
Jatinder Mann
Internet Explorer Program Manager

IEBlog: Web Performance APIs Rapidly Become W3C Candidate Recommendations

In this IE Blog article, I discuss how the Web Performance APIs are rapidly standaridizing.

We’re pleased to share that three new W3C Web Performance Working Group specifications moved to W3C Candidate Recommendations. Accurately measuring the performance characteristics of Web applications is critical to making the Web faster. In addition, developers need the ability to effectively use the underlying hardware to improve the performance of their applications. Over the last two years, companies including Microsoft, Google, Mozilla, Intel, and Facebook have been working toward these goals through the working group. This is a great example of what’s possible when the industry and community come together through the W3C.

The Navigation Timing, Resource Timing, User Timing and Performance Timeline specifications help developers accurately measure Web application performance. The first three specifications provide developers with information related to the navigation of the document, resources on the page, and developer scripts, respectively. The Performance Timeline specification defines a unifying interface to retrieve this timing data. Prior to these API’s it was not possible for developers to accurately measure their site performance.

To ensure these performance metrics are measured in the most accurate way possibly, the High Resolution Time specification defines a sub-millisecond clock resolution. This interface not only benefits accurate measurements of performance metrics, but also allows better frame rate calculations and synchronization of animations or audio cues. For the first time developers can measure operations with sub-millisecond accuracy.

The Page Visibility, Timing control for script-based animations, and Efficient Script Yielding specifications help developers write more CPU- and power-efficient Web applications. The Page Visibility API allows for programmatically determining the current visibility state of the page. Developers can use this data to make better CPU- and power-efficiency decisions, e.g., throttling down activity when the page is in the background tab. The requestAnimationFrame API, from the Timing control for script-based animations specification, allows for creating more efficient JavaScript animations. Finally, the setImmediate API, from the Efficient Script Yielding specification, allows developers to efficiently yield control flow to the user agent and receive an immediate callback, efficiently leveraging the CPU.

In order to ensure Web developers only have to write code once and have it work interoperably in all browsers, the Working Group has worked diligently these last two years to standardize these APIs. The table below shows the maturity level of all the specifications currently being edited in the Working Group.

Table showing the status of W3C Web Performance Specifications

As of this month, the Navigation Timing specification has been published as a Proposed Recommendation (PR). This stage of standardization is the final step before a Web standard becomes an official W3C Recommendation. Additionally, this interface has been broadly adopted in browsers, including support since Internet Explorer 9, Chrome 6 and Firefox 7. The working group recently started incorporating feedback and working on Navigation Timing 2, the next version of the specification.

As of this month, User Timing, Performance Timeline and Page Visibility specifications have been published as a Candidate Recommendation (CR). This stage of standardization is prior to the PR stage and reflects that the W3C believes this specification has been widely reviewed and satisfies the Working Group’s technical requirements. Resource Timing was published as CR just two months ago, along with High Resolution Time, which went from an Editor’s Draft to CR in just three months.

These APIs are a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers. Thanks to everyone in the W3C Web Performance Working Group for helping design these APIs and to other browser vendors for starting to implement these APIs with an eye towards interoperability.

—Jatinder Mann, Program Manager, IE Performance

Improving Web Performance: It’s All In The (Navigation) Timing

I gave the following interview to the Benchmark: The Mobile & Internet Performance Review.

An interview with Microsoft IE Program Manager Jatinder Mann

Users’ thirst for speed seems increasingly unquenchable. Even as they (barely) tolerate the sluggish performance of mobile devices, they demand more and more of their PCs. Make them wait one blink of an eye too long, and they are gone, taking the revenue they would generate with them. In 2010, The World Wide Web Consortium chartered a Web Performance Working Group to give developers client-side tools, in the browsers, to gain greater visibility into the timing of each aspect of page loading and help them see how they can make their pages faster. The first product of the working group is the Navigation Timing API, which Keynote is already leveraging to provide more granular site performance reporting and to provide operations managers and developers a common language to address site improvements. Microsoft IE Program Manager Jatinder Mann lives and breathes performance, both on the Internet Explorer team and on the W3C Web Performance Working Group, and is an expert on the Navigation Timing API. Benchmark recently caught up with him to get an overview of the Navigation Timing API and other initiatives and what they offer the Web community.

Benchmark: You work on the Internet Explorer team and focus on performance, and you’ve also been involved with the Navigation Timing API. Tell us what’s going on in your performance world.

Jatinder Mann: The Web Performance Working Group was chartered about a year and a half ago with two main goals – making it easier to measure and understand the performance characteristics of Web applications, and also to define interoperable methods to write more CPU-efficient applications.

So together with Google, Mozilla, Facebook, and other industry leaders that participate in this working group, we designed a few APIs – Navigation Timing, Resource Timing, User Timing, and Performance Timeline. And these APIs help developers accurately measure Web performance.

The first three specifications – Navigation Timing, Resource Timing, and User Timing – define interfaces for Web apps to access the timing information related to the navigation of the document; also resources on the page and developer scripts. Performance Timeline defines the unifying interface to retrieve the data.

Benchmark: The Navigation Timing API is actually available now. What is it, and why is it important for website owners to know about it?

Jatinder Mann: The short answer is, Navigation Timing allows site owners to accurately measure how fast their site is loading for their customers.

And this is not like an instrumented build where you are looking at the server side. With Navigation Timing what you’re getting is data from actual client machines.

So let’s say you are trying to improve page performance for a site which varies from location to location. You can look at machines in various locales and figure out what their actual load times are and understand the different causes of the performance problems.

Before this API there really wasn’t a way to accurately measure that without instrumenting builds and whatnot. So this is natively done within the browser and that makes it much more powerful.

Benchmark: You mentioned some other specs, Resource Timing, et cetera. Can you give us a quick overview of those?

Jatinder Mann: Navigation Timing was getting the time for the document navigation, but if you look at the timeline of activities that happen for a page to load, that’s just the first portion. There’s also all the resources within a page. Resource Timing tackles that problem.

None of the browser vendors have actually implemented anything yet, mainly because the spec isn’t yet at the stage of standardization. But both IE and Chrome are very interested in implementing it as soon as the spec is in a good state which I believe will happen soon.

Then there’s User Timing which focuses on developer scripts within a page. Again, if we look at the timeline of how a web page is loaded and the point at which the user can start interacting with the page, there’s a lot of script execution happening. User Timing is designed for developers to measure the time it takes to execute the scripts on the page.

And all of this information is included in what we call the Performance Timeline. It’s a unifying interface where you can obtain timing data for any of these different measurements – you can get your Navigation Timing, your Resource Timing and your Script Timing through one interface.

Benchmark: So what does this mean in practice? How will it change what developers do?

Jatinder Mann: We’re giving performance information on things that developers can change. You can look at the time spent in these various phases, for example, if your page is very slow to load, you can look at Navigation Timing to understand the culprit. If you see that the redirects are taking too long, you may choose to reduce the number of redirects you’re doing for a page. If the DNS look-up phase is very slow, you may want to use DNS proxies or caching. And if connection times are slow, you can determine which locales are slow and build CDNs closer to those customers.

So a lot of the timing information here is actionable information – you get timing information about why your page is slow and there’re actions you can take to improve that.

Benchmark: A web page goes through a long series of steps and there are performance implications in every one of them.

Jatinder Mann: Yes. The advantage here is that now you can see the breakdown of where the time is being spent. As I mentioned earlier, if your redirects are taking too long, as an owner of a website I may choose to reduce the number of redirects, or be careful of what server I’m redirecting to. Maybe that server’s slow.

Benchmark: So the goal of all this is to make the experience faster for the users. That’s obviously a focus of the IE team and of the working group. What is Microsoft’s perspective on speed? Have you identified any critical thresholds that guide what you do?

Jatinder Mann: For many releases now we’ve made significant product changes to IE to make sure it’s fast and fluid for end users. For example, hardware-accelerated HTML5 implementation, and reworking our layout and JavaScript engines from scratch. I don’t know if it’s easy to characterize a threshold, because we see that the Web consists of many different patterns.

Within our IE performance lab we test many different pages, representative of patterns on the Web, and try to improve those patterns.

For example you can have five different news sites and they may all be using different patterns. So it’s not as easy as saying ‘improve JavaScript and all Web pages will be faster’ because some sites may be JavaScript heavy, some may be layout heavy.

Benchmark: What is your sense of the how the developer community and the site community are embracing this API? Or is it still too early to tell?

Jatinder Mann: Keynote, for example, has already started performance monitoring using this API. Facebook had a lot of requests for this API while we were building it. So I’m certain at least for Resource Timing, once that’s available, they may be interested as well. And there are many Microsoft teams that are looking at this API.

So there’s definitely some interest already through people that are in the business of performance improvement and I would love to see more site owners start using these tools to improve their site performance.

Benchmark: What’s next for the working group?

Jatinder Mann: My expectation is that Resource Timing, User Timing and Performance Timeline will probably be the next ones that the browser vendors will want to implement, mainly because it would complete the story with Navigation Timing and you would get the complete Performance Timeline view.

That’s something I think would be very interesting, coming up very soon.

Benchmark: Very soon as in 2012?

Jatinder Mann: It’s hard to say. But I would say, yes, very soon. Chrome, and IE, and Mozilla are all active in this working group and I think we all appreciate that Navigation Timing is out there and it’d be nice to get the next set of things out there too.

Benchmark: So to close, what is the most important thing to communicate about the new Navigation Timing API and its use?

Jatinder Mann: The Navigation Timing API is a new way to get information about what’s happening in the browser that wasn’t available before or was difficult to get. This API makes it easier for developers to identify ways for improving Web performance.

IEBlog: The Year in Review: W3C Web Performance Working Group

In this IEBlog article, I look back at a year in the W3C Web Performance Working Group:

17 Aug 2011 9:36 AM

Fast HTML5 Web applications benefit consumers who browse the Web and developers building innovative new experiences. Measuring performance characteristics of Web applications and writing efficient applications are two important aspects of making Web sites fast. Browser manufacturers can rapidly address developers’ needs through interoperable APIs when collaboratively partnering through the W3C.

One year ago today, the W3C announced the formation of a Web Performance Working Group chartered with two goals: making it easier to measure and understand the performance characteristics of Web applications and defining interoperable methods to write more CPU- and power-efficient applications.

Together with Google, Mozilla, Facebook, and other industry and community leaders who participate in the W3C Web Performance Working Group, we designed the Navigation Timing, Resource Timing, User Timing and Performance Timeline specifications to help developers accurately measure Web application performance. The first three specifications, Navigation Timing, Resource Timing, and User Timing, define interfaces for Web applications to access timing information related to the navigation of the document, resources on the page, and developer scripts, respectively. The Performance Timeline specification defines a unifying interface to retrieve this timing data.

Resource Timing, User Timing, and Performance Timeline specifications are all in the Last Call phase of specification. Last Call is a signal that the working group believes the spec is functionally complete and is ready for broad review from both other working groups and the public at large. This Last Call period extends until September 15, 2011. The Navigation Timing specification is already in the Candidate Recommendation phase and has two interoperable implementations, starting with Internet Explorer 9 and Chrome 6. Together these APIs help Web developers create faster and more efficient applications by providing insights into the performance characteristics of their applications that just weren’t possible before.

Over the last four months, the Web Performance Working Group defined interoperable methods to write more CPU- and power-efficient applications by producing the Page Visibility, Timing control for script-based animations, and Efficient Script Yielding specifications. The Page Visibility specification is in the Last Call phase until September 8th and has two implementations starting with the second IE10 Platform Preview and Chrome 13. The requestAnimationFrame API, from the Timing control for script-based animations specification, has three implementations starting with the second IE10 Platform Preview, Firefox 4 and Chrome 10. This specification is very close to entering Last Call. For more information on these two APIs, see the blog posts on using PC Hardware more efficiently with these APIs (link and link). IE10 is the first browser to implement the emerging setImmediate API from the Efficient Script Yielding specification.

It’s encouraging to see how much progress we’ve collectively made in just one year. These APIs are a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers. Thanks to everyone in the W3C Web Performance Working Group for helping design these APIs and to other browser vendors for starting to implement these APIs with an eye towards interoperability.