Continuing with our recent Rigor announcement, I was recently questioned over some advice I had given on domain sharding, and whether it was still relevant today.

I’ll be honest, at first, I just took the question as is and explained that yes, domain sharding is a recommendation for the website we were reviewing. It wasn’t until after I finished my explanation that the reason for asking this question came to light [hint: it relates to HTTP/2], so I thought it would be good to write a blog post about domain sharding and whether it’s still best practice.

The first task is to explain what domain sharding is.

What is domain sharing?

Domain sharding is a method used to increase the number of simultaneously downloaded resources for a website. You may already know this, but web browsers have a connection limit for each hostname. Back in Internet Explorer 5 days, the limit was two connections per hostname, while today’s current set of browsers offer anywhere between six to 13 connections.

When a web page exceeds a browser’s connection limit per hostname, the requests get queued up resulting in delays in the web page loading and becoming interactive. In turn, this leads to slow web page load times and ultimately will impact the website’s conversion rate.

To work around a web browser’s hostname connection limit is to serve specific content over a subdomain. This approach enables developers to increase the number of request threads spun up for their website, helping improve the overall performance. A typical example of domain sharding is using a subdomain for images, e.g. images.mydomain.com.

Just like everything in life, a sensible balance is required, so please read on and don’t run off and create 101 subdomains! And don’t forget, web browsers also cap the total number of connections allowed.

HTTP/2

The next point to consider is what version of the HTTP network protocol your website uses, and this can make a difference on whether you adopt domain sharding or not.

The latest version HTTP network protocol is HTTP/2 which was introduced in May 2015. The majority of browsers support HTTP/2, and its adoption is picking up speed with the latest analysis showing a 32.8% website adoption rate.

I’m not going to list all of the technical details around HTTP/2, but I am going to touch on why domain sharding and HTTP/2 will most likely degrade your website performance. If you want to know more about HTTP/2, as a starting point I can recommend the following:

• Wikipedia offers a good summary and bullet point list around some of the technical goals.
• Google’s Introduction to HTTP/2.
• A Simple Performance Comparison of HTTPS, SPDY and HTTP/2 by HttpWatch.

One of the key differences between HTTP/1.1 and HTTP/2 is how content gets delivered to the browser. Below are two diagrams showing the request workflow for HTTP/1.1 and HTTP/2. First is the HTTP/1.1 request workflow - note how the requests are handled one at a time.

HTTP/2 takes a different approach and can make parallel requests over a single TCP connection (called multiplexed), resulting in several requests getting delivered over one connection. Note how the same size and number of requests gets delivered over a shorter period.

There is a gotcha though, and that domain sharding under HTTP/2 will hurt your page load times. So when the time comes for you to move to HTTP/2, do your homework, plan and review your current HTTP/1.1 specific optimisations and make sure you’re not going to degrade your website performance.

Well, is domain sharding still relevant today?

If you’re using HTTP/1.1, yes, domain sharding is still relevant. If however your web site is served under HTTP/2, then no – implementing domain sharding will hurt web performance.

And if you are using various HTTP/1.1 workarounds, moving across to HTTP/2 can lead to a bad performance experience, and depending on how many workarounds you have, it might not be a quick migration.

How can Rigor help?

When reviewing your website, Rigor runs the results of your web page against 289 rules and defects and provides advice on any detected issues. For each check, Rigor tells you the impact severity and the ease of fix, helping you prioritise the issue. Rigor also provides a clear summary of a defect along with instructions on how to resolve it.

In the case of HTTP/1.1 and HTTP/2, Rigor detects which version of HTTP is used to serve your website’s resources, and, where appropriate, Rigor adjusts the advice to you accordingly, with HTTP/1.1 receiving domain sharding advice, while HTTP/2 receiving advice on H2 Push.

If this has intrigued you, and you’d like to find out more, then please take a look at our website, or contact us here and we can get in touch, or if you are keen to see how Rigor can help you, please register for a free trial.