I have two questions, could be silly though
1. Instead of serving static content from a cookieless domain, can we serve static content from a sub-domain?
2. And how to configure it as a cookieless sub-domain or domain ( if sub domain is really not possible)?
Just an additional information that we are using our domain as
http://www.example.com ( not as example.com).
Thanks in anticipation.
1 - You could serve the content from a different sub-domain but if you set any cookies to the top domain it would defeat the purpose.
For example...If your website is at
http://www.example.com you could serve static content from images.example.com as long as you never set cookies to example.com (and set them to
http://www.example.com instead).
2 - There's really no explicit concept of a "cookieless domain" it is just by convention that you NEVER set cookies on that domain from your pages.
Pat,
Thanks very much for your valuable input. We are serving our static content from sub domain/s and having cookies set up at the domain level (
http://www.example.com). We do need cookies at domain level and can't get rid of these.
I was going through this blog
http://www.pubbs.net/nginx/200909/84064/ where in first paragraph Nick mentioned that it is possible to have cookieless sub domain in such situations, but didn't mention how? and there is no link to ask him a question either. Wondering is there real way to this or it was just a guess
I think I got the answer from Yahoo
http://developer.yahoo.com/performance/rules.html link It says :
Use Cookie-free Domains for Components
tag: cookie
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is
http://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
http://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.
Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to cache the components that are requested with cookies. On a related note, if you wonder if you should use example.org or
http://www.example.org for your home page, consider the cookie impact. Omitting www leaves you no choice but to write cookies to *.example.org, so for performance reasons it's best to use the www subdomain and write the cookies to that subdomain.
Hi everyone, just discovered this amazing site! Really well thought out & put together.
I ran a test on my site & saw that I need to Enable browser caching of static assets. Searching to find out more I found this thread instead. It seems really interesting.
Do I understand this correctly?... When images are downloaded cookies get downloaded with them too? So if I put my images on a separate domain which does not use cookies I will get a faster response time? That would also apply to style sheets etc?
Sorry if this is a real newbie kind of question.
-
Sort of. When images or style sheets are requested, the request includes any cookies for the domain. It doesn't usually make a HUGE difference but sending the cookies up to the server takes time (more so than downloading since the upload bandwidth is usually quite a bit less than the download bandwidth). Putting the static content on a different domain keeps the requests clear of cookies and makes them a bit faster.
The cookies (and ETags) are the least important of the optimizations though and at best will save a few milliseconds. Making the static assets cachable can have an ENORMOUS difference for a repeat visit (50-90% faster).
Using another domain to serve static content also speeds up the rendering by getting around the concurrent-connections to each domain rule in the browsers.
If you're using a sub-domain of the main domain chances are this will not help with cookies. In the case of your main content being on example.com and then using the sub-domain static.example.com cookies will generally be set for .example.com and thus be sent with requests to static.example.time. This is particularly true with Google AdSense which doesn't allow you to limit the domain the cookie is set for.
I wrote an article about this subject, including speed tests with Chrome and Keynote for the before and after:
http://symkat.com/105/cookieless-domains/
I hope this is helpful.
