Hello All,
Just curious on why so many sites have the cookies column with RED Xs.
Question:
- Why does it throw the RED X?
- Should it be fixed and will it help performance?
Thanks.
Regards,
TRX
The cookie check is one I have considered eliminating because it’s kind of a micro-optimization, particularly compared to a lot of the others. The basic rule is that you should serve static content from a “cookieless domain” (i.e. content that doesn’t actually use the cookies). The reason is that cookies can add to the size of the request and requests are usually sent upstream on asymmetrical user connections where the upstream is the slower part. A 100 byte cookie across 100 requests is 10KB of outbound data.
Unless the cookies are huge and on a LOT of requests I wouldn’t bother with it. If you have already optimized everything else and are possibly looking at adding a CDN that would be a god time to make sure that your cookies are not bleeding over to the CDN domain.
-Pat
When you say “bleeding” over the CDN domain, what do you mean exactly?
We are currently using CDN (ADN platform to be specific with caching enabled).
Let me know.
Thanks.
Regards,
TRX
Let’s say I have www.webpagetest.org and cdn.webpagetest.org. If I set a cookie to webpagetest.org (instead of www.webpagetest.org) then it will “bleed over” to cdn.webpagetest.org as well. In a situation like that it’s usually best to put the CDN on a completely different domain - like www.webpagetestcdn.org.
Thanks,
-Pat
Excuse my ignorance. When you say
“If I set a cookie to webpagetest.org (instead of http://www.webpagetest.org) then it will “bleed over” to cdn.webpagetest.org as well.”
… are you saying that “webpagetest.org” is different than "http://www.webpagetest.org?
Let me know.
Thanks.
Regards,
TRX
Yes, webpagetest.org and www.webpagetest.org are different. Cookies are automatically applied to any sub-domains of the domain that they are set on so if you run your website on the bare domain then any cookies will also be included in requests for any and all sub-domains.
Most don’t know, but www.example.com is basically a subdomain of the example.com. DNS goes from right to left going from the Top Level Domain (TLD, like .com, .net) to the domain (example) to subdomains (sub.example.com, www.example.com), and each level being delimited by a period (.). When setting a cookie in your site software, you can choose to set the cookie to .example.com, which sets the cookie for the domain example.com and all subdomains like www.example.com. If you set your CDN up with cnames to be a subdomain (cdn1.example.com), then the browser will send the cookie for the cdn as well. Normally this is done so that the cookie can be accessed by both www and non-www versions of the site.
The CDN cnames match our DNS cnames. So I don’t think cookies bleeding would be an issue. Would you agree?
ex)
Let me know.
Thanks.
Regards,
TRX
I’m not sure I understand. What do you mean the CDN cnames match your DNS CNames? When I look at www.qad.com it looks like the static content is served from www.qad.com as well (in which case the cookies WILL be sent with the static content). If you are using a whole-site accelerator product from the CDN where everything is on the same domain then cookies are being sent for the static content too.
There are more to cookies than I thought. Are using the CDN platform called ADN (Application Delivery Netowork) but also utilizing the caching part of it as well.
Questions:
- From what you see, do we have a cookie bleeding problem?
- Should we ignore the cookie errors as they are minor?
- You have an example of sites/explanation (cookie bleeding vs. NOT bleeding) to better understand the concept?
Let me know.
Thanks.
Regards,
TRX
1 - yes (though technically it’s not “bleeding” since it’s literally the same domain. You have the problem of not serving static content from a cookieless domain.
2 - yes
3 - Enable Compression | PageSpeed Insights | Google Developers
Thanks,
-Pat
btw Thanks!
Regards,
TRX