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.