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