serving static files via a cookiless subdomain?

Nick Pearson nick.pearson at gmail.com
Thu Sep 10 04:25:13 MSD 2009


This depends somewhat on how your site stores cookies.  If your
website lives at www.example.com, it can store cookies at either
"www.example.com" or just "example.com".  The reason this matters is
that all "example.com" cookies will be sent in requests for
*.example.com, but "www.example.com" cookies will only be sent to
requests at www.example.com (e.g., not to static.example.com).  As
such, you can use a subdomain (rather than a separate domain) if your
cookies are stored with a "www" prefix.

You can find out some pretty detailed information on this here:
http://code.google.com/speed/page-speed/docs/request.html#ServeFromCookielessDomain

There's a lot of other good information at that site that points out
how to optimize websites for speed.

I doubt if the .mp3 downloads will benefit much from not sending
cookies in the header, mostly because they aren't (usually) downloaded
in quick succession the way images are.  Also note that most browsers
limit to four connections per host while downloading assets, so if you
have a lot, consider spreading them out over multiple subdomains, such
as static1.example.com, static2.example.com, etc.

As far as doing this in nginx, there are many ways.  The simplest
would be to just add more hosts to your server_name declaration.  If
you want to limit the asset hosts to just serving assets, then just
add a new server block:

server {
  ...
  server_name  static1.example.com  static2.example.com ... ;
  root ... ;
  location / {
    ...
  }
}


On Wed, Sep 9, 2009 at 7:01 PM, Ilan Berkner<iberkner at gmail.com> wrote:
> Hi All,
> We serve MANY .mp3 file and images.  These files hardly ever change so I'm
> thinking about serving them off of a "cookieless" domain per suggestion of
> the yslow component.
> 1. Does it make sense in general to do this?
> 2. How would you do it in Nginx?
> Currently we just have one webserver, we are thinking about adding another.





More information about the nginx mailing list