Hacker News new | past | comments | ask | show | jobs | submit login

Years ago, webpages loaded faster by using domain sharding. A big website I had used one domain as its primary, but images were on another domain, and there was yet another domain for resources like css and js.



That's an infrastructure problem. Sure you can solve it with domains, but you can also easily use other current technologies for it with no issues as well and never change the domain name at all.


NCSA was using regional DNS for load balancing in '95. I don't know who invented it but it's at least 25 years old.


How is this faster?

More DNS requests, more TCP connections. At first this is purely slower.


Browsers used to/still do max number of connections per domain. Adding more domains allows you to do more concurrent requests.


With HTTPS you have to handshake for the first connection on each domain.


Yes and it still outweighed that especially if you were loading a lot of images or a stupid amount of different JS/CSS files


Upstreams were very limited, and HTTP requests send cookie data in each GET.

For instance, if you had a 128kbps DSL upstream and each request was 2KB (loaded up with cookies), you're already limited to 8 requests/second. A cookie-less domain for small resources helped this a lot.


Pretty sure in HTTP 1.1, there was a max amount of concurrent requests per server/proxy. So using different domains allowed more rq/s.


A separate domain name for static assets would not receive any cookies of the actual site. This means less data transferred and in theory a proxy closer to the user could more easily cache these requests, even for multiple clients.


More connections = better parallelism = faster downloads

The DNS is cached.


Before HTTP2 this was common


It spreads out the load on disks and outbound bandwidth.


You are making the assumption that the domain pointed to different physical servers. To get the benefits of what everyone else is describing it does not matter what the domains actually are pointing to.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: