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:
<html>
<head>
<script type=”text/javascript”>
var start = (new Date).getTime();
</script>
</head>
<body>
<script type=”text/javascript”>
/* do work here */
var pageLoad = (new Date).getTime() - start;
</script>
</body>
</html>
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.
window.msPerformance.timing
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:
JSON.Stringify(window.msPerformance);
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.
window.msPerformance.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.
window.msPerformance.navigation
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 https://ietestdrive.com 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
Anonymous
June 28, 2010
If you're interested in setting good examples for other developers, that timing code should really be (new Date()).getTime()Anonymous
June 28, 2010
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? :-)Anonymous
June 28, 2010
What does the firstPaint process stand for?Anonymous
June 28, 2010
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.Anonymous
June 28, 2010
It is a great idea. How about a memory and processor profiler too?Anonymous
June 28, 2010
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. http://html5test.com Last I checked, the Firefox nightly got 199/300, and Webkit got 220/300. IE is still not to 100, last I checked.Anonymous
June 28, 2010
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?Anonymous
June 28, 2010
@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.Anonymous
June 28, 2010
Great! 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...Anonymous
June 28, 2010
@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.Anonymous
June 29, 2010
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)?Anonymous
June 29, 2010
The comment has been removedAnonymous
June 29, 2010
@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.Anonymous
June 29, 2010
@Brian LePore: Yes, that was an editing mistake based on an earlier version of this post. The proper value is 111ms not 72ms.Anonymous
June 29, 2010
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="stevesouders.com/.../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="wimleers.com/.../master-thesis-proposal-web-performance-optimization-analytics">my master thesis: 'Web Performance Optimization: Analytics'</a>. Those who are interested, feel free to <a href="wimleers.com/contact">contact me</a>! And thanks again for this tremendous step forward, IE team! :)Anonymous
June 29, 2010
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! :) [1] stevesouders.com/episodes [2] wimleers.com/.../master-thesis-proposal-web-performance-optimization-analytics [3] http://wimleers.com/contactAnonymous
June 29, 2010
The comment has been removedAnonymous
June 29, 2010
The comment has been removedAnonymous
June 29, 2010
EricLaw[MSFT] I was wondering if you guys will link to a VP8/WebM codec once you guys show off IE9 beta.Anonymous
June 30, 2010
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.Anonymous
June 30, 2010
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.Anonymous
June 30, 2010
@Not-A-Democracy 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.Anonymous
June 30, 2010
@hAl Well, since Windows has built-in codecs for those formats, IE9 will be able to play them...or am I wrong ?Anonymous
June 30, 2010
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.Anonymous
June 30, 2010
@Aethec De IE team has not indicated that would be the case.Anonymous
June 30, 2010
@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.Anonymous
June 30, 2010
@Stifu 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.Anonymous
July 01, 2010
HTML 5 test (300 Full Test): http://html5test.com 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 / 300Anonymous
July 01, 2010
@Ali 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...)Anonymous
July 01, 2010
@Aethec: To be fair, WebGL is under the heading "Related Specifications".Anonymous
July 01, 2010
@Wurst Several W3C specifications are related to HTML5 and state so in the introduction of the W3C specifications but WebGL is not one of themAnonymous
July 02, 2010
Please, Form validator: www.w3.org/.../common-input-element-attributes.html Input element type: www.w3.org/.../the-input-element.html Section elements: www.w3.org/.../semantics.html Geolocation: dev.w3.org/.../spec-source.html Web SQL Database: www.w3.org/.../webdatabaseAnonymous
July 02, 2010
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.Anonymous
July 04, 2010
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.