Why are Uber’s apps slow to load? It’s due to pre-fetching

Editor’s note: Keynote Systems’ Startup Shootout Index provides some insight into the three-screen challenge — desktop, smartphone, and tablet — now facing anyone with a web presence. We’ll be bringing you a fresh set of data from Keynote every month. Check out previous Startup Shootout results. 

Keynote just did a major refresh of the Startup Shootout to keep up with the latest companies and hottest categories. Some of the new categories are what we call the “Sharing Economy” and “Sharing Knowledge” categories – services that enable you to rent out your spare room to travelers, use your car as an impromptu taxi service, and share your major interests or hobbies with like-minded people.

Given the interest around the Sharing Economy and services like Lyft, Sidecar and Uber, we took a look at how performance is for these “mobile-first” offerings.

We see that all three have comparable and fast page load times for their desktop-optimized sites. But on smartphones things get slow.

The average time to completely load the opening page for these three services on smartphone browsers is 11.9 seconds. Lyft is in the middle with 11.3 seconds. Sidecar comes in at 12.7 seconds and Uber is an undesirable 19.6 seconds.

The performance on tablets is similar: Lyft is slightly faster than the average; Sidecar is slower; Uber is very slow. Uber comes out as the slowest site in the Sharing Economy section for tablets.

So why is Uber so slow?

The Uber site uses responsive design, which means the same payload is delivered to the smartphone as the desktop, but the page adapts to screen size and device capabilities. That is a flexible approach, but it is usually a lot of content to download over a mobile network connection.

On the Uber mobile home page, there are over 50 new HTTP requests and five different domains (each of which can require a DNS lookup for first-time site visitors).

Interestingly what the user actually experiences is not 19.6 seconds but more like nine seconds. It’s due to something called pre-fetching.

Pre-fetching can be an effective method for speeding up the user experience on mobile devices for users who visit more than one page on the site. The idea is that after all content necessary to the home page loads, other content is requested and gets stored in the browser cache while the user is reading the content on the homepage.

In other words, the page is loading content that’s hidden off-stage for future use. So the user perceives that the page is completed around nine seconds, but the page continues loading content behind the scenes for the next 11 seconds.

But for this to work effectively, it’s imperative that the page elements load in priority order so that assets needed for initial page render always load before anything not needed on that page. Then, when the user logs in and goes to the next page, those elements can be pulled from cache instead of being requested over the network.

Uber looks to be pre-fetching content in anticipation of the user taking further actions and interacting with the home page, but some content critical to the home page is not being requested as soon as it should be.

For example, the image that displays the main corporate logo at the very top of the page is the 26th requested, long after the Google Analytics tag and some other third-party calls.

The logo is also being requested after six very large image files used in the main image carousel at the top of the page. Only the first image is immediately visible to the site visitor, but all six images are requested and load in the browser before the Uber logo image.

As a result, the logo is sometimes taking seven to eight seconds or even longer to display.

Another “must” for pre-fetching is proper cache header settings. Improperly set cache headers can result in conditional HTTP requests being made over the slow mobile network instead of having the element pulled directly from cache on the device. Some of the image files that are being pre-fetched into cache do not have their cache headers set correctly, and will need to be requested over the network again anyway.

This is impacting at least six elements on the Uber home page.

One other caution about pre-fetching is that the user potentially ends up consuming more data than they need to (assuming they discontinue their journey through the site). For customers on pay-as-you-go data plans, this means that you are making your site visitors spend more money for more bytes.

We’re surprised to see these mobile-first sites, especially Uber, come in at such slow speeds. But Uber also serves as a cautionary tale when deploying pre-fetching and cache management, especially for smartphone users.

To view the full range of Keynote Indices, please visit here.

Keynote tests the sites in the index hourly and around the clock from four locations over the three largest U.S. wireless networks, simulating visitors using three different devices. Data is collected from multiple locations and then aggregated to provide an overall monthly average in terms of both performance and availability.