@toomanyairmiles is partially correct - the purpose of this technique is to allow parrallel connections from the web-browser to the server. Web browsers should allow a minimum of two simultaneous connections to a single host, but many new browsers can manage up to 60. Regardless, concurrent simultaneous connections between browser and webserver(s) is a major speed bottleneck.
From Google's resource:
So the way to get around this is to "shard' the requests to either different domains, or hosts:
Again, from the same Google resource:
Balance parallelizable resources across hostnames.
Requests for most static resources, including images, CSS, and other binary objects, can be parallelized. Balance requests to all these objects as much as possible across the hostnames. If that's not possible, as a rule of thumb, try to ensure that no one host serves more than 50% more than the average across all hosts. So, for example, if you have 40 resources, and 4 hosts, each host should serve ideally 10 resources; in the worst case, no host should serve more than 15. If you have 100 resources and 4 hosts, each host should serve 25 resources; no one host should serve more than 38.
Static content, such as images, JS and CSS files, don't need to be accompanied by cookies, as there is no user interaction with these resources. You can decrease request latency by serving static resources from a domain that doesn't serve cookies. This technique is especially useful for pages referencing large volumes of rarely cached static content, such as frequently changing image thumbnails, or infrequently accessed image archives. We recommend this technique for any page that serves more than 5 static resources. (For pages that serve fewer resources than this, it's not worth the cost of setting up an extra domain.)
To reserve a cookieless domain for serving static content, register a
new domain name and configure your DNS database with a CNAME record
that points the new domain to your existing domain A record. Configure
your web server to serve static resources from the new domain, and do
not allow any cookies to be set anywhere on this domain. In your web
pages, reference the domain name in the URLs for the static resources.