Early findings: 97% of mobile end-user response time happens at the front end
20 Apr 2011
Yesterday I was standing around talking with some of my fellow Strangeloopians, and someone brought up a couple of interesting questions:
- Everyone goes around quoting Steve Souders’s stat that 80% of performance issues happen at the front end, but this quote is almost four years old, dating back to the publication of Steve’s book High Performance Web Sites. Is this number still accurate?
- And what about mobile performance? To the best of our collective knowledge, this area has never been studied.
We’re in the fortunate position of being able to get to the bottom of these questions. We gather and store a lot of data for our customers, so it only took me about five minutes to look at the last five million desktop and mobile transactions (about a week’s worth) in our beacon database. (I stopped at five million because my pivot table in Excel would not handle more and my SQL query skills are non-existent.) These transactions occurred on a dozen or so sites.
Methodology
To do my calculation, I included all the reported pages, both landing and non-landing, which had document complete load times of less than 45 seconds. (We see huge outliers in some of the mobile browsers due to how multitasking works.*)
I conducted each calculation twice for verification. I also performed calculations in which I removed large outliers. In all cases, the results were consistent.
Results: Desktop vs mobile
Here’s the breakdown of where response time was spent, on average, for desktop versus mobile users:
| Back end | Front end | |
| Desktop | 15% | 85% |
| Mobile | 3% | 97% |
This exercise confirms that the proportion of front end to back end time with desktops has remained about the same. What’s more interesting to me is the fact that the front end — shorthand for “everything after the HTML arrives” — was where 97% of mobile response time happens. I expected this number to be higher than the desktop number, but not this high.
I then did a quick analysis based on a few of the mobile browsers:
| Back end | Front end | |
| Android2 | 4% | 96% |
| BB5 | 1% | 99% |
| IEMobile7 | 1% | 99% |
| iPad3 | 10% | 90% |
| iPad4 | 15% | 85% |
| iPhone3 | 2% | 98% |
| iPhone4 | 1% | 99% |
| iPod4 | 5% | 95% |
This raises new questions
This quick analysis raises a number of additional questions for the mobile data set:
- What is the breakdown in the mobile space based on Wifi vs 3/4G networks?
- How does the carrier affect these numbers?
- What is the cache hit rate for the mobile browsers?
- What is the typical latency for the mobile customer?
Lately, we’ve been stepping up our efforts to push key web performance stats out there to a mainstream audience. It’s crucial to keep revisiting these stats with real world data to make sure we’re pushing the right numbers.
Final caveat: I don’t think this exercise is the last word on this subject. We need a more controlled study and significantly more analysis.
*I always chuckle when I see major outliers in the data. Here are a few fun examples. If you’re wondering, 75190442ms equals roughly 21 days.


Apr 20, 2011 @ 13:30:54
Great questions. We’re building the answers in to our service. You’ll be able to compare carriers, wifi (on off), cache (cleared or not) and more
Apr 20, 2011 @ 13:52:51
Just sent you a tweet with a picture in it. Sprint vs AT&T, wifi-on, wifi-off, cache cleared each time. The results are impressive.
Apr 20, 2011 @ 22:36:43
nice post – but I do have a question.
Isn’t it wrong to say that everything after the HTML document is client time? Downloading images, js, css, flash, … is not client time. It is part of the overall Web Site and needs to be downloaded from a server/proxy/cdn/… – Client Time for me is time that the Browser spends to calculate layout, draws content and executes JavaScript.
Would be interesting to see how these timings differ on desktop vs. mobile browsers
thoughts?
Apr 20, 2011 @ 23:44:22
Isn’t iPad 3 and 4 supposed to be listed as 1 and 2?
However, interesting statistics!
Apr 21, 2011 @ 00:00:26
Thanks for sharing your findings. I think the key part we need to clear up next is “how much impact does the type of network have?”. I expect this to be the absolute dominant factor.
The limited hardware resources of mobile devices do maybe also impact the numbers right now but their importance on loading times already seems to fade away as indicated by the iPad devices (which equivalent the type of phones we use tomorrow). Those are already on par with the stats you are reading from desktops.
@Andreas
True. From this viewpoint one should call it network time or something. But I think the right meaning is not about where it happens. Instead it is about where you need to change your architecture to diminish the time. And that is clearly in the front end / on the client side.
Apr 21, 2011 @ 01:34:54
@Schepp: totally right. You need to follow certain best practices to limit the number of roundtrips, optimize content, … – but thats true in general – independant whether the webapp is viewed on the desktop or mobile device. The impact obviously is higher on mobile devices because latency and bandwidth becomes a huge problem when you have lots of content to download.
What would really be interesting for me is the actual “browser time” on mobile devices – and that includes rendering, javascript execution and dom manipulations. Especially Web 2.0 apps – apps that leverage JS/XHR/DOM need to deal with the limitations of a mobile device (speed, js engine, memory, …)
Looking forward to more results
Apr 21, 2011 @ 01:58:41
@Andreas I think we are not far away from getting these data as well as we have the W3C WebTiming Spec underway and already two browser implementing it. See:
http://dev.w3.org/2006/webapi/WebTiming
http://blogs.msdn.com/b/ie/archive/2010/06/28/measuring-web-page-performance.aspx
» MeasureMatters #3
Apr 22, 2011 @ 07:03:10
[...] Early findings: 97% of mobile end-user response time happens at the front end [...]
JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: Modern JavaScript, V8Monkey and SpiderNode, Adapt.js
Apr 22, 2011 @ 17:51:02
[...] Early findings: 97% of mobile end-user response time happens at the front end [...]
Apr 22, 2011 @ 21:49:29
Great stats – I think it gets more and more important with mobile, especially when “smartphone browsers” support better standards.
@Alois, I think front-end / back-end split is the way it is to be able to show that people should distinguish between scalability problems and performance problems.
97% of Mobile Web Response Time Is On the Front-End | Golden Key Coaching
Jun 10, 2011 @ 12:00:46
[...] Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
97% of Mobile Web Response Time Is On the Front-End | SEO College
Jun 10, 2011 @ 12:01:05
[...] Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
97% of Mobile Web Response Time Is On the Front-End | Derivations of Thought
Jun 10, 2011 @ 12:01:29
[...] Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
97% of Mobile Web Response Time Is On the Front-End
Jun 10, 2011 @ 16:09:40
[...] Strangeloop president Joshua Bixby decided to take a look at Steve Souders’ old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
97% of Mobile Web Response Time Is On the Front-End
Jun 10, 2011 @ 16:33:50
[...] Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
97% of Mobile Web Response Time Is On the Front-End | Scripting4U Blog
Jun 11, 2011 @ 15:53:27
[...] 97% of Mobile Web Response Time Is On the Front-End Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here. [...]
Quick roundup: Mobile performance — Web Performance Today
Jun 22, 2011 @ 10:20:00
[...] Early findings: 97% of mobile end-user response time happens at the front end [...]
Mobile performance: Don’t panic, but it’s worse than we thought. — Web Performance Today
Jun 22, 2011 @ 23:07:36
[...] Early findings: 97% of mobile end-user response time happens at the front end [...]
Sep 26, 2011 @ 15:55:38
Folks like NewRelic suggest that the network is a significant contributor (not front-end or back-end).
http://blog.newrelic.com/page/4/
At Cedexis, our worldwide RUM data is suggesting this as well. Would anyone be interested in collaborating on a post to performance community re: the NETWORK?
Got iPad 3 fever? Five things to consider when it comes to tablets and mobile web performance
Mar 07, 2012 @ 00:28:04
[...] discovery: while this number has remained pretty much the same for desktop response time, the front end is where a whopping 97% of mobile response time happens. What this means for tablet owners: When they aren’t struggling with network issues, [...]
Good question: We own a load balancer/ADC. Why not just use it to accelerate our site?
Mar 11, 2012 @ 05:37:02
[...] Early findings: 97% of mobile end-user response time happens at the front end [...]
Latency reality check: Early findings show that desktop latency ranges from 65-145ms
Apr 02, 2012 @ 17:42:39
[...] year, we here at Strangeloop conducted an in-house research project in which we determined that 97% of mobile end-user response time happens at the front end. We did this by digging into our customers’ beacon data and analyzing millions of unique [...]
Your 10 favorite posts of 2011
Apr 25, 2012 @ 16:02:07
[...] 1. Early findings: 97% of mobile end-user response time happens at the front end [...]
Latency. FaceTime on WiFi/LTE. « Andre's Blog
May 16, 2012 @ 11:08:22
[...] 4.80% of response time is front-end related for landline users and 97% for mobile users! We have more latencies in 3G than xDSL/FTTB. http://www.webperformancetoday.com/2011/04/20/desktop-vs-mobile-web-page-load-speed/ [...]
Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 1)
May 29, 2012 @ 11:19:02
[...] response time is spent on the front end. (Related: We re-tested this assumption last year, and it still holds.) Much of this time is spent downloading page objects like images, stylesheets, etc. By reducing [...]
Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 1) « 13fqcs
May 30, 2012 @ 09:12:43
[...] response time is spent on the front end. (Related: We re-tested this assumption last year, and it still holds.) Much of this time is spent downloading page objects like images, stylesheets, etc. By reducing [...]
Improving Web Site Performance on Mobile Devices » LoadStorm
Mar 06, 2013 @ 15:22:44
[...] of performance. But what do you measure, and how? As Web Performance Today recently pointed out, over 90% of performance gains on mobile devices are to be found on the mobile client’s front end, and not on the server side. This suggests [...]
10 Great Web Performance Articles from 2011 » LoadStorm
Mar 13, 2013 @ 08:36:43
[...] can Web site operators improve mobile performance? WPT did some additional leg work, and found that 97% of the performance cost of mobile Web sites resides in the front end. The numbers varied between devices and operating systems, with some performing better than others. [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | PJExploration
Apr 09, 2013 @ 08:00:24
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | WPress4.ME
Apr 10, 2013 @ 00:48:37
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design - rehavaPress
Apr 10, 2013 @ 01:09:42
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Society of Global Technocrats
Apr 10, 2013 @ 01:11:47
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design – James Timothy White
Apr 10, 2013 @ 01:29:44
[...] categorical reason for doing this is performance. Most of a time taken by a page to load is caused by a browser perplexing to make clarity of a information being received. Being delayed [...]
我有我的奥多比 | Improve Mobile Support With Server-Side-Enhanced Responsive Design
Apr 10, 2013 @ 01:32:23
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Feeds
Apr 10, 2013 @ 03:04:45
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | DigitalMofo
Apr 10, 2013 @ 03:05:19
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Photography in Australia
Apr 10, 2013 @ 04:04:53
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | FloroGraphics.com
Apr 10, 2013 @ 06:17:34
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design
Apr 10, 2013 @ 06:33:30
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Today’s Links | JohnAspinall.co.uk
Apr 10, 2013 @ 08:06:09
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Mymarketing » Improve Mobile Support With Server-Side-Enhanced Responsive Design
Apr 10, 2013 @ 08:19:02
[...] fοr responsibility thіѕ іѕ performance. Mοѕt οf thе time taken bу a page tο load іѕ caused bу thе browser trying tο mаkе sense οf thе [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Diancin Designs
Apr 10, 2013 @ 09:47:06
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Affordable Website Design - Wordpress Website Development
Apr 10, 2013 @ 19:43:40
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Design Front Page
Apr 12, 2013 @ 14:06:12
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design - — Ethiopian Website Design
Apr 12, 2013 @ 22:43:22
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Wordpress, joomla and other web-development news
Apr 16, 2013 @ 00:58:58
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
UX News & Links April 17, 2013 | Erie Design Partners
Apr 17, 2013 @ 02:25:37
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
metascope | Improve Mobile Support With Server-Side-Enhanced Responsive Design
Apr 21, 2013 @ 15:52:46
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]
Improve Mobile Support With Server-Side-Enhanced Responsive Design | Inspire Web Designs | Web Design Kansas City
May 06, 2013 @ 06:37:24
[...] main reason for doing this is performance. Most of the time taken by a page to load is caused by the browser trying to make sense of the data being received. Being slow has a cost, [...]