Sharding Antipatterns
At Section we commonly rewrite HTML to remove over-zealous attempts at domain sharding.
A few years ago browsers constrained the number of connections they used when talking to a web server. With all the to and fro that’s required to build a web page that meant that the user’s Internet connection wasn’t fully utilised. Downloading more files simultaneously meant that the page could load faster because the user’s Internet link was used more effectively.
This limitation is built into the HTTP RFC specification with the intention of protecting servers from being overloaded. As web server technology has improved browser manufacturers have started to overrule the RFC and allow the browser to establish more connections.
IE7 only supported 2 connections per name. IE8 increased the limit to 6 connections, and IE10 has increased the number to 8 connections.
What’s the problem with too many connections? Each connection makes HTTP requests on top of the TCP protocol, and there’s overhead in establishing the connection. Furthermore, once the connection is established, TCP goes through a period called “slow start”, where the connection doesn’t run at full throttle. When you make too many connections you pay too much in the TCP establishment tax which outweighs the benefit of the parallelisation.
One area where we see people fall down is with Magento. Magento’s admin screens provide handy textboxes that allow you to type in the names of the Javascript domain, the CSS domain and the Images domain. We see sites enter three unique values here. This means that a user would connect to www.your-important-business.com, js.your-important-business.com, css.your-important-business.com and images.your-important-business.com - each with 6 TCP connections, meaning you’ll have 24 TCP establishment costs to pay.
When you decide to shard your site you should run some experiments with different browsers and different pages on your site. We highly recommend www.webpagetest.org for that kind of testing.
At Section, we look at each web performance best practice and determine if it is right for a given situation, and we let experiments and data guide our decisions.
