Protocol Power - Site Speed in eCommerce - Kaizen

Making your site work for you

Your site speed isn’t simply a dial you can turn up in your page settings. There are a number of factors which contribute to it – here’s what they are, how they’ve been implemented (or not) across the industry, and how you can start making your site one of the fastest out there.

In the 700 sites researched, many sites weren't integrating valuable tactics into their speed improvement strategy. The following were the most prominent issues, as well as what percentage of sites weren't using them:

Top 10 recurring PageSpeed Insights errors
Speed Improvement Ocurrences Percentage of sites not utilising
Leverage Browser Caching 665 95%
Optimise Images 651 93%
Minimise Render Blocking Resources 637 91%
Minify JavaScript 427 61%
Enable Gzip Compression 374 54%
Minify HTML 371 53%
Minify CSS 242 35%
Server Response time 241 35%
Prioritise Visible Content 177 25%
Avoid Landing Page Redirects 47 7%

It’s quite the insight into where the eCommerce industry could squeeze a bit more speed out of their site. You can find out in the following sections how you can avoid the same mistakes, and take advantage of some of these ideas.

Protocol power

A. HTTP/1.1 isn’t SPDY enough

Network protocols are the rules and standards that govern the end points in a telecommunication connection – how data is transmitted over the web. Common examples include IP – Internet Protocol – and HTTP – Hypertext Transfer Protocol.

The HTTP/1.1 protocol is decades old and doesn’t make full use of newer technologies. The main downside of HTTP/1.1 is that it doesn’t allow you to download files in parallel. For each file (or request), the server needs a separate connection. HTTP/1.1 enables only one request per connection, while browsers now support a maximum of 6 connections per domain. This means that the number of files which can be downloaded and rendered simultaneously is limited - and that costs time.

Since the time of HTTP/1.1, Google has developed a newer version of the protocol named SPDY (“Speedy”), which allows simultaneous connections to be opened, and means that it can serve multiple parts of the website (JavaScript, HTML, images, etc.) in parallel.

But SPDY isn’t the latest protocol developed by Google. Working closely with W3C (World Wide Web Consortium), they’ve developed the new HTTP/2 protocol. HTTP/2 has roughly the same characteristics as SPDY, but is also binary, and allows the server to ‘push’ information to the requester, with better HPACK compression.

Difference between HTTP/1 and HTTP/2
Difference between HTTP/1 and HTTP/2 Difference between HTTP/1 and HTTP/2

It’s relatively limited throughout the internet, with some eCommerce sites often being slow to integrate it. However, our recent research discovered that 14.45% of the top 700 eCommerce sites are now using the technology – higher than the broader Internet average of 13.5% of sites overall. Some examples of websites using HTTP/2 are Vans, Paperchase or Expedia.

Usage of HTTP/2 for websites
Usage of HTTP/2 for websites Usage of HTTP/2 for websites

According to, when they implemented HTTP/2, they saw customers’ average page load time nearly halved – from 9.07 seconds for HTTP/1.X falling to 4.27 seconds for HTTP/2. That’s a significant improvement in a key area of website efficiency.

However, HTTP/2 doesn’t solve everything. While the majority of HTTP/2 cases had a significant reduction in average loading time, in some cases the results can be disappointing. There’s a number of potential reasons for this.

Switching to HTTP/2 isn’t enough by itself - many websites fail to optimise for the change and lose out on the maximum speed gains.

Old-school techniques, such as domain sharding or sprites, can be counter-productive.

And using huge CSS or JavaScript files where less than 10% of the rules and code is relevant to pages likely to be visited is a waste of both your user’s time and your server’s time.

Oliver Bonas’ Loading Performance
Oliver Bonas’ Loading Performance Oliver Bonas’ Loading Performance

Nice example of a successful HTTP/2 optimisation is Paper Chase who have saved a full second of time necessary to load their website, as is shown here:

Paper Chase’s Loading Performance
Paper Chase’s Loading Performance Paper Chase’s Loading Performance

B. Getting Started with HTTP/2

If you want to be at the forefront of network protocols – and at the top end of the list of speedy (though not SPDY) sites, it’s important to get an HTTP/2 protocol in place.

While HTTP/2 only requires the server to support the new protocol (a large number of server software providers have started to support it, though Microsoft’s IIS has no plans yet), the browsers will require a TLS connection. This means that every connection made over HTTP/2 will be safe and secure, adding an extra layer of security to the internet.

For more information on how you can get started with HTTP/2, have a look at our in-depth article here.