State of the Union: Mobile Web Performance

3,947 views

Published on

In this kick-off to the 2015 RWD Summit, I dived into latest research into the performance of the world's most popular ecommerce sites to answer the question: In the fight to offer shoppers the richest possible content on mobile devices, are retailers helping or hurting the user experience?

This session looks at metrics such as load time, page size, page composition, and adoption of performance best practices. The goal is to obtain a real-world "shopper's eye view" of the performance of leading sites, and to track how this performance changes over time.

Published in: Mobile, Technology
1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total views
3,947
On SlideShare
0
From Embeds
0
Number of Embeds
675
Actions
Shares
0
Downloads
37
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide
  • Optimize pop-up script
    Ensure cross-browser functionality
    Delay for at least 10 seconds
    A/B test for effectiveness (e.g. conversions/bounce rate)
  • Looking at the year-over-year numbers, it’s interesting to note that growth has been consistent, with a median growth rate of around 28%. If this continues, the average page will be well over 2 MB in size by 2018 — a year that doesn’t seem that far away.
  • images alone (726 KB) account for more payload than the entire web page (682 KB) just two years ago
  • With the advent of retina displays, consumer expectations of image quality have never been greater. Yet with the overwhelming advent of mobile usage, consumers also expect those same images to render quickly on their smartphones and tablets. In order to remain competitive, site owners must somehow miraculously meet consumers’ demand for large, high-resolution product images while at the same time ensuring that those images don’t clog the pipe to the user’s screen.

    Images typically comprise between 50 to 60% of a page’s total weight. In my research, I’ve found that the bulk of images on most sites are not fully optimized for performance. For example, when analyzing the top 100 Alexa-ranked retail sites, I’ve found that 35% of sites fail to compress images, and only 13% of sites got a pageSpeed score of ‘A’ for image compression. Image compression is a basic optimization technique, yet many sites are missing out on it. It’s easy to spot the low-hanging fruit here.
  • Some of the JavaScript increase discussed already can be attributed to the rise in popularity of custom fonts. Today, 45% of pages served to mobile devices use custom fonts — up from 4% three years ago. While custom fonts are great for controlling design and branding elements, they can also incur major performance penalties. Some fonts require massive amounts of CSS code, while others use super-heavy JS. Either way, load times suffer.

    Your best bet? Disable custom fonts for mobile devices. If that’s not an option, then use them only where absolutely necessary, i.e., headers and key typographical elements.
  • Payload from JavaScript has grown by 163% in the past three years — from 97 KB in 2012 to 255 KB today.
  • When it comes to JavaScript requests, payload is just one thing to worry about. Page complexity is arguably an even greater concern. As the graph below demonstrates, in 2012 most pages contained 10 or fewer JS requests. Today, just over half of the pages measured by the Archive contain more than 10 JS requests. Each of these requests increases the complexity of page rendering, as each request must be downloaded and parsed by the browser. While mobile browsers have made huge strides in a few short years, this added complexity places a significant burden on them.

    While not all of these scripts are from third parties, many are — and this presents yet another performance challenge. Every “simple” single line of third-party code you inject into your pages creates a new potential point of failure. You don’t need to reject them, but you do need to plan ahead and monitor your third-party scripts in order to mitigate their risks.
  • Stylesheets are an incredible boon for modern web pages. They solve a myriad of design problems, from browser compatibility to design maintenance and updating. Without stylesheets, we wouldn’t have great things like responsive design, which gives designers the much-needed ability to customize layout to suit multiple screen formats.

    When poorly executed, however, stylesheets can create a host of performance problems. These problems range from stylesheets that take too long to download and parse to improperly placed stylesheets that block the rest of the page from rendering. Stylesheets should be placed in the document HEAD, which allows the page to render progressively.
  • Among the ten fastest pages, the median page contained 50 resource requests and was 556 KB in size. Among the ten slowest pages, the median page contained 141 resource requests and was 3289 KB in size.

    (Note that these numbers are for the page at the moment the onLoad event fires in the browser, AKA “document complete” time, AKA the amount of time it takes for most resources to render in the browser. Doc complete time shouldn’t be confused with fully load time, AKA the amount of time it takes for every resource to render. More on this dictinction later in this post.)

    In other words, the median slow page was almost three times larger than the median fast page in terms of number of resources, and about six times larger in terms of size.

    Looking at the range of page sizes offers a bit more perspective. For the ten fastest pages, the total number of resources lived within a pretty tight range: from 15 to 72 resources. The smallest page was just 251 KB, and the largest was 2003 KB. With the ten slowest pages, we saw a much wider range: from 89 to 373 resources. The smallest page was 2073 KB, and the largest was more than 10 MB.
  • Time to First Byte is the window of time between when the browser asks the server for content and when it starts to get the first bit back. The user’s internet connection is a factor here, but there are other factors that can slow down TTFB, such as the amount of time it takes your servers to think of what content to send, and the distance between your servers and the user. In other words, slow TTFB can be an indicator of a server problem or a CDN (or lack thereof) problem — or both.

    Among the ten fastest site, the median TTFB was 0.254 seconds, compared to 0.344 seconds for the median for the ten slowest sites. This difference — less than 100 milliseconds — might not sounds like much to be concerned about, but bear in mind that TTFB isn’t a one-time metric. It affects every resource on the page, meaning its effects are cumulative.
  • Deferral is a fundamental performance technique. As its name suggests, deferral is the practice of deferring any page resources that are not part of a page’s critical rendering path, so that these non-essential resources load last. (The optimal critical rendering path has been excellently defined by Patrick Sexton as “a webpage that has only the absolutely necessary events occur to render the things required for just the initial view of that webpage”.)

    Faster pages seem to have a better handle on deferral, which we can infer from looking at the difference between their page size metrics at doc complete versus fully loaded. As already mentioned, among the ten fastest pages, the median page contained 50 resources and was 556 KB in size at doc complete. But when fully loaded, the median page doubled in size to 1116 KB, and contained almost 50% more resources.

    Compare this to the ten slowest pages. The median page grew by about 30%, from 3289 KB to 4156 KB, and from 141 resources to 186 resources. And in several cases, the difference between the doc complete and fully loaded metrics was either unchanged or only negligibly different, indicating that these site owners have not put any effort into optimizing the critical rendering path.
  • Walmart found that, for every 1 second of performance improvement, they experienced up to a 2% conversion increase. Even more dramatically, at the recent Velocity NY conference, Staples shared that shaving just 1 second off their median load time yielded a 10% conversion increase.
  • State of the Union: Mobile Web Performance

    1. 1. © 2014 SOASTA. All rights reserved. March 10, 2015 1CONFIDENTIAL – Not for Distribution State of the Union: Mobile Web Performance 2015 RWD Summit @tameverts
    2. 2. © 2014 SOASTA. All rights reserved. March 10, 2015 2CONFIDENTIAL – Not for Distribution
    3. 3. © 2014 SOASTA. All rights reserved. March 10, 2015 3CONFIDENTIAL – Not for Distribution eMarketer, June 2014
    4. 4. © 2014 SOASTA. All rights reserved. March 10, 2015 4CONFIDENTIAL – Not for Distribution BI Intelligence, August 2014
    5. 5. © 2014 SOASTA. All rights reserved. March 10, 2015 5CONFIDENTIAL – Not for Distribution comScore, 2013
    6. 6. © 2014 SOASTA. All rights reserved. March 10, 2015 6CONFIDENTIAL – Not for Distribution Shopify, August 2014
    7. 7. © 2014 SOASTA. All rights reserved. March 10, 2015 7CONFIDENTIAL – Not for Distribution
    8. 8. © 2014 SOASTA. All rights reserved. March 10, 2015 8CONFIDENTIAL – Not for Distribution
    9. 9. © 2014 SOASTA. All rights reserved. March 10, 2015 9CONFIDENTIAL – Not for Distribution Google I/O, 2013
    10. 10. © 2014 SOASTA. All rights reserved. March 10, 2015 10CONFIDENTIAL – Not for Distribution Google, SeeWhy
    11. 11. © 2014 SOASTA. All rights reserved. March 10, 2015 11CONFIDENTIAL – Not for Distribution
    12. 12. © 2014 SOASTA. All rights reserved. March 10, 2015 12CONFIDENTIAL – Not for Distribution Keynote, 2012 Mobile User Survey
    13. 13. © 2014 SOASTA. All rights reserved. March 10, 2015 13CONFIDENTIAL – Not for Distribution Akamai, 2009
    14. 14. © 2014 SOASTA. All rights reserved. March 10, 2015 14CONFIDENTIAL – Not for Distribution Jakob Nielsen, Response Times: The 3 Important Limits
    15. 15. © 2014 SOASTA. All rights reserved. March 10, 2015 15CONFIDENTIAL – Not for Distribution Optimal load time 8-second delay Jakob Nielsen, Website Response Times
    16. 16. © 2014 SOASTA. All rights reserved. March 10, 2015 16CONFIDENTIAL – Not for Distribution
    17. 17. © 2014 SOASTA. All rights reserved. March 10, 2015 17CONFIDENTIAL – Not for Distribution Radware, 2014 State of the Union: Mobile Ecommerce Performance
    18. 18. © 2014 SOASTA. All rights reserved. March 10, 2015 18CONFIDENTIAL – Not for Distribution Radware, 2014
    19. 19. © 2014 SOASTA. All rights reserved. March 10, 2015 19CONFIDENTIAL – Not for Distribution OpenSignal, August 2014
    20. 20. © 2014 SOASTA. All rights reserved. March 10, 2015 20CONFIDENTIAL – Not for Distribution
    21. 21. © 2014 SOASTA. All rights reserved. March 10, 2015 21CONFIDENTIAL – Not for Distribution Pages that are blank for several seconds, then populate all at once
    22. 22. © 2014 SOASTA. All rights reserved. March 10, 2015 22CONFIDENTIAL – Not for Distribution Pages that load nav elements first and primary content last
    23. 23. © 2014 SOASTA. All rights reserved. March 10, 2015 23CONFIDENTIAL – Not for Distribution Pop-ups that block the rest of the page from rendering
    24. 24. © 2014 SOASTA. All rights reserved. March 10, 2015 24CONFIDENTIAL – Not for Distribution
    25. 25. © 2014 SOASTA. All rights reserved. March 10, 2015 25CONFIDENTIAL – Not for Distribution Mobile HTTP Archive (February 15, 2015)
    26. 26. © 2014 SOASTA. All rights reserved. March 10, 2015 26CONFIDENTIAL – Not for Distribution
    27. 27. © 2014 SOASTA. All rights reserved. March 10, 2015 27CONFIDENTIAL – Not for Distribution
    28. 28. © 2014 SOASTA. All rights reserved. March 10, 2015 28CONFIDENTIAL – Not for Distribution
    29. 29. © 2014 SOASTA. All rights reserved. March 10, 2015 29CONFIDENTIAL – Not for Distribution
    30. 30. © 2014 SOASTA. All rights reserved. March 10, 2015 30CONFIDENTIAL – Not for Distribution
    31. 31. © 2014 SOASTA. All rights reserved. March 10, 2015 31CONFIDENTIAL – Not for Distribution
    32. 32. © 2014 SOASTA. All rights reserved. March 10, 2015 32CONFIDENTIAL – Not for Distribution
    33. 33. © 2014 SOASTA. All rights reserved. March 10, 2015 33CONFIDENTIAL – Not for Distribution
    34. 34. © 2014 SOASTA. All rights reserved. March 10, 2015 34CONFIDENTIAL – Not for Distribution
    35. 35. © 2014 SOASTA. All rights reserved. March 10, 2015 35CONFIDENTIAL – Not for Distribution
    36. 36. © 2014 SOASTA. All rights reserved. March 10, 2015 36CONFIDENTIAL – Not for Distribution
    37. 37. © 2014 SOASTA. All rights reserved. March 10, 2015 37CONFIDENTIAL – Not for Distribution
    38. 38. © 2014 SOASTA. All rights reserved. March 10, 2015 38CONFIDENTIAL – Not for Distribution
    39. 39. © 2014 SOASTA. All rights reserved. March 10, 2015 39CONFIDENTIAL – Not for Distribution
    40. 40. © 2014 SOASTA. All rights reserved. March 10, 2015 40CONFIDENTIAL – Not for Distribution
    41. 41. © 2014 SOASTA. All rights reserved. March 10, 2015 41CONFIDENTIAL – Not for Distribution
    42. 42. © 2014 SOASTA. All rights reserved. March 10, 2015 42CONFIDENTIAL – Not for Distribution
    43. 43. © 2014 SOASTA. All rights reserved. March 10, 2015 43CONFIDENTIAL – Not for Distribution
    44. 44. © 2014 SOASTA. All rights reserved. March 10, 2015 44CONFIDENTIAL – Not for Distribution “The optimal critical rendering path is a web page that has only the absolutely necessary events occur to render the things required for just the initial view of that web page.” Patrick Sexton
    45. 45. © 2014 SOASTA. All rights reserved. March 10, 2015 45CONFIDENTIAL – Not for Distribution Real User Monitoring at Walmart How to Measure Revenue in Milliseconds
    46. 46. © 2014 SOASTA. All rights reserved. March 10, 2015 46CONFIDENTIAL – Not for Distribution

    ×