Select a language to translate this page!
Powered by Microsoft® Translator
As web sites become more like applications, measuring and tuning their performance dramatically increases in importance, especially on mobile devices where latency and other performance-related factors have a high impact on user satisfaction. In fact, GigaOM just recently released findings that almost half of users are much less likely to return to a Web site that loads slowly on their handset.
We consider helping developers to measure real-world performance of their mobile sites to be so important that we were on the leading edge of implementing the W3C Navigation Timing interface in Internet Explorer 9, and helped drive it to Candidate Recommendation status very quickly. This interface is available via the window.performance object on IE9 for Windows Phone “Mango” devices, and you can read more about the work we’ve done on this standard here and here. If you don’t have a Mango device, you can download the easy-to-use emulator from the App Hub on MSDN.
The Navigation Timing interface gives Web developers a way of measuring a complete end-to-end picture of user latency – that is, the total amount of time involved in various parts of the process by which a user first requests a Web resource until the time point where it has finished loading in the browser.
Using the Navigation Timing features, you can measure things such as (but not limited to):
The Navigation Timing features are available from the window.performance object (as with any feature, your code should make sure that the given feature actually exists before attempting to use it), which itself just provides objects for timing and navigation. Assuming the feature is supported, you can use the window.performance.timing and window.performance.navigation objects to obtain timing data.
The PerformanceNavigation Interface defines two properties and a few constants:
The type of navigation. Can be TYPE_NAVIGATE (0), TYPE_RELOAD (1), TYPE_BACK_FORWARD (2), or TYPE_UNDEFINED (255).
Indicates the number of redirects the navigation experienced for the page to load in the browser
The type field indicates what kind of navigation was measured. This can be either a normal navigation, a reload event, or a programmatic navigation event via the history object. NOTE: Navigations that result from client-side redirects such as using a <meta> tag with a refresh directive are not counted as redirects – the API reports these as whether they caused a reload or a navigation to a new URL.
The actual timing information for the navigation is available on the timing object, which implements the PerformanceTiming interface. Each of these properties represents a time point during the lifecycle of the navigation event. These time points, listed in order of their occurrence, are:
Time point at which the navigation begins
Time at which the user agent starts unloading the previous document, if there is one, otherwise 0
Time at which the previous document finishes unloading the previous document, otherwise 0
If any redirects are involved, this is the time point at which the first fetch request that initiates the redirect starts, other wise 0
If there were any redirects involved, the time point at which the last byte of the last redirect is received, otherwise 0
For HTTP GET requests, the time at which the user agent starts to check the application cache, otherwise the point at which the resource fetch starts
Time point at which the user agent starts the domain name lookup for the document. If the document is retrieved from the cache, this is the same as fetchStart
Time at which the user agent finishes looking up the domain name. If the document is being retrieved from a cache or locally, same as fetchStart
Time when the user agent starts establishing a connection to the server. If the document is retrieved from the application cache or otherwise locally, this is the same as domainLookupEnd
Time when the user agent finishes establishing a connection to the server. If the document is retrieved from the application cache or otherwise locally, this is the same as domainLookupEnd
Optional attribute – it is undefined for user agents that don’t provide it. If HTTPS is used, this is the time point when the user agent starts the handshake process to secure the connection. If HTTPS is not used, this is 0
The time when the user agent starts requesting the document from the server, or from the application cache or other local resource
Time point immediately following when the user agent receives the first byte of the response from the server, application cache, or local resource
Time point immediately following when the user agent receives the last byte of the response from the server, application cache, or local resource
Time point when the user agent sets the readyState of the current document to “loading”
Time point when the user agent sets the readyState of the current document to “interactive” – this is the first point where the user can interact with the page
Time point right before the user agent fires the DOMContentLoaded event
Time point right after the DOMContentLoaded event completes
Time point right before the user agent sets the readyState to “complete”
Time point right before the user agent fires the onload event
Time point right after the onload event completes
To calculate the amount of time required for a particular navigation sequence, you can simply subtract one value from another. For example, to calculate the total time required to load a page, you can simply subtract navigationStart from loadEventEnd:
var perfData = window.performance.timing; var pageLoadTime = perfData.loadEventEnd – perfData.navigationStart;
Or, if you wanted to see how long the request-response process took, you could simply use:
var connectTime = perfData.responseEnd – perfData.requestStart;
Each of the timing events fires at a defined point in the page navigation process, illustrated by the following figure:
Having this data available inside your page can provide several real-world benefits. Site developers, for example, can implement a URL parameter switch that turns on performance testing for the page, allowing testers to gather data from live production pages. Or, a site might choose to implement an “opt-in” feature for live users to provide this performance feedback via XHR so that the site can measure how well pages are being navigated to in the wild.
Microsoft is committed to working with the W3C to create an interoperable way of measuring the performance of Web sites, of which the Navigation Timing API is just a start. Let us know how you’re using the API and what kinds of insights it has helped you find!
Joe Marini (@joemarini) Principal Program Manager, Internet Explorer Windows Phone
@nomis - No, the web timings API can't give you that. You might check out boomerang (github.com/.../boomerang) which allows you to fire events around your ajax calls to measure performance.
How about ajax calls. Can I measure them with this to? If so, how would I do this exactly?
We are currently developing a mobile website with jq mobile and apart from the first page, everything is loaded via ajax.
Also I'm really happy with the viewport rendering in mango aka IE9, had some serious issues with IE7 control.