32

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.

6 Answers 6

25

Many sites have quite a lot of cookies set, these cookies have the purpose of supporting some kind of state.

By putting the static (stateless) resources on a completely different domain you can reduce the size of the http requests. In some cases there are so many cookie that a single http request takes two TCP packets to be transmitted. So having a separate domain is one of the ways to reduce the number of packets to request the various parts of a page.

Other methods with the same goal are merging a lot of images into a single sprite and merging all Javascript into a single file.

3
  • Wouldn't it be better to just serve your site from www.example.com (so that the cookies are stored against that domain instead of the TLD), and have your CDN on a different subdomain like static.example.com?
    – Tullo_x86
    Dec 26, 2019 at 19:37
  • 1
    In many cases sites are already split into parts like shop.example.com and login.example.com. I have also seen situations where something like analytics.example.com is really a CNAME towards an analytical SaaS. So they often want to share state between these separate hostnames and put the cookies they want to share on the domain .example.com. If you then do not want any cookies going to the static resources you really need a completely separate domain for that. Dec 26, 2019 at 21:50
  • Seems like there is actually a valid case for subdomains like login.www.example.com then. How ugly. I see why people just use another domain.
    – Tullo_x86
    Jan 6, 2020 at 20:21
25

Aside from use of CDNs, using separate domains for static data also means:

  1. You can use a lightweight web server that doesn't have to load all the modules/extensions that your dynamic content web server has to load on every single request. Not having to scan each directory in the URI path to read .htaccess files also increases the number of simultaneous requests the server can handle.

  2. Adding an extra subdomain means you increase the number of parallel downloads that the browser can perform.

  3. If set up properly (e.g. your site is hosted on www.example.com instead of example.com), you can also take advantage of a cookieless subdomain, reducing traffic and roundtrip times.

The only downside is, if you're using SSL sessions, you need a signed certificate and separate static IP for the additional domain(s). But the benefits outweigh this minor inconvenience in most cases.

Edit:

Sorry, I misread your question. If you're asking why some people use separate SLDs, that would be answered by the parenthesis on #3. It's also explained on sstatic.net:

If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.

But incarnate also mentions a good point about using a separate generic SLD instead of a subdomain of an existing SLD when you're running a large network of sites that share certain assets.

Lastly, as Niels Basjes points out, part of the reason for eliminating cookies is to minimize the number of packets used to perform a request. I think the YSlow guidelines state that most networks have a max packet size of 1500 bytes, so keeping it under 1500 bytes would reduce TCP overhead. This also demonstrates another advantage of using sstatic.net instead of static.webmasters.stackexchange.com.

4
  • Why would you need a separate ip? Jan 26, 2012 at 10:01
  • 2
    Because the encryption is traditionally applied before the domain name is sent. SNI, which alleviates this, is not yet universally supported - you'd be excluding IE on XP.
    – phihag
    Jan 26, 2012 at 12:28
  • @Mihalis: Just to add to phihag's comment, you'd also be excluding Windows Mobile 6.5 and older, Android 2.x and older, Blackberry Browser, Safari on XP... The full list of supported/unsupported software can be found here: en.wikipedia.org/wiki/Server_Name_Indication#No_support Jan 26, 2012 at 19:24
  • 3
    I am not asking about why to use multiple subdomains - that makes sense to me. I am asking about separate full domains. Why sstatic.net rather than static.stackexchange.com? Jan 26, 2012 at 21:16
6

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.

5

Lèse majesté covered the main points, but to expand further I'd add that having a single domain for all the various Stack Exchange sites means that someone browsing them will only download static content such as JavaScripts once. Going to Superuser, for example, a user will use the cached content since it is from the same place.

There's some more useful info on Yahoo and Google about this.

3

Older browsers are restricted to just two parallel downloads per hostname.

Splitting a web page's elements across multiple domains is called domain sharding. Doing this allows more resources to be downloaded in parallel, reducing the overall page load times.

The optimal number of domains to shard across is 2-4. After 4 domains, response time degrades.

3

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 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. Consider implementing separate domains for static and/or user-generated content. Always implement recommendations for developing secure web applications such as CSP, SRI, and CORS. The connect-src CSP directive and the—hopefully available soon—navigate-to directive 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:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.