Some Interesting Performance Statistics

by Austin Hallock on September 19, 2012

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.

Overall Stats

The following values are for the onload time across our sample set.

Desktop

  • Median: 2.53s
  • Average: 4.97s
  • Geometric Mean: 2.19s
  • 90th Percentile: 10.38s
  • 95th percentile: 16.86s
  • 99th percentile: 43.73s

Mobile

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.

Location

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.

By Country

Fastest Slowest
Slovenia 3.41s Tonga 31.49s
Sweden 4.02s Cuba 30.59s
Denmark 4.27s Vanuatu 28.65s
Canada 4.27s Niger 27.05s
Switzerland 4.32s Burkina Faso 26.83s
Netherlands 4.34s Burma 24.87s
Belgium 4.39s Liberia 23.78s
Norway 4.45s Sierra Leone 23.30s
Aaland Islands 4.48s Gambia 22.13s
Iceland 4.58s Micronesia 22.12s



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

Massachusetts 3.39s
Rhode Island 3.8s
Oregon 4.04s
Delaware 4.1s
Virginia 4.1s
Washington 4.11s
Connecticut 4.17s
Minnesota 4.18s
New Hampshire 4.19s
New Jersey 4.22s
Arizona 4.23s
Nebraska 4.25s
New York 4.26s
Vermont 4.3s
California 4.36s
Maryland 4.36s
Colorado 4.37s
Utah 4.39s
Wisconsin 4.41s
North Dakota 4.47s
South Dakota 4.5s
Pennsylvania 4.52s
Oklahoma 4.53s
Kansas 4.55s
Michigan 4.55s
Iowa 4.6s
Illinois 4.61s
Ohio 4.61s
Nevada 4.62s
Texas 4.66s
Indiana 4.74s
Missouri 4.75s
Florida 4.79s
Tennessee 4.82s
North Carolina 4.84s
South Carolina 4.86s
Georgia 4.89s
Louisiana 4.92s
New Mexico 4.92s
Maine 4.99s
Alabama 5.04s
Hawaii 5.04s
Montana 5.07s
Wyoming 5.18s
Kentucky 5.19s
Arkansas 5.22s
Idaho 5.23s
West Virginia 5.56s
Alaska 5.75s
Mississippi 5.88s

* 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.

By City

Of cities we have at least 100,000 data points for, below are the fastest and slowest.

Slowest Fastest
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.)

Browser Comparison

Desktop

Safari 4.47s
Firefox 4.79s
Chrome 5.53s
IE8 6.10s
Opera 6.44s
IE9 6.89s
IE7 7.39s
IE6 9.63s



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.

Mobile

Opera Mini 4.68s
Chrome iOS 5.82s
Safari iOS 6.60s
Android Browser 7.16s
Chrome on Android 8.70s

Read into that as you wish…

Business Metrics

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.

Engagement (Desktop)

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.

Engagement (Mobile)

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!


Leave a Reply