We all know that web page speeds can make a huge difference to an e-commerce website’s conversion rate and stickiness. This case study by SOASTA claimed that improving mobile page load speed increased the conversion rate by over 25%. In his constant drive to put the user first, Jeff Bezos, Amazon’s founder and CEO, is famously obsessed with page load speed and is constantly driving his employees to reduce the page speed of the Amazon website. The rise of mobile dominance has amplified the need for faster page load speed as users will often browse websites on slower connections.
There are plenty of tools out there to help you improve the speed of web pages such as Yslow or Google Pagespeed Insights, and there are various best-practices such as css and js minification and merging, use of css sprites and minimizing network requests that a front end developer should follow to ensure that page speed is maximized.
The problem that we have is that once you follow the standard best practices and realize the big wins, you will soon start to see diminishing returns on efforts to improve overall page speed. You can spend a great deal of time making smaller and smaller incremental improvements and this will be a costly and time-consuming process. Front end developers with the necessary skills and experience to work at this level are surprisingly scarce and expensive. There are some things that you cannot control such as network latency or mobile connection speeds, and so there is a limit to what can be achieved with raw page speed. On a 3G connection anywhere between 600ms and 1s is consumed by mandatory network overheads, which you can do nothing about. Based on a desired page load time of 2s, this gives us just 1s to play with. That’s not very much.
There is no denying that raw page speed is very important and all developers should follow the standard best practices as a minimum. This article, however, is not going to discuss how to make your page load faster. There are plenty of articles out there about that and it’s all a bit techie. This article is going to focus on the perception of page speed. What is the more important? How fast the page loads or how fast the user perceives it to load? Surely the perception is what counts most to the user.
Let’s focus on the home page of your website. It is likely to contain a top navigation, search bar, hero banner, maybe links to key categories a carousel and some content. Home pages tend to be quite content heavy and loading all of this content quickly on a mobile connection is going to be a big challenge.
The key here is to prioritize the loading of critical content first, ahead of other content. Give the user something important to see as quickly as you can. While they are processing this critical information, you can then start to load the next tier of content.
Let’s look a site that does this very well. Amazon have split up the delivery of assets and content to ensure that the user is provided with critical content as soon as possible and they then progressively load assets in the order of priority.
This test was run on an iPhone 6 simulator on a good 3G connection and caching disabled. After the page was initially loaded I initiated a hard refresh.
In just over 600ms I have something beginning to load with my name in the header. You will also notice that only 6 network calls have been made and 5 assets loaded (3 css files and 2 images).
Just 50ms later I now see key components of the header as well as the lead hero banner. I already have the perception of speed as key content is being delivered to me very quickly and there is something for my eyes and brain to process while additional content is being loaded.
After just 1 second the main navigation is loaded. You will notice that there is no scroll bar visible at this stage. This means that there is currently no content below the fold. Precious time has not been wasted in loading this content that the user cannot see. You will also notice that only 13 requests have been made so far.
In just under 2 seconds, I now have a new section of important content.
In less than 3 seconds I now perceive the page to have entirely loaded whereas the page actually took just under 5 seconds to load in its entirety. This suggests that I perceive the site to be completely loaded when it is in fact only 60% loaded.
The actual timing of content delivery will vary from person to person but this illustrates very clearly how Amazon is prioritizing the loading of mobile content to ensure that critical content is loaded as quickly as possible and that users perceive the site as beginning to load very quickly.
Now let’s look at a website that doesn’t do this so well. This test was run using the exact same tools and network speed as the previous Amazon test. While the Charles Tyrwhitt site does prioritize some content, there is a great deal more that could be done to get close to the optimization of Amazon.
I don’t see any content for almost 7.5 seconds. Immediately I have a perception that this site is slow on my mobile device. Although the site prioritizes the header content as well as a hero banner, you can see that over 90 requests have been made by this point and, as I can see the scroll bar, it is clear that content must have been loaded below the fold.
After 8.5 seconds I can see that a carousel is starting to load. The number of requests has not changed which suggests that the bulk of the content-related requests are made right at the beginning on page load.
It is not until almost 22 seconds that I perceive that the site has now fully loaded. The page actually took a total of 28.4 seconds to completely load. This suggests that I perceive that the page was completely loaded when it was in fact 77% loaded.
It easy to see the clear difference between the 2 experiences. Whilst the Amazon mobile home page loads significantly faster than the Charles Tyrwhitt home page, effort has been made to ensure that users perceive that it is even faster. The user starts to see something loading within 12.5% of the total page load time whereas users of the Charles Tyrwhitt website only see something happening within 26% of the total page load time. The Amazon home page has made 6 network requests before the user sees progress whereas the Charles Tyrwhitt home page has made 90 requests.
This is not meant to be overly critical of Charles Tyrwhitt as they are, by no means, unique in the way that they have built their website. The accepted best practice has been followed in a number of areas but it appears that a great deal more could be done to improve the perception of speed as well as the actual speed.
It is fairly common for front end developers to place the majority of a website’s css in a handful of files and to always use external, rather than inline, css. The problem this causes is that a large css file needs to be loaded before any content can be shown to a user. A solution to this is to split your css files and load them in sequence with the critical content. If we look at the example of Amazon, they load a css file that is just 6.5k in size as one of their initial 6 requests. This file contains the css that is required to style the critical content on their home page. In fact, the total size of all css files that are requested before the user sees content on the Amazon mobile home page is under 40k whereas it is over 500k on the Charles Tyrwhitt home page.
This practice allows you to deliver critical content to user very quickly and helps to enforce the perception of speed.
There is a lot that web developers can learn from the way that website such as Amazon focus on the perception of the speed of their website as well as the actual speed. Although their website is clearly very fast, users perceive it as even faster due to the way that they prioritize on showing the user critical content before anything else.
Much has been made of the impact that speed can have on your conversion rate (I am skeptical of some of that – it really depends on the particular vertical) and retailers should consider investing in optimizing their perceived website performance along with actual website speed.