HTML5 Navigation Timing

Ryan Hurley posted August 24, 2015

There are a lot of client side libraries and frameworks that are used on a modern website. On the TripAdvisor mobile website, we primarily use Zepto and Backbone but there are pages that use React as well. Though these tools can make a developer’s life easier, they can also have a detrimental affect on client side performance.

With the addition of navigation timing to the HTML5 specification, there is now an easy way to investigate how a user’s phone actually loads a website.

5 Minute Tour of Navigation Timing

Navigation timing is a Javascript API that measures client performance. To access page load performance, type in the following JS code into the Chrome console:


If all goes well, you should see output similar to the image below:

Screen Shot 2015-06-11 at 9.35.24 AM

In the PerformanceTiming object, you will see many different properties. Each property is an event that is recorded as a page is loaded. Together they form a timeline from when the user’s browser starts navigating until all the content has been processed by the browser. The WC3 spec ( has a lovely picture showing how all the events follow each other.


The timeline is exhaustive and has a lot of information. At TripAdvisor, we focus on 5 key metrics (Note that these metrics happen sequentially):

  1. Latency (responseStart – fetchStart)
    How long it takes the response to get to the user’s phone. This includes the time it takes for the request to get to the server, the time it takes the server to render a response, and the time until the first byte of that response gets back to the user’s phone.
  2. Transfer (responseEnd – responseStart)
    How long it takes the browser to download the response from the server.
  3. DOM Processing to Interactive (domInteractive – domLoading)
    How long the browser spends loading the webpage until the user can starting interacting with it.
  4. DOM Interactive to Complete (domComplete – domInteractive)
    How long it takes for the browser to load images/videos and execute any Javascript code listening for the DOMContentLoaded event.
  5. Onload (loadEventEnd – loadEventStart)
    How long it takes the browser to execute Javascript code waiting for the window.load event.

How You Capture the Data

As hinted above, you access navigation timing data through Javascript. The last event in navigation timing event is LoadEventEnd, so you have to wait for the window.onload event to fire before calling any Javascript. Using javascript, you could use the following code to print the timing data to the console window of your browser:

window.onload = function() {
  // Check for browser support
  if(!(window.performance && window.performance.timing)) {

At TripAdvisor, we ping the data back to our servers for a small percentage of our traffic. We then have offline processes that go through our logs, validate the data, and then insert the results into a database. From there, we can either run queries directly against the DB or point a dashboarding tool to the database like Looker (

Interpreting the Data

The graph below, is our mobile page performance averaged across all TripAdvisor domains for the week of August 7th. I use stacked bar graphs since the events I described happen sequentially. Putting them together gives us a general sense of total page load time.

navigation timing all points of sale averaged

On average, our mobile site takes 4.6 seconds to load. Even though our latency is high, we spend most of the request processing HTML and downloading resources. This graph is nice to see the general health of the site, but is also important to see how different domains perform.

navigation timing per point of sale

Some domains take a very long time to load on average (over 8 seconds in India). While some domains are very quick (just under 3.5 seconds in Japan). To better understand the graph, it also helps to know that our data centers are currently located in the United States. It’s then not that surprising that domains in Asia, which tend to have traffic from Asia, have high latency values. For example, the latency for our domain for India on August 7th is double the latency for our domain for the United States.

Latency and transfer are mostly affected by server processing times and network speeds. Assuming your server code is running efficiently, then the best way to speed up latency is to move your servers closer to your users and employ CDNs. Even now, some domains load faster than our US domain and this is primarily due to the stellar cellular infrastructure in the corresponding countries that are able to download our CSS and JS files from CDNs very quickly.

Day to day, web developers should be mostly worried about “DOM Processing to Interactive”, “DOM Interactive to Complete”, and “Onload”. These metrics are the majority of our page load times and are most affected by the processing power of the devices connecting to our site. You can see from the graph that some domains are visited by phones with low processing power and consequently those domains have poor performance metrics. To speed up these metrics you need to pay close attention to the amount of HTML, CSS, and JS you are sending to your users and the amount of JavaScript you are running when the page has loaded. Consider using which will run a series of tests against your site and give you easy suggestions to improve your page performance.

Why Care About Performance?

A faster site makes more money because users are happier. Earlier this summer, we fixed some poorly written Javascript code that sped up the TripAdvisor mobile site by half a second. At the time, this reduced our average page load time from 5.5 seconds to 5 seconds (a 9% win). The effect on our site was a 10% increase of clicks on our meta product. We actually set off our anomaly detection scripts for having too many clicks.

By measuring performance before making the JavaScript change, we were able to quantify the value of performance based infrastructure projects. Speed improvements can help your users and your business goals; caring should be a no brainer.

4.8 Seconds is Pretty Slow

If you carefully looked at the graphs above, you will see that TripAdvisor’s average page load time is around 4.8 seconds. We have exhausted many of the easy wins, so here is a highlight of ideas we may try in the future.

  • Mobile lite: We could use the performance timing data to set a cookie for users with slow connections or phones with poor processing power. When this cookie is set, we could disable inline photos on the site and essentially create a text only version of our mobile site. We could also send less data. Instead of a results page with 50 locations maybe we only send 10.
  • Reduce CSS/JS: TripAdvisor has been around for a while so the mobile site uses large rollups for our CSS and JavaScript code. The intention was to reduce network requests but we didn’t take into account the extra processing the browser has to do to parse CSS and JS that isn’t even needed for the current page. Ideally, we would include only the CSS and JS needed in the HEAD of our pages and async the rest. This is an obvious win but will take a lot of work.
  • New Protocols: We haven’t tapped into the power of web sockets or HTTP2. There could be performance wins there.
  • Save JSON Responses: We use client side templating to render some of our pages. We could use HTML5 browser storage to cache responses locally to speed up browsing. We could even cache the templates themselves.
  • Prefetching: Once we break apart our CSS/JS rollups, we could use a sitemap to preload resources for the pages a user may be visiting next.

Wrap Up

Hopefully this article explains why you should be monitoring the performance of your site and the difference it can make. TripAdvisor still has a long way to go but at least we can measure our progress now.


Browser Support

The following OS/browsers fully support Navigation Timing on mobile:

  • Android 4.0 and above should support Navigation Timing. The Chrome team has done excellent work.
  • IE Mobile 10 and 11 also support Navigation Timing.
  • Firefox since version 7
  • Blackberry devices

iOS 8 and below are evil and claim to support Navigation Timing but commonly return bad values like negative numbers in fields that should only be greater than zero. I recommend that you explicitly exclude iOS devices from any data collection you do. iOS 9 should support Navigation Timing but I have not tested this claim. Note that navigation timing may not be ready for use on Desktop yet depending on your target browsers.