Should all my static content be on a cookie-less domain?

Question

We are currently serving a significant part of static content from an alternate (cookiefree) domain - in fact, it's a whole different IP-address as well should that matter.

This has certainly helped us with page load speed, however not all content is served from that domain.

Common knowledge seems to be that serving from a second domain is faster because you eliminate cookie/session/etc traffic and because it allows for more concurrent connections.

It's the latter that has me curious: if we move all static content to the other domain, the main domain will only get a single request (for the HTML) and all other subsequent requests go to the other domain.

This will reduce the amount of concurrent requests a browser will make to our server. Won't that make things slower? Especially because our pages often include a lot of images.

All information I can find suggests moving all content to the cookieless domain, but this issue is never mentioned which might mean that the authors might not have considered this downside?

Answer 1

You're right but you don't have to stick with a single cookieless domain...

For example you could shard via sub-domains e.g. use static.domain.com for js/css and then image1.domain.com / image2.domain.com / etc for images.

If you're running something like an image gallery you ideally want to shard the images over as many connections as the browser in use supports (I think - you may just want to test this against just using 6).

To ease maintenance each subdomain could be pointed back at the same server.

Update - 12 Dec 13

I wouldn't go over 2 shards these days (and I'd measure it with and without shards too) - Will Chan wrote a good post on 'over sharding' and TCP congestion - https://insouciant.org/tech/network-congestion-and-web-browsing/