Early findings: 97% of mobile end-user response time happens at the front end

Yesterday I was standing around talking with some of my fellow Strangeloopians, and someone brought up a couple of interesting questions:

  1. 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?
  2. 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.

The front end is where 97% of mobile response time happens.

Related posts:

52 thoughts on “Early findings: 97% of mobile end-user response time happens at the front end

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

  2. 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?

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

  4. @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

  5. Pingback: » MeasureMatters #3

  6. Pingback: JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: Modern JavaScript, V8Monkey and SpiderNode, Adapt.js

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

  8. Pingback: 97% of Mobile Web Response Time Is On the Front-End | Golden Key Coaching

  9. Pingback: 97% of Mobile Web Response Time Is On the Front-End | SEO College

  10. Pingback: 97% of Mobile Web Response Time Is On the Front-End | Derivations of Thought

  11. Pingback: 97% of Mobile Web Response Time Is On the Front-End

  12. Pingback: 97% of Mobile Web Response Time Is On the Front-End

  13. Pingback: 97% of Mobile Web Response Time Is On the Front-End | Scripting4U Blog

  14. Pingback: Quick roundup: Mobile performance — Web Performance Today

  15. Pingback: Mobile performance: Don’t panic, but it’s worse than we thought. — Web Performance Today

  16. Pingback: Got iPad 3 fever? Five things to consider when it comes to tablets and mobile web performance

  17. Pingback: Good question: We own a load balancer/ADC. Why not just use it to accelerate our site?

  18. Pingback: Latency reality check: Early findings show that desktop latency ranges from 65-145ms

  19. Pingback: Your 10 favorite posts of 2011

  20. Pingback: Latency. FaceTime on WiFi/LTE. « Andre's Blog

  21. Pingback: Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 1)

  22. Pingback: Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 1) « 13fqcs

  23. Pingback: Improving Web Site Performance on Mobile Devices » LoadStorm

  24. Pingback: 10 Great Web Performance Articles from 2011 » LoadStorm

  25. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | PJExploration

  26. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | WPress4.ME

  27. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design - rehavaPress

  28. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Society of Global Technocrats

  29. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design – James Timothy White

  30. Pingback: 我有我的奥多比 | Improve Mobile Support With Server-Side-Enhanced Responsive Design

  31. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Feeds

  32. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | DigitalMofo

  33. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Photography in Australia

  34. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | FloroGraphics.com

  35. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design

  36. Pingback: Today’s Links | JohnAspinall.co.uk

  37. Pingback: Mymarketing » Improve Mobile Support With Server-Side-Enhanced Responsive Design

  38. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Diancin Designs

  39. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Affordable Website Design - Wordpress Website Development

  40. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Design Front Page

  41. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design - — Ethiopian Website Design

  42. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Wordpress, joomla and other web-development news

  43. Pingback: UX News & Links April 17, 2013 | Erie Design Partners

  44. Pingback: metascope | Improve Mobile Support With Server-Side-Enhanced Responsive Design

  45. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Inspire Web Designs | Web Design Kansas City

  46. Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Tuts – Infos++

  47. Pingback: Improving Web Site Performance on Mobile Devices » LoadStorm LoadStorm

  48. Pingback: 10 Great Web Performance Articles from 2011 » LoadStorm LoadStorm

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>