: How many domains to split components across? I understand how splitting components across domains can maximize parallel downloads, and enable you to have cookie-free static content domains, but

@Mendez628

I can think of one edge case where the benefits of multi-host requests outweighs the DNS setup costs.

When serving map tiles from a Google Maps-style slippy map, you can see benefits from distributing your tile locations virtually across a much larger number of hosts, even if they are all pointing at the same underlying resources (images). In these cases, you'll want to ensure that the resources have an "affinity" set to one host based on their properties (such as some combination of the MOD of row and column numbers) so that browser caching works optimally and requests are balanced across all hosts for any given view extent.

This situation is very specialized, but it basically just emphasizes that if you have a non-standard use case make sure that you test everything, and don't forget to include both raw numbers and UX / perceived performance of all of the scenarios.

Vote Up Vote Down

@Pierce454

My recommendation is that for relatively simple sites, one "static content" domain should be sufficient. DNS lookups should be cached, so only affect the first contact with that server, but it should still be kept to a minimum.

You can place all of your Javascript, CSS and static images on there to reduce the overhead of cookie processing and to provide the option of offloading that work on to a different physical server. If you are running multiple popular, related sites (e.g. Stack Overflow, Server Fault etc.), then you can share a static site between them all (e.g. sstatic.net).

Of course, there may be situations where more domains are appropriate (e.g. a photo hosting site may offload the photo serving to another separate domain).

Vote Up Vote Down