TL;DR: This this the first in a series of blog posts related to improving the performance of e-commerce web storefronts. This post runs through some of the more common performance problems sites experience, laying the groundwork for later posts.

A recent Think With Google article rated retail websites as the slowest category of all web sites. Specifically

“… in a study of 6 million websites, retail sites were ranked at the very bottom of page speed, with an average load time 26% slower than the fastest category.”

Ugh!

To be fair, it is not clear to me whether the difference is because retail sites are not built as well or whether such sites have more complex pages. Regardless, it is not a good result since it is also known that site speed impacts conversion rates.

While it is easy to agree that a faster site will lose fewer shoppers and so conversion rates will increase, how to estimate the impact? One tool I have mentioned before is the Google site speed revenue impact calculator. This tool estimates the revenue impact of site performance, which can be useful when discussing the merits of such work.

So what common performance problems affect e-commerce sites?

Common Performance Problems

I will say up front that the problems I mention below are all well known and all have solutions. However they are still commonly seen. Why? One big factor is that doing a fantastic job is a lot harder than doing a good job. Applying all of the solutions together on top of an existing e-commerce platform can be hard.

One of my personal interests is to work out how to make typical sites better (rather than how to make the best sites even better). That means the challenge is less about working out how to make a site faster and more about how to make the known solutions more accessible to more developers.

TIP: Want a more detailed performance test report on your own site? Check out Lighthouse, which is available in the “Audits” tab in Chrome Developer Tools. Point it at different pages on your site and see how you score and what advice it provides to improve your score.

Common reasons for a site to be slow include the following.

Images are too large

From a range of site performance reviews I have seen, the most common issue is poorly performing images. Images are clearly important to both site appeal and for sharing product information. They can also be useful to help guide users through sites in lower literacy geographies. So images are worth getting right.

Sometimes images are uploaded that are larger than the screen can display. This means a browser will download an image the discard some of it, which is wasteful. Another reason for image inefficiency is images that have not been compressed well. Other times the platform default behavior is not optimal for your site. If you want to speed up your site, it is worth spending some time reviewing the images on your site as a first step. It may be updating a few key images on your site with better compressed versions is sufficient to get a boost.

There are a number of services around that can provide image compression and resizing, making improving image performance easier. Also check out this article for some hands-on advice on image compression.

Images on low-end devices

Images have other challenges beyond just the file size to be downloaded. Decompression speed (and battery required usage) can be an issue on low end mobile devices. This can be a challenge given the ever increasing number of low end devices on the market. If low end phones matter to you, spend some time to understand which image formats work best on such devices.

Unused CSS

It is common for CSS to bloat over time. There are tools to cull out unused CSS rules (such as CSS Coverage tool and UnCSS), but they are not always integrated well with e-commerce platforms, and they can be hard to automate when pages contain dynamic content (it is hard to predict in advance which rules are going to be used, especially if some of the content comes from databases).

It is also worth noting that it can be hard to predict if a CSS class name is going to be used or not because content (such as a product description) may be stored in a database and so the full class list is not known when building the site.

It is worth checking what tools are supplied by the platform you are using and whether better tools are available.

Bundling CSS

You want the first page a user visits to be fast, which means you should load “just enough” for that page. If you create a single CSS file for the overall site, it means once loaded subsequent page loads will be faster (because each page can reference the same file which will be in the browser’s cache). But is also has a negative – the first page will load more CSS than it needs.

One approach to help is to work out the most common landing pages for a user arriving on the site, and then create CSS files with just the CSS required by those pages. For example, product pages or category pages may be common landing pages from search engines. The rest of the CSS required by the site may then be added to another file. Thus a user’s first page experience will load just the CSS file needed for that page, and subsequent pages will then load a second CSS file with the rest of the rules. By mapping out the most common journey for visitors on your site, you can work out the most appropriate bundles to use.

Further, parsing CSS does take time (especially for larger files). So an additional technique is to identify the CSS required to format a page “above the fold”. The idea is to inline just enough CSS to make the first page display quickly, with minimal external dependencies. A separate file is then used for the other less important CSS rules. CSS inlined in a page cannot be shared between pages, but generally improves render speed as all the formatting information is known when the browser starts parsing and rendering the start of the HTML page contents.

Many sites support CSS minification (which strips unnecessary content like whitespace to reduce file sizes), but few support bundling out of the box. (See also here and here.)

The average volume of JavaScript on a site is going up

Many developers reuse existing libraries (such as jQuery), which makes sense from a software engineering perspective. However, large libraries can have a negative performance consequences in that more JavaScript needs to be downloaded and parsed, slowing down sites. It is easy to loading a library only to use a small number of functions from it, which may be good software engineering practice, but has negatives in terms of site performance.

There are some tree shaking tools available which go through a library and remove JavaScript code in the library that you do not use, but these tools are not available out of the box for all e-commerce platforms.

Multiple versions of JavaScript libraries

On some sites where different developers author different parts of a site, a problem that can occur is they use different versions of the same library. For example, an e-commerce site with extensions may have extensions from different vendors using a different version of the jQuery library than the main site. Even if the same version, difference extensions may use different copies of the library such as minified and non-minified versions. This can result in different versions of the same library being loaded multiple times.

JavaScript can be render blocking

Render blocking JavaScript is JavaScript where the page cannot be displayed until all the JavaScript is downloaded, parsed, and executed. That can significantly block how long it takes to display the page. It is better to download JavaScript asynchronously or defer it so the page can be displayed as quickly as possible. Non-expert JavaScript developers can block rendering without realizing they have done so.

Device performance

When performance testing, you need to think about your target audience. Do you want a great site for users with the latest top-end devices or users with low end phones? Advances in mobile technology have made lower powered phones available to more people. This means that users with low end devices are growing at a faster rate than top end users and top end devices. So not only do you need to make your site more efficient to achieve better conversion rates, you also need to make it efficient on low end devices or else the page may fail to load on a low end device due to running out of memory or similar.

Conclusions

This blog ran through a number of common problems for e-commerce websites. Most of the issues have solutions, but those solutions are not always easy to adopt. When using an e-commerce platform, the available set of tools is often dictated by the platform.

But the reality is that even though there are known solutions to many site performance problems, they are not always easy accessible.

In an upcoming post I describe an approach to make typical sites that perform well  simpler to develop.