Last week our CEO, Josh Fraser gave a presentation at the San Francisco Web Performance Meetup cleverly titled “Yo ho ho and a few billion pageviews of RUM” – quite relevant for today, International Talk Like a Pirate Day. If you have some spare time, it’s definitely worth watching! (video and slides). In preparation for the talk, Josh and I gathered some intriguing statistics using the terabytes of data Torbit has collected in the last 4 months. Much of that data is listed below on a categorical basis using a sample of 1,000 sites representing 6.7 billion pageviews.
Frontend vs Backend
As a developer, I spend a good deal of time making my backend code efficient. While that certainly does matter, the vast majority of time users spend waiting is due to frontend loading. Steve Souders’ Golden Rule for Performance states that 80-90% of the end-user response time is spent on the frontend. Across Torbit’s data, that number is actually 93%. We measure frontend vs backend timing based on “time to first byte” (TTFB) and on average 7% of load time is spent on the backend compared to a whopping 93% on the frontend.
Have a look over some of our blog posts on performance for tips on how to reduce frontend load time.
The following values are for the onload time across our sample set.
- Median: 2.53s
- Average: 4.97s
- Geometric Mean: 2.19s
- 90th Percentile: 10.38s
- 95th percentile: 16.86s
- 99th percentile: 43.73s
You’ll see with our mobile data, everything is shifted to the right on the histogram. This is caused by a myriad of reasons including slower processors, latency and slower connections with Edge, 3G, etc.
- Median: 3.87s
- Average: 6.23s
- Geometric Mean: 3.12s
- 90th Percentile: 12.07s
- 95th percentile: 18.11s
- 99th percentile: 44.42s
Taking a closer look at latency, the average response transfer time (time from first byte to last byte of the html response) is 0.30s from desktop browsers and 1.30s on mobile browsers, that’s over 4 times slower! The most important thing you can to to improve your performance on mobile is to reduce the number of requests that you make.
There are many factors that impact the performance experienced by end users in varying locations. When it comes to load times on the web, geography matters a lot.
Where’s the US? The US is the 22nd fastest country. Hopefully Google Fiber will help US cable companies to get with the times.
By US State
* scroll to see full list
Or if you prefer a visualization…
As you can see, the southern and rural states are the slowest, not too terribly surprising.
Of cities we have at least 100,000 data points for, below are the fastest and slowest.
|Makati, Philippines||17.96s||Hallwang, Austria||0.63s|
|Caracas, Venezuela||17.87s||Independence, USA||2.09s|
|Sampaloc, Philippines||14.02s||Nærbø, Norway||2.63s|
|Johannesburg, South Africa||13.92s||University Park, USA||2.68s|
|Jakarta, Indonesia||13.53s||Köln, Germany||3.01s|
By US City
|Slowest US Cities||Fastest US Cities|
|Metter, GA||11.96s||Independence, OH||2.09s|
|Decatur, MI||11.63s||University Park, PA||2.68s|
|Ridgeland, MS||9.33s||Ogden, UT||3.02s|
|Apo, AE||9.02s||College Park, MD||3.11s|
|Mulberry, FL||8.81s||Keansburg, NJ||3.17s|
|Blanchard, OK||8.70s||Notre Dame, IN||3.18s|
|Inglewood, CA||8.65s||Stanford, CA||3.18s|
|Brookhaven, PA||8.61s||Stony Brook, NY||3.24s|
|Compton, CA||8.51s||Dracut, MA||3.32s|
|Bell, CA||8.49s||Princeton Junction, NJ||3.41s|
I can’t see a good reason why Independence Ohio would be so quick, but what most of the fastest cities have in common is a major university (Penn State, University of Maryland, Notre Dame, Stanford, etc.)
Safari as the quickest browser might be a little shocking… As Josh mentioned in his talk, it’s hard to tell what specifically leads to the faster speeds – using Safari typically means they’re on a Mac, a pricier (likely higher performance) machine, and can afford higher speed internet.
|Chrome on Android||8.70s|
Read into that as you wish…
Bounce Rate (Desktop)
Load time plays a huge role in bounce rate. Not even 10 years ago most people were used to waiting 10-30 seconds for a page to load on dial-up. These days pages are expected to load right away, or the consumer will lose interest. The graph above is more proof of that fact.
Bounce Rate (Mobile)
Mobile devices suffer the same fate, just shifted to the right some. An interesting thing to note is how high the bounce rate is for pages that load in one second. With a bit of context behind the graph, the reason for that value is that typically the only pages that will load in 1 second are error pages.
Not only are consumers more likely to leave your page due to slow load times, they’re much less likely to be engaged users. I know if I have to wait 6 or 7 seconds for a page to load, I’m not going to stick around that site for long – this graph proves most people have that same mindset. Notice that engagement is doubled by reducing onload time from 6 seconds to 2 seconds.
If your site loads in 7 seconds on average, clearly that means you should add in a few more requests to bump that up to 9 seconds… In all seriousness though, mobile shows the same overall trend of less engagement with higher load times as expected. It has been suggested that the bimodal nature of this graph with the bump at 9 seconds might represent the difference between pages viewed on 3G versus wifi. In other words, perhaps we’re more patient if we know we’re on 3G and 9 seconds feels more reasonable to us.
Hopefully these statistics are of value to you, or at least somewhat entertaining. If you would like to see how your own site fairs, sign up for Torbit Insight where we provide all these statistics and more!