Today’s blog is a repost from Peter McLachlan, Chief Architect at Mobify.  The article originally appeared on Mobify’s blog on October 30, 2012.

In this post we’ll review the results of a real-world test with over three million samples showing that domain sharding is at best neutral and at worst harmful for mobile websites.

If you’re already familiar with sharding, you may want to skip straight to our results. Otherwise, we’ll begin with a brief introduction to the subject.

What is Domain Sharding?

Traditionally, web browsers place a limit on the number of simultaneous connections a browser can make to one domain. These limits were established in 1999 in the HTTP/1.1 specification by the Internet Engineering Task Force (IETF). The intent of the limit was to avoid overloading web servers and to reduce internet congestion. The commonly used limit is no more than two simultaneous connections with any server or proxy.

Domain sharding is a technique to accelerate page load times by tricking browsers into opening more simultaneous connections than are normally allowed. It’s a widely-used optimization tactic that enables browsers to make better use of high-bandwidth internet connections.

The average web page references 44 different resources such as image files, stylesheets and JavaScript. Each of these resources need to be loaded for the page to render correctly, so domain sharding seems like a useful technique for increasing load times and, therefore, improving user experience.

However, there are two key reasons why domain sharding is no longer a best practice, and why web developers should particularly avoid it on mobile or responsive websites:

1. Additional network connections above and beyond the recommended limits are not “free”. Each connection comes with a setup overhead in the form of a DNS lookup and a TCP 3-Way handshake, as well as TCP slow start. For mobile browsers, the resulting latency is much higher than for desktop users. Additionally, this connection setup consumes extra CPU, memory and battery power–all considerations on mobile devices with scarce resources.
2. Many mobile browsers implement HTTP pipelining and no longer observe the old HTTP/1.1 connection rules.

Domain sharding works because web browsers recognize each unique internet name (a DNS entry such as www1.yourdomain.com, www2.yourdomain.com and so forth) as being a different server, even if in reality all those domain names resolve to a single server.

If you divide your references to static assets such as images, scripts and CSS files over several servers, the browser will open two connections to your web server for each server name. You may have noticed, for example, that resources on YouTube pages load from i1.ytimg.com, i2.ytimg.com and so forth.

The web, and web browsers, have changed

When the “two connections per server” rule was established, most internet users were using dial-up internet connections one-tenth to one-hundredth the speeds of today’s broadband connections. Most contemporary browsers no longer implement the two-connection per-server limit since 2010.

For example, the default for desktop Firefox is eight connections per server, and for Google Chrome and Internet Explorer 8/9 the limit is now six connections per server. For most websites, these values are high enough to effectively maximize bandwidth utilization. Additional sharding for desktop computers will only offer marginal improvements or may even penalize your site’s performance.

So what about in the mobile browser use case?

Here’s a table showing simultaneous connections by mobile browser type:


As you can see, mobile browsers also no longer respect the two-connection per-server limit.

So, is domain sharding still necessary? We wanted a definitive answer, so we ran some real-world tests.

Real-World Testing of Domain Sharding on Mobile Devices

Our test required downloading 15 images, each about 10 KB in size. By using a portion of our Mobify Cloud network, we were able to test using real users on real networks and real phones distributed around the planet with almost 3-million unique samples.

The test was limited to visitors using high-end smartphones such as iOS 5, Android 2.2+, BlackBerry OS 7 and newer devices. The backend was serviced by our global Content Delivery Network, so mobile visitors received data from a web server running in one of our 35 worldwide data centers with the images in memory geographically close to their location.

Here are our results:


Regardless of browser, when we added shards, the results were at best neutral and, in most cases, detrimental.

The lesson: the connection overhead for mobile browsers exceeds the benefits of having additional simultaneous connections.

Mobile Chrome takes the biggest penalty for adding more shards, performing half of a second slower when sharding is used, but Safari Mobile also pays a hefty penalty.

Domain Sharding Conclusions for Mobile Devices

Ultimately, sharding adds complexity to your infrastructure without providing performance benefits. In many cases, sharding can degrade visitor performance for your site.

Based on our data, we recommend disabling sharding for both for desktop and mobile visitors.