Take the 2-minute tour ×

An image server for static images and possibly other static files (css, js, etc). Are they only used for large/popular websites? Secondly, are they only really beneficial when the images undergo some sort of processing (e.g. resizing)? I'm not a server guy, so this is unfamiliar territory for me. I'm working with IIS. Are there major differences if it's done on a subdomain (images.mywebsite.com) on the same server or on another separate machine.

share|improve this question

3 Answers 3

up vote 2 down vote accepted

Using an image server allows you to serve the images from shorter requests. All the domain specific cookies get dropped. It also makes it easier to set caching policies. If the static content is on a separate server, you can set a caching policy for it without caching your dynamic content.

Securing the static content is simpler as well. The server can be restricted to answering only GET requests. Referrer restrictions can be added as well, although they are easy to bypass.

Log analysis is also easier as you don't need to filter or process log entries for images and other non page content.

share|improve this answer

If your site isn't very large, and one server can handle all the traffic you anticipate. Simply adding something like static.yourdomain.com via DNS, and linking all your static content off that can provide some benifits because browsers will only do two downloads per DNS name at the same time.

So having

  • css.yourdomain.com
  • img.yourdomain.com
  • www.yourdomain.com

can yeild 6 concurrent downloads over HTTP. This can induce extra DNS lookups, but ideally those will be very quick.

This setup can be done all on the same server, simply with different DNS entries, and when your site is big enough to require separate servers, you can change the DNS and only host the related content under each subdomain.

share|improve this answer

The biggest advantage is that you can take your static content (which is usually the bulk of a site's traffic), and serve it off faster servers -- perhaps thttpd instead of apache, since you don't need all the extra power of apache, or you could mirror them on multiple servers so that they're served closer to where your user is actually from.

Usually, this isn't something you would need to worry about until your site gets fairly large.

share|improve this answer

Your Answer


