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.

Specification Editor’s Draft First Public Working Draft Last Call Candidate Rec Proposed Rec Rec
Navigation Timing Sept 2010 Oct 2010 Jan 2011 Mar 2011 July 2012 Dec 2012
Resource Timing Sept 2010 May 2011 Aug 2011 May 2012
User Timing Oct 2010 Aug 2011 Sept 2011 July 2012
Performance Timeline July 2011 Aug 2011 Sept 2011 July 2012
High Resolution Time Feb 2012 Mar 2012 Mar 2012 May 2012 Oct 2012 Dec 2012
Page Visibility Apr 2011 June 2011 July 2011 July 2012 Feb 2013 May 2013
Display Paint Notifications May 2011 June 2011 Feb 2012
Navigation Timing L2 (NEW) Jan 2013 Jan 2013
Efficient Script Yielding June 2011
High Resolution Time L2 (NEW) Apr 2013
Beacon (NEW) Mar 2013
Resource Priorities (NEW) Apr 2013
Navigation Error Logging (NEW) Apr 2013
Resource Error Logging (NEW) Apr 2013
Prerender (NEW)

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.

Jatinder Mann
Internet Explorer Program Manager

Comments (25)

  1. Arieta says:

    That's nice and all but IE10 still suffers from memory leaks. When will you fix those?

  2. @Arieta says:

    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

  3. pmbAustin says:

    I too experience the resource leak.  On a very regular basis.  Leave a bunch of tabs open for a long time (through 'sleep' cycles) on Windows 8, and eventually memory use will go up, tabs will somehow become "consolidated" in one iexplorer.exe process, and page rendering (and even rendering of resources in common dialogs like the 'save as' dialog or 'open file' dialog) will cease or glitch.  The most common first indicator for me is going to Facebook, and the top bar (with the notifications and navigation commands and search…the blue bar) will simply disappear.  At that point, more and more things render blank, including files in the file-open dialog (like when trying to choose a picture to upload to facebook).  When this happens, if I go to task manager details, I ALWAYS see one iexplorer.exe process with over 800M of memory (and a couple of others that are small).  When I kill that process, almost EVERY tab reloads, as if they had all been running in one tab.  But that does "fix" the problem.  I see this at LEAST once a week, sometimes (though rarely) as often as twice a day depending on my use.

    It very well could be something that sites/pages are doing, but clearly it's something IE doesn't handle well whatever it is.  I've taken to monitoring the number of handles in use, and while it is high (over 5,000, generally over 6,000) at the point these problems happen, it's not over 10,000 which is the guidance I was given earlier for what to look out for.  It is NOTICABLY higher than other processes though, or the number of handles in use by iexplore.exe when I'm not having the issue.

    This is using Desktop IE10 on Windows 8.

  4. pmbAustin says:

    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.

  5. Arieta says:

    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.

  6. Arieta says:

    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.

  7. anonim says:

    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"

  8. Arieta says:

    @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.

  9. @Arieta says:

    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.

  10. fr says:

    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.

  11. nope says:

    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.

  12. Mikael Söderström says:

    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.

  13. Tom says:

    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.

  14. @Tom says:

    :fullscreen is part of a spec which is still at the working draft stage.

  15. Joseph Hector says:

    A little problematic

  16. George Delgado says:


  17. pmbAustin says:

    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).

  18. @pmbAustin says:

    Have you ever experience this issue: Open IE, type an ip address and hit enter. It will take you to the bing search! All other browsers handle it with http automatically, while IE expect http:// prefix explicitly.

    IE mobile on Windows Phone 8 has also the same issue. I am a web developer and I frequently use IP addresses for testing my websites on different devices. Why on earth would they expect us to prefix the ip with http!

    pmbAustin, reading your comments over and over make me so hopeless that I don't want to file this complain on connect because they don't listen. Same canned replies followed by closing tickets while the bug is still alive.

    Internet Explorer team is worse when it comes to coping with community requirements, among all the teams at Microsoft! Millions of legit and reproducible issues at connect are closed with lame arguments and false hope. They are sealed minded people and embarrassment for the bigger software house on planet! I hope, I really really hope that someone will fire the whole lot of them and get a new fresh blood in the team and when we submit a feedback on Connect (or uservoice) they will revert back with REAL answer and REAL ETAs as "Cant give ETA" is not an option in the world of browsers but its considered as a lazy ass excuse.

  19. @ @pmbAustin says:

    Just tested with IP adres in IE10. No prefix

    Opens Google.com instantly on http

    So you seem to be incorrect on your suggeted issue.

  20. Klimax says:

    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)

  21. @ @ @pmbAustin says:

    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.

  22. @ @ @ @pmbAustin says:

    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 WITHOUT the http prefix stil opens google.com without any problem.

  23. @ @ @ @ @pmbAustin says:

    I meant default search engine. You cant change default search engine in Windows phone.

    You are missing my point. Here is to reproduce it:

    – Run webserver in your system.

    – Access your LOCAL website in Firefox on your desktop/laptop (your machine IP (colon) port#) without http.

    – Try it on IE10 desktop or windows phone 8, it will take you to the search result page.

    This is annoying and it pisses off hundreds of developers every day (besides the ugliest page-inspected F12 dev tools even known to mankind).. Bu I guess with 8.1 (IE11) they are "reimagining" F12DT and I do thank them for that! Hope its as flexible as firebug and chrome's page inspector.

  24. Kassandra says:

    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>

  25. Kassandra says:

    Internet Explorer team is worse when it comes to coping with community requirements, among all the teams at Microsoft!