Question: I notice a lot of sites host their resources on a separate domain from the main site, e.g. StackExchange using sstatic.net, Barnes & Noble using imagesbn.com, etc.

I understand that there are benefits to putting your static resources on a separate host, possibly with an efficient static-file web server like nginx, freeing up the main server to focus on serving dynamic content. Similarly, outsourcing to a shared CDN like cloudfront Akamai is logical.

What is the benefit to using a separate domain otherwise, though? Why sstatic.net instead of static.stackexchange.com?

**Update**: Several answers miss the core question. I understand that there is benefit to splitting between multiple hosts — parallel downloads, slimmer web server, etc. But what is more elusive is why multiple *domains*. Why sstatic.net rather than static.stackexchange.com as the host for shared resources? So far, only one answer has addressed that.

Answer: 
The main reason are cookies. What Niels suggested in his answer is only a minor consequence, and not the real reason. Without cookies, the request size is smaller, so it is saving some bandwidth.

However, the real difference comes from browser cache. Since content is static (i.e. does not change), browsers can cache it on local hard disk and avoid loading the file from Internet each time. Instead of whole file, the web server just sends a 304 reply, meaning that content has not changed.

When site uses cookies, browsers consider that content of the file might be different for different users, so they do not cache those files. Serving the file from cookie-less domain ensures that browser caching works properly. 

This is the main reason as it improves loading times and reduces bandwidth significantly.
Another reason for rendering static files from an alternate domain is to provide an additional security control through isolated web origins. [The browser's same-origin policy controls](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) ensure that content loaded from the alternate domain is disallowed from accessing the primary domain's cookies (such as user session cookies). This helps reduce the scope of supply chain attacks, where malicious code could be integrated into a vendor's JS library.

Note that this is only a reduction of scope; this architecture will still not be able to protect the primary site's page content from malicious JS, unless it is loaded within an `<iframe>`.

[**Never include** code, from any domain, that you don't trust](https://stackoverflow.com/a/27404921/764945). *Consider implementing* separate domains for static and/or user-generated content. **Always implement** [recommendations for developing secure web applications](https://infosec.mozilla.org/guidelines/web_security.html) such as CSP, SRI, and CORS. [The `connect-src` CSP directive](https://content-security-policy.com/connect-src/) and [the—hopefully available soon—`navigate-to` directive](https://w3c.github.io/webappsec-csp/#directive-navigate-to) will help a ton with minimizing a web application's attack surface when embedding resources.

The other answers covered some performance benefits regarding cookie handling, but the security aspects shouldn't be neglected.

References:

* [Google Online Security Blog: Content hosting for the modern web](https://security.googleblog.com/2012/08/content-hosting-for-modern-web.html)
* [Alternate Domain for Serving Content | Blackboard Help](https://help.blackboard.com/Learn/Administrator/Hosting/Security/Key_Security_Features/System_and_Information_Integrity/Safer_Dynamic_Content_Rendering)