Measuring Web Page Performance

We’re focused on making Internet Explorer 9 amazingly fast, and we want to help web developers make their sites fast as well. Enabling developers to accurately measure the performance of their websites is critical to making the web faster and enabling a new class of HTML5 applications. At Velocity, we announced Internet Explorer 9 as the first browser to provide performance information to developers at runtime, which we introduced in the latest IE9 platform preview. With special thanks to Steve Souders and Zhiheng Wang from Google, the WebKit team and Mozilla.

Measuring real-world performance of websites is difficult and error prone today. Developers are forced to use hacks, such as injecting low resolution JavaScript timestamps throughout their code, which slows down the pages for end users, introduces an observer effect, and provides inaccurate results which can drive the wrong behavior.

The browser knows exactly how long it takes to load and execute a webpage, so we believe the right solution is for the browser to provide developers an API to access these performance results. Web developers shouldn’t have to think about how to measure performance – it should just be available for them.

It’s important for this API to be interoperable across all browsers and platforms so that developers can consistently rely on these results. The Web Timing specification at the W3C is a good foundation for solving this problem in an interoperable manner. The implementation that you’ll find in the latest IE9 platform preview is based off the navigation section of Web Timings and we’ve started conversations with the W3C and other browser manufacturers about working together to get Web Timing chartered and broadly supported.

Let’s take a closer look at how developers are forced to measure performance today and what the new API’s enable.

How Developers Measure Performance Today

Today, in order to collect performance metrics a web developer has to instrument their code with specific timing markers at strategic places on their web page. This can result in code that opposes performance best practices. Developers write something like this:

        <script type=”text/javascript”>
        var start = (new Date).getTime();
        <script type=”text/javascript”>
        /* do work here */
        var pageLoad = (new Date).getTime() - start; 

This approach has several problems. It forces the JavaScript engine to load earlier than normal. It forces the HTML and JavaScript parsers to switch contexts. It may block parallel requests to load the remaining resources.

Something else to mention is that this JavaScript approach does not capture network latency timings, which is the time associated from when the document is initially requested from the server to the time it arrives and is displayed to the end-user.

Additionally, while the Date function is available across all browsers, the results vary in precision. John Resig has a nice blog post in which he goes to some lengths to determine that the time from (new Date).getTime(); is as precise as 7.5ms on average across browsers, half the interval for the Windows system timer at 15ms. Many operations can execute in under 1ms which means that some measurements can have an error range of 750%!

How Developers can Measure Performance with Internet Explorer 9

The third Internet Explorer 9 platform preview contains a prototype implementation of the Web Timings NavigationTiming interface called window.msPerformance.timing. Following convention, we use a vendor prefix (ms) on the namespace because the spec is under development. There are no other implementations yet, and therefore no interoperability with other browsers. This interface captures key timing information about the load of the root document with sub-millisecond accuracy, which is immediately available from the DOM once the page had loaded.


interface MSPerformanceTiming{
     readonly attribute unsigned longlong navigationStart;
     readonly attribute unsigned longlong fetchStart;
     readonly attribute unsigned longlong unloadStart;
     readonly attribute unsigned longlong unloadEnd;
     readonly attribute unsigned longlong domainLookupStart;
     readonly attribute unsigned longlong domainLookupEnd;
     readonly attribute unsigned longlong connectStart;
     readonly attribute unsigned longlong connectEnd;
     readonly attribute unsigned longlong requestStart;
     readonly attribute unsigned longlong requestEnd;
     readonly attribute unsigned longlong responseStart;
     readonly attribute unsigned longlong responseEnd;
     readonly attribute unsigned longlong domLoading;
     readonly attribute unsigned longlong domInteractive;
     readonly attribute unsigned longlong domContentLoaded;
     readonly attribute unsigned longlong domComplete;
     readonly attribute unsigned longlong loadStart;
     readonly attribute unsigned longlong loadEnd;
     readonly attribute unsigned longlong firstPaint;
     readonly attribute unsigned longlong fullyLoaded;

For the first time, web developers can accurately understand how long it takes to load their page on their customer’s machines. They have access to when the end-user starts navigation (navigationStart), the network latency related to loading the page (responseEnd - fetchStart), and the elapsed time to load the page within the browser.

Developers can use this information to adapt their applications at runtime for maximum performance, and they can use their favorite serialization interface to package these timings and store them on the server to establish performance trends.

With JSON, this would look something like this:


Another useful feature of window.msPerformance is the ability to only query for the elapsed time taken in important time phases of loading the document called timingMeasures.


interface MSPerformanceTimingMeasures{
     readonly attribute unsigned longlong navigation;
     readonly attribute unsigned longlong fetch;
     readonly attribute unsigned longlong unload;
     readonly attribute unsigned longlong domainLookup;
     readonly attribute unsigned longlong connect;
     readonly attribute unsigned longlong request;
     readonly attribute unsigned longlong response;
     readonly attribute unsigned longlong domLoading;
     readonly attribute unsigned longlong domInteractive;
     readonly attribute unsigned longlong domContentLoaded;
     readonly attribute unsigned longlong domComplete;
     readonly attribute unsigned longlong load;
     readonly attribute unsigned longlong firstPaint;
     readonly attribute unsigned longlong fullyLoaded;

Simply access window.msPerformance.timingMeasures.navigation after the page has been loaded and you have the time taken to perform the navigation to the loaded document.

Finally, the window.msPerformance.navigation interface contains information such as the type of navigation and additional network activity that occurred on the page to help describe the overall navigation experience.


interface MSPerformanceNavigation{
     const unsigned short NAVIGATION = 0;
     const unsigned short RELOAD_BACK_FORWARD = 1;

     readonly attribute unsigned longlong type;
     readonly attribute unsigned longlong redirectedCount;
     readonly attribute unsigned longlong uniqueDomains;
     readonly attribute unsigned longlong requestCount;
     readonly attribute unsigned longlong startTime;

Let’s look at it in action

On the IE9 Test Drive site, you can try the window.msPerformance Test Drive demo. There you see a visualization of the time to load the demo page as shown below.


In this example, the overall navigation took 111ms to go from when the link is clicked to the time the contents are loaded within the platform preview.

Check it out!

Everything described here is available now in the third platform preview. Check it out at and try out the window.msPerformance Test Drive demo. This interface is a prototype of a working draft. The API may change, but we want to release this early so that developers can begin to use the API and provide feedback. Please give window.msPerformance interface a try and let us know what you think by providing feedback through the Connect.

Anderson Quach
Program Manager

Edit 6/29 - correction in sentence describing demo page load time.  Overall navigation took 111ms, not 72ms. 

Comments (34)
  1. Karellen says:

    If you're interested in setting good examples for other developers, that timing code should really be

     (new Date()).getTime()

  2. Esben says:

    Very nice! This is something we the devlopers have needed for a loooong time! I'm really looking forward to IE9. Can you say something about when you think IE9 will be ready? 🙂

  3. hAl says:

    What does the firstPaint process stand for?

  4. adambrunner says:

    hAI: Maybe when the render starts.

    IETeam: This is a very usefull feature! Are you planing to standardize this in BOM? Hope other browsers will implement this feature as well with same(!) interface.

  5. Daniel says:

    It is a great idea. How about a memory and processor profiler too?

  6. Timothy J. Warren says:

    Performance is good, but despite what IE touts, it's HTML5 support in the previews is still rather pathetic in comparison to Webkit or Gecko.

    Last I checked, the Firefox nightly got 199/300, and Webkit got 220/300. IE is still not to 100, last I checked.

  7. Brian LePore says:

    Maybe my morning coffee hasn't kicked in yet, but where does that 72ms come from? Shouldn't it be 111ms?

    This system is absolutely fantastic. I don't expect it to come from Microsoft, but I would absolutely love to see someone explain what all of the timings mean and provide recommendations on how to improve times for various configurations (classic LAMP stack, IIS, etc.)

    Additionally, none of my comments seem to be showing up in Firefox. Do they need to be approved? Can the system at least acknowledge that somehting was sent and that it needs that or something? I keep thinking the system failed. What is up with that?

  8. hAl says:

    @Timothy J Warren

    html5test page has several issues. For instance it portraits WebGL as part of HTML5 which is it isn't. It isn'tr even a W3C spec but a private initiative.

  9. Jean-Philippe Martin says:


    Can this be submitted as a standard that other browser would support? I would be great to compare timings from browser to browser. I wonder what Steve Souders would have to say…

  10. EricLaw [MSFT] says:

    @Jean-Philippe– As mentioned in the post itself, the Web Timing spec is in the W3C. And as he said at Velocity, Steve is very happy to see this in IE9.

  11. Richard says:

    These measurements are an excellent development.

    Now, I'm not sure where to log this (does this belong in IE bugs?) but if I log out of MSDN, I get a message telling me that to finish signing out, I must "try clearing all of your browser cookies, and then close all browser windows"!  Now that is absolutely ludicrous: why I should I have to lose all my cookies and close all my browser windows, just to log out of MSDN?  Similarly, if I log out of my bank, I get a message telling me to close all my browser windows (which, obviously, is a hugely inconvenient thing for me to have to do – especially if this era of multi-tabbed windows).

    Shouldn't IE have a feature that allows you to close the session(s) belonging to a particular website without having to close all browser windows (and definitely without having to clear all sites' cookies)?

  12. Mario Cossi says:

    With all the speed improvements in IE9 and other competing browsers, the performance range is going to vary wildly depending on the browser, the OS and/or the device. If we are to abide to your commendable "same markup" drive, and renounce any sort of browser detection, it's hard to risk exploiting all the capabilities of IE9 if this might expose some of our users to a bad experience (like some 1FPS animation we get from some examples on the test drive page).

    It would be useful to have some kind of performance index (à la Windows) so we can either tone down animations and effects to a usable level or, as a last resort, warn the user that the page might be unusable on their browser/platform/hardware. Is there any work or standard being made on that front? If not, what approach would you recommend?

  13. Wurst says:

    @MarioCossi: Don't forget that performance might suddenly decline because of background tasks or energy-saving throttling. The best way to go is to build scalable applications.

  14. EricLaw [MSFT] says:

    @Brian LePore: Yes, that was an editing mistake based on an earlier version of this post. The proper value is 111ms not 72ms.

  15. Wim Leers says:

    Excellent work! And great to see Internet Explorer take the lead in a specific area instead of lagging behind! 🙂

    This will result in more accurate <a href="…/a> measurements and also more <em>extensive</em> measurements.

    Now, what is still needed, is the ability to take the measurements collected by Episodes (i.e. through the Web Timing API) and visualize the measurements, and to automatically draw conclusions from it: to automatically pinpoint the causes of slow page loads.

    That's exactly what the goal is of <a href="…/master-thesis-proposal-web-performance-optimization-analytics">my master thesis: 'Web Performance Optimization: Analytics'</a>.

    Those who are interested, feel free to <a href="">contact me</a>!

    And thanks again for this tremendous step forward, IE team! 🙂

  16. Wim Leers says:

    Ok, so apparently this blog doesn't work very well. No instructions on commenting imply that simple HTML is allowed most of the time. But not here. Here's my comment again:

    Excellent work! And great to see Internet Explorer take the lead in a specific area instead of lagging behind! 🙂

    This will result in more accurate Episodes [1] measurements and also more *extensive* measurements.

    Now, what is still needed, is the ability to take the measurements collected by Episodes (i.e. through the Web Timing API) and visualize the measurements, and to automatically draw conclusions from it: to automatically pinpoint the causes of slow page loads.

    That's exactly what the goal is of my master thesis, which is titled "Web Performance Optimization: Analytics" [2].

    Those who are interested, feel free to contact me [3]!

    And thanks again for this tremendous step forward, IE team! 🙂




  17. bcdalai says:

    In IE9 will it remove flash support? And what about VP8 codec? Is IE 9 having a homepage protection or will it alerts on the default homepage change, by different programs/viruses/worms??? One important thing is that the toolbars are creating huge problems for the browser and to the system. There should be security system in installing the toolbars. The security may be like the driver signing and security certificates. Please the remove the setting to "remembering the username and passwords on forms". This setting is harmful to common user. Remembering form data may be useful but it is not safe to remember the password.

    OK, thanks for the new development.

    Hoping better security and a speedy browser (IE9).


  18. EricLaw [MSFT] says:

    @bcdalai: No, IE9 will not remove support for browser add-ons like Flash. IE9 will not ship with a VP8/WebM codec but if one is installed the VIDEO tag can use it. If your computer is compromised by a "virus/worm" then having homepage protection won't help you (if you're running malicious code on your computer, it's not your computer anymore). Non-virus programs which violate your preferences by changing your homepage will typically be blocked by Windows Defender and/or IE's "Bad add-on" blocker. Any user who wants to disable saving of passwords can easily do so using the appropriate checkbox; administrators can do so using Group Policy. For most users, the convenience outweighs the risk.

  19. Johnnyq3 says:


    I was wondering if you guys will link to a VP8/WebM codec once you guys show off IE9 beta.

  20. hAl says:

    The VP8 codec is terribly inefficient and is not a standard.

    Please support the WMV-HD/VC-1 standard codec which is at least as efficient and has the best decoding footprint so that it can be easily played on mobile devices.

    Also I request you support the WMA-Pro 10.x audio codec as it is an highly efficient codec.

    Supporting Microsofts own codecs would respect your customers that invested in your technologie.

    VP8 as released by Google requires 50% more data for the same quality video compared to h.264 main profile and the codec perfoemcnace is even slower. That mean the VP8 is a terrible waste of bandwith and storage. Microsoft should not support putting some inferior and non standardized codec over it's own formats.

  21. Not-A-Democracy says:

    hAl, as much sense as your post may make, Microsoft has explained what they're going to do in the codec space (h264, WebM only if installed), and they're not going to change that plan now. They're only "supporting WebM if installed" in the hope that somebody (aka Google) would be stupid enough to ship that codec and subsequently get sued for billions.

  22. hAl says:


    That still leaves a big question why Microsoft is not supporting the formats tehy devloped and that they are using in a lot of their existing software and for which a lot of their customers would like support in the browser as well a lot more than they would some fairly inferior non standardized codec like VP8.

  23. Aethec says:


    Well, since Windows has built-in codecs for those formats, IE9 will be able to play them…or am I wrong ?

  24. Greg says:

    Please post a memory consumption graph for each of the page events in your test.  Browsers memory consumption affects performance from URL request to viewing the page especially when you have multiple tabs open.

  25. hAl says:


    De IE team has not indicated that would be the case.

  26. Stifu says:

    @hAl: the IE team has been touting "Same Markup" left and right (which, for them, includes code in general: markup, script…), interoperability and so on, and you're proposing that they support codecs that other browsers or OSes won't be able to support? Awesome idea! To get very bad press, that is. Something IE can't afford anymore.

  27. hAl says:


    Many companies already publish their video in WMV/VC-1 (an official standard) and would like to continue doing so.

    They might use them for internal use or for target groups that have no problem with WMV video.

  28. Ali says:

    HTML 5 test (300 Full Test):

    Chrome 6.0.447.0  ->  219 / 300 (+ 10 bonus points)

    Chrome 5.0.375.86.Final  -> 197 / 300 (+ 7 bonus points)

    Safari 5.0  ->  165 / 300

    Opera 10.60  ->  159 / 300 (+ 7 bonus points)

    Firefox 3.6.6  ->  139 / 300 (+ 4 bonus points)

    IE 9 P.3  ->  84 / 300 (+ 1 bonus points)

    IE 8.0  ->  37 / 300

  29. Aethec says:


    That was already discussed before. The "HTML5 Test" is not testing any kind of standard compliance. (e.g. WebGL is not a standard, but included in the test…)

  30. Wurst says:


    To be fair, WebGL is under the heading "Related Specifications".

  31. hAl says:


    Several W3C specifications are related to HTML5 and state so in the introduction of the W3C specifications but WebGL is not one of them

  32. hAl says:

    Geolocation API is only really usefull for mobile browsers on devices with gps capabilities is it not?

    A mobile browser which IE9 is not planned to be.

    But if Windows phone in the future gets based on an IE9 version than geolocation API might be usefull.  

  33. fr says:

    Geolocation is also potentially useful on netbooks/laptops, and GPS capability is only needed if you need a very accurate position.  A lot of the potential uses for geolocation work fine with the less accurate location worked out by services like Google Location Service.

Comments are closed.

Skip to main content