HOW TO serve static content from a cookieless domain

Serving static content from a cookieless domain is a performance best practice. Static content, such as images, JS and CSS files, don't need to be accompanied by cookies, as there is no user interaction with these resources.

To reserve a cookieless domain for serving static content, register a new domain name and configure your DNS database with a CNAME record that points the new domain to your existing domain A record. Configure your web server to serve static resources from the new domain, and do not allow any cookies to be set anywhere on this domain. In your web pages, reference the domain name in the URLs for the static resources. 

Though it may be better idea to host static content on totally separate domain name, you can use a sub-domain for static files if you are certain that you will never have a cookie set for *.domain.comYou'll need to ensure applications like Google Analytics and WordPress (or any other third-party service providers) don't set cookies at a domain level, but rather restrict them to the www sub-domain.

Cookies set at the top-level domain apply to all subdomains as well. The cookies set by Google Analytics are usually set on a domain-wide basis to cover all subdomains.  Use of Google Analytics puts the average user’s cookie size around 1 kilobyte. In order to set up a cookieless subdomain you have to make sure that your server or application only sets cookies for www.example.com and not the top-level example.com.

Many Google properties, including News and Code (this site), serve static resources, such as JS files and images, from a separate domain, www.gstatic.com. YouTube serves static media from places like ytimg.com. A Facebook photo may be served from a domain like fbcdn-x-x.akamaihd.net. Google & Microsoft offer developers to use popular JavaScript libraries from their CDN.  Microsoft used to host these at ajax.microsoft.com but now serves them from ajax.aspnetcdn.com to avoid the perf hit due to cookies.

Google recommends that early loaded (or JavaScript referenced in the head of the document and needed for page startup) external JS files should not be served from the cookieless domain but instead should be served from the same hostname as the main document. This is because most browsers block other downloads and rendering until all JavaScript files have been downloaded, parsed and executed, it's better to avoid the risk of an additional DNS lookup at this point of processing.

Related:

Comments