MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
WebPagetest Forums - Serving static content from a cookieless domain

WebPagetest Forums

Full Version: Serving static content from a cookieless domain
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I have two questions, could be silly though Smile

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 ( not as

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 you could serve static content from as long as you never set cookies to (and set them to 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.
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 ( We do need cookies at domain level and can't get rid of these.

I was going through this blog 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 Smile
to make sub domain cookie less see this discussion

If you must share cookies for all sub domains you should use completely separate domain to serve static content. For example your domain is and all images on the page can be served from For example face book logo is being served from
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
I think I got the answer from Yahoo 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, you can host your static components on However, if you've already set cookies on the top-level domain as opposed to, then all the requests to 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, YouTube uses, Amazon uses 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 or for your home page, consider the cookie impact. Omitting www leaves you no choice but to write cookies to *, 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 and then using the sub-domain cookies will generally be set for 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:

I hope this is helpful. Heart

we have the same problem. We write a new Domaincheck and images are really slow

Should we use a second domain for images?

Pages: 1 2
Reference URL's