Microsoft to Co-Chair New W3C Web Performance Working Group

Earlier this morning the W3C announced the formation of a new Web Performance Working Group chartered with making it easier to accurately measure web application performance. Enabling web developers to understand the real world performance characteristics of their applications is critical to the success of HTML5, and we’re excited to have been selected as co-chairs of the new working group alongside Google. We look forward to partnering with the W3C and the broader web community to enable these scenarios through an interoperable API.

The first deliverable for the working group is to recommend an API that measures the performance of browser navigations. The WebTimings specification provides a good starting point for these capabilities, so this specification will move into the Web Performance Working Group and become the foundation for our recommendations.

The third Internet Explorer 9 Platform Preview was the first browser to implement these portions of the WebTimings specification. Following standard conventions, we used a vendor prefix (ms) on the name because the specification was still under active development and hadn’t been brought into the charter of any working group. Google also recently provided an early implementation of these API’s inside Chrome using their vendor prefix (webkit). Through early collaboration between our engineering teams, we almost have interoperable implementations which is impressive for an API that has only been discussed for a few months. This is a great example of what’s possible through collaborative partnerships at the W3C.

With two early implementations available, it shouldn’t take long to finalize an interoperable API and remove the vendor prefixes. We can’t do this alone though – the new working group needs your feedback to ensure we have the right design. Over the next few weeks we’ll post more details on the working group website and begin to solicit feedback. In preparation, you can try out these API’s using the IE9 Platform Preview or Chrome 6 nightly builds. To help you get started take a look at the msPerformance demo on the IE9 TestDrive which shows these API’s in action.

Jason Weber
Lead Program Manager for IE Performance

Comments (35)

  1. Bob says:

    "we’re excited to have been selected as co-chairs of the new working group alongside Google."

    I bet the Richter Scale could pick up the tension in that room.

  2. Rob says:

    Great. Now we'll have to hear about hardware accelerated marquee tags and how well IE9 interfaces to Office.

  3. Macrohard says:

    Speaking of performance, is IE9 going to have a mechanism to fall back on CPU rendering if it detects a fast CPU with a slow GPU?

  4. Alex says:

    Bob. the Richter Scale is not an instrument. Sheesh.

    Rob. Every vendor has the right to pitch their product. Everyone does it. You're just a little sensitive. Truth be told, IE9's GPU acceleration blows every browser out there out of the water right now. Yes, they'll catch up. Be happy.

  5. Meni says:

    Just responding to the heading:

    These are exciting times, I hope the stagnation of the years 2000-2010, will be behind us. Microsoft, please help move the web forward. Its imperative that a faster standards body be created. w3 is tooooo sloooow. I grant you that previous attempts might have been Microsoft hostile. For example i read [citation needed] that VML is more natural then SVG, and that event model of IE4 is more natural then w3 events. BUT, once a standard is chosen, fight your ego and support it. Had Microsoft supported SVG in 2001, the web IMO would have been better!

    As far as faster standards, I was thinking along the lines of a sealed room, no one leaves until we have a standard πŸ™‚

    We need support for better sound, better JavaScript (Harmony), 3D, video camera, video synchronization. In other words everything flash and silverlight and java applets do.


  6. Stilgar says:

    Macrohard I doubt you can find a GPU so slow and a CPU so fast on the same machine that the CPU will render graphics faster.

  7. mitch074 says:

    @Alex: IE9's hardware acceleration isn't much faster than Firefox 4's (YMMV). Opera isn't much slower than both, eventhough it DOESN'T use Direct2D hardware acceleration (it uses another acceleration technique). It is merely strongly optimized for Direct2D – all other browsers have to contend with platforms that don't have Direct2D at all (WinXP, OS X, GNU/Linux…)

    @Meni: VML includes a feature that allows more natural effects than SVG. However, the part that really blocks SVG is in its animation language: currently, it uses SMIL – while it would be more natural to use ECMAscript (which has 2 well-known implementations: Javascript and ActionScript). That part is being addressed (note that it is already possible to animate SVG with Javascript through SVG DOM manipulation, but it's not exactly streamlined) through a future revision of SVG.

    @Stilgar: case in point, an IGP on a quad core. Currently, most software rasterizers are badly optimized, which makes CPU rendering rather slow. However, some experimental or proprietary software multithreaded renders do work well (see how Opera works). Moreover, the problem with graphics isn't a matter of raw horsepower, but more of bus contention and latency: this happens when, say, an interface element is sent to the GPU for processing, then has to be read back in system RAM for CPU treatment, then sent back to the GPU. And when THAT happens, you can make a quad SLI on PCIe2.0 x16 mounted cards crawl down to a stop, even when running at full tilt with all lanes enabled. So, imagine about an IGP running in power saving mode on a single PCIe lane…

    In THAT case, a software renderer that blits to the graphics hardware will kick a hardware renderer's behind quite strongly.

  8. Saitir says:

    @mitch074 "all other browsers have to contend with platforms that don't have Direct2D at all (WinXP, OS X, GNU/Linux…)"

    Just to be a pedant, all other browsers do not 'HAVE' to contend with other platforms, they simply choose to, no gun to their head and all that.  World of difference!

    Of course there are several arguments on cross platform availability and performance…

    One is that all OS platforms are not equal, so don't even try to make your software exactly the same (middle of the PC age model).

    Two is that software vendors demand abstraction api's so that the underlying OS is less and less in the way of the hardware (early OSs, a current thrust of things). and their cross platform lives are made simpler.

    But my opening point remains the same, there's absolutely zero requirement for you to be cross platform.  If you choose to make you software on multiple platforms, is it really the OS vendor's problem if it makes your life hard?

  9. Miguel Web Developer says:

    Here some cool information about web workers:…/html5-web-workers

  10. Senthil says:


    "..sealed room, no one leaves until we have a standard.."

    If that is enforced with the current W3C, we need to have facilities to procreate and maternity wards.. schools and maybe highschools for the participants' children!

    … because that's how long its going to take! πŸ˜›

  11. Jeffrey Gilbert says:

    thanks for continuing to support web standards in a way that makes my developer life suck less and less. also, please activate those backdoors you installed on on the windows machines running ie 6-8 and upgrade them to this version forcefully. I bleed workarounds πŸ™

  12. Mike says:

    This is terrific.  Thanks for the support.

  13. Raffi says:

    Does anyone find the fact that Firefox is using Direct2D like IE9 hilarious?  I mean, it's exclusive to Windows Vista and 7, and its supposed to be a cross-platform browser.  I wonder if they're using XPS for printing as well.

    It also shows that the D2D must be a way better technology than OpenGL for building hardware acceleration into the browser if they sacrificed cross-platform support for it.  It also put them ahead of Chrome and Opera.

  14. Bas says:

    @Raffi: Even if you would want to use OpenGL, developing the vector renderer on top of it would take considerable effort. Current Cairo OpenGL backends have not succesfully been made to perform sufficiently to date. Direct2D takes a lot of this work off our shoulders by providing an extremely efficient and complicated vector graphics renderer. Hence OGL would not really have been an option at all.

  15. Miguel Web Developer says:

    @Raffi  Specifically: Firefox 4 is going to use hardware acceleration through Direct2D and DirectWrite on Windows, are similar things coming up for Linux and Mac OS X?

    Chris Blizzard: Within what's provided: Yes. We're trying to give the best experience possible on each platform. So for Windows Vista and 7 we see huge improvements when doing certain graphically intensive stuff. On OS X for example we have support for OpenGL for doing compositing, on Linux we do the same. But generally the Windows APIs that we have are better and more rich than what we have on other platforms. To give you an example: On Linux Cairo and Pixman were supposed to be fast, but unfortunately the underlying infrastructure never really got fast. On OS X we are actually pretty fast but Direct2D gives the performance advantage to Windows at the moment.


  16. jabcreations says:

    Mozilla has dropped the ball with Firefox 4 in regards to performance as it totally fails my benchmark (Version 2.9). Only Opera actually visually executes the benchmark and only about a third of it. I haven't tested IE9 on a non-emulated copy of Windows since I will run XP until I either find a Linux distro that doesn't annoy me or Microsoft undoes all the GUI destruction from Vista/7 however that being said Firefox 0.7-3.6 runs the benchmark fine on emulated versions of Windows without any problem as well as on my netbook.

    There are NUMEROUS ways to test performance; running hundreds of iterations of the same function only tests the speed that the rendering engine can parse that exact bit of code. In some ways Firefox 0.7 is much faster then the latest copies of Chrome, Opera, or IE9 while Ie9 is much faster on other things. It's just gaming benchmarks, some games put more emphasis on the CPU then the GPU and vice versa. The ultimate goal for browser performance parallels that of video games in example. Most LCD's max out at 60Hz (120Hz are for 3D gaming that splits the frames hence an effect 60Hz when using 3D technology so NOT the full 120Hz). Playable FPS is generally considered to be 30 FPS+ (this can vary between 24-40 FPS depending on the game). I see a lot of benchmarks like UT3 with 200 FPS+ which is pointless. When it comes to gaming I'm interested in getting playable FPS (generally 40+) rather then the absolute maximum as I don't game morning noon and night (and past 60 FPS it's purely excess that you don't benefit from in any way). Scoring well on ALL browser benchmarks then scoring the best on one or two is a better approach. So long as the user is happy with the performance then increasing the performance past that point will not gain anything for the extra work put in to it. So variety in performance is the key.

    Any way, my benchmark will become available once I get to beta with 2.9…so race you guys to beta. πŸ˜‰

  17. trevor says:

    @jabcreations your versioning system has always made me chuckle.  How can you be at Version 2.9 – if you are still in Alpha?  Your website of course tops this – in a world where no one else versions theirs – you insist on being on version or whatever number you are now on…. yet still output a 1990's UI.

  18. Will Peavy says:

    Will IE9 support web workers? Web worker support would allow for a HUGE performance gain on web apps my team has built.

  19. Neil Dunensach says:

    @Trevor – I think this is jabcreations' best comment:

    "I will run XP until I either find a Linux distro that doesn't annoy me or Microsoft undoes all the GUI destruction from Vista/7"

    So, he wants a Linux distro tailored just for him or MS roll back 5 years worth of interface changes in the next OS – just for him πŸ˜‰

  20. Does anybody @ the IE9 Team know if Technet Subs are getting the Beta of IE9 soon? Thanks in advance

  21. Stifu says:

    Each of jabcreations' posts makes me think he has a serious ego problem. And / or is desperate for attention.

  22. sally says:

    Does IE9 properly support the setAttribute method now?  my tests still indicate that IE9 can't handle switching the "type" attribute round trip from various values on input fields.  It looks like the name attribute has some similar, related issues as well.


  23. EricLaw [MSFT] says:

    @sally: We are not able to reproduce the issue you have reported. Please file a bug on CONNECT with the exact repro steps. Thanks!

  24. bull says:

    @EricLaw – srsly? are you kidding? you can't find the bug with setting the type attribute?

    Test case:

    <input type="text" id="foo" value="test"/>

    play with the value if you like

    in JS…

    //hide it

    document.getElementById('foo').setAttribute('type', 'hidden');

    //show it

    document.getElementById('foo').setAttribute('type', 'text');

    ***Poof!**** what value does the text box now have?

    it is still 4 letters long, only this time it is now: "FAIL"


  25. EricLaw [MSFT] says:

    The code you've provided works just fine in IE9– the text is preserved as "test". Did you put your page in Standards Mode using the document type declaration?

  26. bull says:

    serves me right for not copy pasting from my test case files!!!

    start with a password input…. change the value to anything (user interaction vs. JS interaction), now change the field to a text input… value is lost.

  27. MakeUpUrMind says:

    it sounds like your test case filez are bogus b/c you change your story now… it was "everything is broken" and now you say "the text value is cleared when a password input is changed to a text input."  seems like a bug but no big deal.

  28. Vince says:

    Actually, it might be a conscious decision to clear the password when the input field is converted to text (with security/privacy in mind): as a user I wouldn't trust IE if my password field randomly went from ***** to my password in clear!

  29. GIF says:

    Open this GIF animation in IE9 Platform Preview 4:…/Prince_of_Persia_%281989_video_game%29_IBM_PC_Version_gameplay.gif and zoom it. Notice the ugly visual artifacts. Please fix in the beta.

  30. bull says:

    @MakeUpUrMind – I'm sorry that I don't carry my entire browser test suite with me everywhere I go – I just happened to be bit by the "can't change the type attribute" bug in IE today and remembered that in IE9 is was only partially fixed – and since only the bugs that get constantly discussed have a chance of being fixed – I added my comment about this bug.  Thanks though, you are right I should be drawn and quartered for forgetting it was a password, not a hidden field type, clearly all my test case files compiled over the years must therefore be bogus… after all I've only been doing professional web development since 1996.

    @Vince – Absolutely not! – this is a bug in the type fix's implementation in IE.  At any point in time the value of the field is accessible (view-source), or via JavaScript e.g. elem.value and yes it IS A BIG DEAL because we all want a development platform that works in a standard way – cross browser.  If the method were named


    Then I might accept that it is understood the method has limitations.  However when the method is Element.setAttribute(attName, attValue); There is no implied limitations that 1 browser will only implement this for some attributes, only some of the time, with some undocumented side-effect behavior.

    Lets not forget that in IE6 and IE7 this bug was much worse… we just want it fixed – completely!…/bug-242-setattribute-doesnt-always-work.html

    Back in IE6, IE7 (both unfortunately still widely used today) there were dozens and dozens of attributes you could not set in IE.  It would be a shame to see all this progress be for not.

  31. Andy says:

    Will you also finally update the GUI icons and interfaces from back the Windows 95 days? :/


  32. badger says:

    @GIF   The GIF looks fine to me in IE9 PP4 and see no artifacts when zoomed. Furthermore, I'll point out that it played faster/smoother in IE9 than Chrome which I appreciated!

  33. EricLaw [MSFT] says:

    @GIF: We have a bug tracking the artifact issue, which can be seen, e.g. when the character runs from one place to another, ghosted outlines remain behind.

  34. JamesNt says:


    Stated that there will be "NO CONNECT BUG REPORT WILL BE FILED FOR THIS ISSUE" is just plain not intelligent.  Filing and discussing bugs is what CONNECT is for.

    @Everyone Else

    The greatest mistake MS has made so far was disbanding the original IE team.  And, I think everyone here knows that MS commtted many sins with IE5 and IE6.  However, with the advent IE7 and IE8 I truly feel MS has atoned.  The tremendous job MS has done in bringing true quality and adherence to standards to IE, whilst keeping true to backwards compatibility, has been nothing short of awe inspiring.


  35. ccarrer says:

    Very cool!