I have two questions, could be silly though 
Just an additional information that we are using our domain as 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 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 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 ( 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
to make sub domain cookie less see this discussion http://blog.wasimasif.com/serving-images-from-cookie-less-domain/
If you must share cookies for all sub domains you should use completely separate domain to serve static content. For example your domain is http://www.mydomain.com and all images on the page can be served from http://www.myimagedomain.com. For example face book logo is being served from http://static.ak.fbcdn.net/
Thanks wasimasif. This was great. I found another link in comments section of your blog, how to create cookieless sub domain. I 'll try that and will keep you guys posted. The link was Serve static content from a cookieless domain - Kensfi
Thanks.
Naresh
I think I got the answer from Yahoo Best Practices for Speeding Up Your Web Site - Yahoo Developer Network 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 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.
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 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. 
Hello,
we have the same problem. We write a new Domaincheck and images are really slow Domain check - schnell und kostenlos 800 Endungen prĂĽfen
Should we use a second domain for images?
thanks
Thanks very much for your valuable input. We are serving our static content from sub domains and having cookies set up at the domain level . We do need cookies at domain level and can’t get rid of these.
I made a cookieless subdomain, the server is lighttpd, so I put a .user.ini with session.use_cookies = 0 inside, put all my images in there, but I had no gain in pae load. Also the static content of subdomain did not load simultanuasly with main domain content, but after it like it was when all content was in main domain. In other words, nothing has changed. But I see the static content I defined (images) being served from subdomain.
Did I do anything wrong?
Thank you!
Do you have a link to some test results? Using a separate subdomain will not make the browser increase parallelism if it is being blocked for other reasons (only if it has maxed out it’s 6 connections on the main domain).
Just removing the cookies themselves is mostly a rounding error for sites unless they have enormous cookies and a huge number of requests so I wouldn’t be surprised to see no impact from that.
Thank you, my page is www.mikroviologos.gr.
Here are some test results:
http://www.webpagetest.org/result/120508_C3_4994W
Yeah, you have few enough resources that the DNS lookup time for the separate domain is using up any benefits you might see from sharding (and you have so few resources that sharding won’t help anyway).
Right now your 6 connections are tied up downloading the css and javascript. If you can merge any of the css files together that will free up a connection to download some of the image resources. Moving the javascript to the end of the page will also help if there are no inline dependencies (will let the browser focus on downloading the visible elements first).