Domain Sharding

Domain Sharding

What is Domain Sharding?

Domain sharding is a technique used to increase the amount of simultaneously downloaded resources for a particular website by using multiple domains. This allows websites to be delivered faster to users as they do not have to wait for the previous set of resources to be downloaded before beginning the next set.

Web browsers traditionally place limits on the amount of concurrent downloads allowed for each domain (between 2-16). This limit was put in place by the Internet Engineering Task Force and is mentioned in the HTTP/1.1 specification. It was recommended in order to reduce Internet congestion and web server overloading. Therefore, in order to overcome this limitation due to the growing use of resources required to load a page, the implementation of domain sharding was introduced.

Pros vs Cons of Domain Sharding

Like anything, domain sharding comes with pros and cons which are listed below.


  • Additional resources being downloaded in parallel
  • Faster page load time


  • Increased DNS lookup times
  • Website modifications
  • Increased TCP overhead

For certain websites, the use of domain sharding is simply not required based on the amount of requests needed to generate a web page. For example, if a browser is able to download 6 resources in parallel and a website only requires 6 resources, then it would not be required and furthermore would be harmful to website performance. This is due to the additional DNS lookup and connection times required for the additional domain. However, in the case that a website must load a large number of resources, domain sharding can be useful as seen in the next example.


As mentioned, domain sharding works by using multiple domains to deliver content to a single website. For example, assets such as CSS, JavaScript, or image files can be split so that some are downloaded from and others from This allows for additional connections to be established and enables further parallelization of downloading resources.

In the example below from, the page needs to load 45 resources from the same host. In this example, no domain sharding is being utilized. The brown sections display the amount of time the resources are stuck waiting to be downloaded while the purple sections are the amount of time it took to download the resources.

waterfall domain sharding offNo Domain Sharding Src:

The next image displays the same website, this time, with the use of domain sharding. As you can see, the amount of time resources are spent waiting for a connection to be open is reduced considerably, resulting in a page load time that is 33% faster.

waterfall domain sharding onDomain Sharding Src:

Domain Sharding and HTTP/2 & SPDY

With the growing popularity of protocols such as SPDY and primarily HTTP/2, domain sharding has become irrelevant and is in most cases recommended to avoid it. Its main purpose is to increase the number of simultaneous connections in order to download resources faster and to avoid having to wait for open connections.

This is no longer an issue when using the HTTP/2 and SPDY protocols. These protocols perform parallelized transfers allowing for multiple requests to be performed simultaneously thus increasing speed and reducing additional round trip times (RTT). If you have either SPDY or HTTP/2 configured and your website users are using popular, up-to-date browsers such as Chrome, Firefox, etc then it is unnecessary to use domain sharding. However, if your users are still using an older web browser such as IE6 or 7, which does not support HTTP/2 or SPDY, then it could be beneficial to implement.

Note: Google has officially announced that SPDY will be completely withdrawn in 2016 while the focus is now directed towards HTTP/2.


In certain scenarios, domain sharding is a useful technique when wanting to deliver resources faster to end users. However, due to more advanced protocols, such as HTTP/2, domain sharding is becoming more and more obsolete and soon will be only beneficial to older browser versions. However, until the day when your website is being delivered though HTTP/2, it may be worth further investigating if your website relies heavily on many resources.