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:
| 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.
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.
According to Cloudflare.com, 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.
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:
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.
M
B
E
D