Web Performance APIs Rapidly Become W3C Recommendations

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 Logging specifications 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

Comments

• Anonymous
  May 21, 2013
  That's nice and all but IE10 still suffers from memory leaks. When will you fix those?

• Anonymous
  May 21, 2013
  You have a data leak. Others like me do not have that issue. So it could be caused by something you do or you have installed. You have not provided a meaningfull reprodcution of the issue

• Anonymous
  May 21, 2013
  The comment has been removed

• Anonymous
  May 21, 2013
  I've also experienced a separate issue which seems related to Telerik controls.  There seem to be some circumstances where IE10 will issues a POST that has a valid body size, but a zero length body...immediately followed by a new POST with the same size, and the correct body contents.  This confuses the heck out of IIS, and basically everything just hangs.  It's very reproducible with specific situations.  Forcing IE9 doctype makes things better but it still occasionally hangs.  Forcing IE8 doctype fixes the issue.  We've applied a Hotfix that was designed to fix some issues with IE10 (double-digit version numbers apparently causing some issues somewhere in .Net) and that fixed a few scenarios but not the main ones.  This wasn't reproducible on other browsers.  I don't have a lot more information than this (others I work with have been trying to debug this, and once the IE8doc-type fix was found, we moved on out of sheer frustration and need to get actual work done).  But I hope this issue is "known" and being worked on, even if you have to work with telerik to get it fixed.

• Anonymous
  May 22, 2013
  One thing I might add is that, since IE10 uses multiple processes, the problem only happens when one of those processes run out of memory which could mean quite a lot of time. However you can fasten up the reproduction by setting TabProcGrowth = 1 in registry, which limits IE to use a single tab. Some plugins require this due to not being 100% compatible with IE8/9/10. HOWEVER, the memory leak still happens regardless of those, using single tabs merely exuberates the problem.

• Anonymous
  May 22, 2013
  This comment was meant to go first, but the blog engine ate it. I have tried IE10 both in 32bit and 64bit modes, with and without my usual plugins, in private mode, with all options reseted to default (and reboot), as well as the option that explicitly runs IE10 in no-addon mode. Any and all combinations had the memory leak present. Steps to reproduce:

1. open a page, any page (but preferably one rich with media, HD youtube movies are a good choice, but so is opening multiple tabs of ebay pages with big descriptions!)
2. close the page Many of the contents will still remain cached in memory.
3. repeat 1 and 2 and watch the memory usage of the IE process(es).
4. once the processes reach 2gb of virtual memory usage (task manager shows around 1gb there), 32bit IE will hang up due to running out of memory space. Pages can become unresponsive, images will stop working, entire tabs might hang up, etc. Only solution is to close the process. 64 bit IE10 still swells up the same way, and the only reason it does not hang up is because it has a higher floor for RAM usage due to being 64bit. This is all tested on Windows 7 x64. But many users have reported it on Windows 8 as well. And this is NOT the first time I typed these steps, but they go ignored on the blog.

• Anonymous
  May 22, 2013
  opened and closed youtube multiple times - the memory was released - it certainly did not increase opened about 50 youtube tabs - 2,5 GB memory usage. There was some swapping to disk, but no choking to death closed all the youtube tabs - memory went back to normal This is not a windows-wide problem, but only occurs on some systems. On my system it's a "can't reproduce"

• Anonymous
  May 22, 2013
  @anonym: it's not an issue you can reproduce in half a minute. Note that when you close your tabs, the memory levels will not return to exactly what they were - some data remains in memory. This will keep piling and piling up, and eventually you get huge memory usage even with no tabs open (sans a single about:blank). It may take minutes, it may take hours, or even a day long session without restarting IE. Add-ons will of course fill the memory faster, but the fact is, there is a problem in IE itself.

• Anonymous
  May 22, 2013
  Tried with 30 youtube tabs. Played all the video's. Left the tabs open overnight. Open new tabs to several sites without hitches Closed all youtube tabs. IE went down to a few hunderd MB with stil about 5 of the other non-youtube tabs open. No detectable memory leaks.

• Anonymous
  May 23, 2013
  Re tabs becoming consolidated in one iexplore.exe process mentioned by pmbAustin, I have noticed this too, but on Windows 7 x64.  It appears that if a tab process crashes/freezes, IE10 reloads the tabs in another existing tab process, which means eventually if the browser is left open you can end up with only a single tab process.  This seems to be completely different behaviour to older versions which I believe generated at least one new tab process after a tab group crashed, sometimes as many as there were tabs in the crashed process.

• Anonymous
  May 23, 2013
  Tried all scenarios mentioned in IE10 on Win7 and 8.  Browsed for over 6 hours straight, left IE open for a full day.  Browsed some more.  No memory leaks.

• Anonymous
  May 23, 2013
  Resource priorities seems like a great idea. But what if we want it the other way - set higher priority? If I for example have an image which should be downloaded before anything else, I would with this approach have to put it either as the first element in the DOM, or set the lazyload element on all other elements. And what about JavaScript APIs? Does the vendors care about lazyload attributes added with JavaScript? This could be necessary for Single Page Apps.

• Anonymous
  May 25, 2013
  Speaking of standards, Microsoft Internet Explorer doesn't recognize :fullscreen pseudo-selector stackoverflow.com/.../1712065 And I thought you guys have incorporated all living standards in IE10. Please revert.

• Anonymous
  May 26, 2013
  :fullscreen is part of a spec which is still at the working draft stage.

• Anonymous
  May 28, 2013
  A little problematic

• Anonymous
  May 29, 2013
  Excellent

• Anonymous
  May 31, 2013
  Another issue I'm constantly having is pages just crashing and reloading silently (some tab in the background).  When this happens, some percentage of the time, it loses cookie information.  Sometimes a little bit (a few things on the page have to be re-entered... it "forgets" that I had it remember the password, or a setting out of several is reverted to default), sometimes completely (ALL cookie-based information is just lost, and it's like I'm going to the site for the first time ever).  It's very annoying and very frustrating. It happens on a regular basis.  This was a problem in IE9 as well.  Any time the app crashed (whether being killed via task manager, crashing because "something went wrong on the page and it had to reload", or the power is cut), there is a significant (though less than 50%) chance that some or all cookie data for a page will just disappear. I can't believe I'm the only one this is happening to, given it's across two different machines and two versions of IE (both desktop versions).

• Anonymous
  June 02, 2013
  The comment has been removed

• Anonymous
  June 02, 2013
  Just tested with IP adres 173.194.78.101 in IE10. No prefix Opens Google.com instantly on http So you seem to be incorrect on your suggeted issue.

• Anonymous
  June 02, 2013
  Re ip: Don't know what is different, but in IE 8 (W8), when IP address is used it first tries it (with http) and only when connection fails, it does search. (Windows 7, it fails outright)

• Anonymous
  June 03, 2013
  On Windows Phone, there is no option to set google as your default browser. Now get back to your clumsy google +1 space and let the elders take care of the situation.

• Anonymous
  June 03, 2013
  Google.com is a website. Not a browser. And it was opened in IE10. That is a browser. Coincidentally also a browser availlable on windows phone 8 And even on Windows Phone 8 using the ip adres of 173.194.78.101 WITHOUT the http prefix stil opens google.com without any problem.

• Anonymous
  June 03, 2013
  The comment has been removed

• Anonymous
  April 26, 2015
  Internet Explorer team is worse when it comes to coping with community requirements, among all the teams at Microsoft! <a href="gtaonlineargent.com/">gta 5 online argent</a>

• Anonymous
  April 26, 2015
  Internet Explorer team is worse when it comes to coping with community requirements, among all the teams at Microsoft! gta5onlineargent.resourcesgenerator.com