Web Page Performance in a Standards Compliant and Interoperable way


At Velocity, we showed Internet Explorer 9 as the first browser to support the W3C Navigation Timing proposal to provide performance information to developers at runtime. This interface is aimed at helping developers measure and understand the performance of their website. Web developers can use this performance information to make their web sites faster. For IE9 Platform Preview 6, we updated the Navigation Timing interface to reflect the latest work of the Web Performance Working Group. Special thanks to Arvind Jain, Steve Souders, Zhiheng Wang, and Tony Gentilcore from Google, Jonas Sicking from Mozilla and Sigbjørn Vik from Opera for their contributions to this work.

With the Web Performance Group members, we’ve been working together to tackle the challenges of providing performance information about page navigations in a way that is standard and interoperable across browsers. Along with providing performance information to help developers tune and optimize their website, we also are conscious of the security implications of providing this information. Together we are working on a design that is valuable to developers and safe for end-users.

Interoperability and making sure the interface works across all browsers and platforms is very important to developers, so they can consistently rely on the results. The W3C Performance Working group is working to evolve the specification from a Working Draft to Recommendation. As progress on the Navigation Timing specification continues, we are updating IE9 to reflect these changes.

New in PPB6

With interoperability in mind, we’ve updated PPB6 to align with the working draft. Thus we removed the interface window.msPerformance.timingMeasures and updated window.msPerformance.timing and window.msPerformance.navigation.

interface MSPerformanceTiming{
     readonly attribute unsigned long long navigationStart;
     readonly attribute unsigned long long unloadEventStart;
     readonly attribute unsigned long long unloadEventEnd;
     readonly attribute unsigned long long redirectStart;
     readonly attribute unsigned long long redirectEnd;
     readonly attribute unsigned long long fetchStart;
     readonly attribute unsigned long long domainLookupStart;
     readonly attribute unsigned long long domainLookupEnd;
     readonly attribute unsigned long long connectStart;
     readonly attribute unsigned long long connectEnd;
     readonly attribute unsigned long long requestStart;
     readonly attribute unsigned long long responseStart;
     readonly attribute unsigned long long responseEnd;
     readonly attribute unsigned long long domLoading;
     readonly attribute unsigned long long domInteractive;
     readonly attribute unsigned long long domContentLoaded;
     readonly attribute unsigned long long domComplete;
     readonly attribute unsigned long long loadEventStart;
     readonly attribute unsigned long long loadEventEnd;
}
interface MSPerformanceNavigation{
     const unsigned short TYPE_NAVIGATE = 0;
     const unsigned short TYPE_RELOAD = 1;
     const unsigned short TYPE_BACK_FORWARD = 2;
     const unsigned short TYPE_RESERVED = 255;

     readonly attribute unsigned long long type;
     readonly attribute unsigned long long redirectCount;
}

Give it a Test Drive!

In Platform Preview 6, you’ll find that the interface aligns closer to the latest Navigation Timing Specification. You can try this out for yourself with the window.msPerformance Test Drive demo.

See Navigation Timings for yourself at: http://ietestdrive.com

As the working group stabilizes Navigation Timing specification, we expect fewer changes to the IE implementation. We encourage you to try this interface and we welcome your feedback. Please give the Navigation Timing interface a test drive.

Anderson Quach

Program Manager

Comments (8)

  1. Larry says:

    This is quite cool indeed! It certainly shows that IE9 is now a capable modern web browser unlike all previous versions of IE.  Congratulations on such speedy, trackable results!

    One thing though.  Are these times subject to delays due to IE Addons? e.g. If I have the "WhackySlow Bar BHO" installed am I going to see these numbers grow wildly without any explanation or ability to debug?

    tx

    Larry

  2. uhm says:

    hmm…. that printscreen remains me of crappy IE9 fonts and reason why i will not use it..

  3. Jason says:

    Keep up the good work 🙂

  4. Stefan van Zanden says:

    Sounds cool, something we need in our completly Ajax based webapplications is a good way to find Memory leaks,

    is finding stuff like that something that will be added in IE9?

    For example I would really want to know if a HTML DOM Element couldn't be cleaned up by the garbage collector

    because there is still an eventhandler attached to it.

  5. Toni says:

    This looks great guys! Glad we don't have to use crazy hacks to get these metrics!

    A couple of questions/enhancements:

    – support SSLStart and End to figure out SSL Handshake time. Currently I am assuming it goes into the Connect.

    – what would be the wait time? So once connection established (ConnectEnd) the request is Sent, and than the client waits for the server. Is it :responseStart – requestStart – the concern here is there is no RequestEnd (usually request is super fast, 1 packet, but there are some cases where it is slow say an ASP.net page with a vert large ViewState?)

    tony

  6. Hawcreek says:

    @ Uhm

    It also lacks a spell checker, which is your case would be a non starter.

  7. raw says:

    The iframe element should follow the css border:none and overflow:hidden to hide the border and scrollbar.

    frameborder and scrolling are no longer allowed in the HTML 5 spec.

  8. Taylor says:

    Speaking of standards — why does IE9 have a NEW property on the window object that returns NULL?

    window.ActiveXObject

    msdn.microsoft.com/…/ff974676%28v=VS.85%29.aspx

    This is the kind of crap that got Microsoft in trouble in the first place… even more awesome is the notes that say if we as developers put stuff there in the past, to stop it…

    Arghhh!!!!!