Optimizing Site Performance: Cookieless Domains

Creative Commons License woordenaar
We all like eating cookies, but only so many. Some websites, though, force too many down our throat and I have to say mine was one of those guilty ones. Google’s Page Speed tool (and site) gives you an incredible amount of website optimization info. Analyzing my page’s performance showed that all the static content was being requested with our site’s cookie. By moving most of our static content (images, javascript and css files) to a cookieless domain I saved our users time and bandwidth.

Why do these requests have a cookie?


Because our domain was globally covered by cookies, even the static content was automatically getting sidled with them. With around 125 resources and 125 bytes per cookie, I was having the user send almost 15KB of cookies upstream on every page request … 😦

For $2, I got a new domain – ndimg.de – and setup the virtual host entry. A few application & configuration changes later, and voila! No more cookies!

All things in moderation


The numbers speak for themselves. A noticeable reduction in total response time with very little programming effort.

Better Logs

An unexpected bonus of doing this was getting a separate apache log file for static requests. This information isn’t really relevant to your business and I saw nearly a 500% reduction in the size of my main data log! So remember to add a logger within the new virtual host.

    ServerName s.ndimg.de

    LogLevel warn
    LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" " combined-host
    CustomLog /var/log/apache2/static_content.log combined-host

I’ve set my next sites on reducing the total number of requests – 125 is just insane! To do that, I’ll be taking advantage of css image sprites to reduce the overall requests to around 40. That will really rock the user’s experience on our site!

What are some of the things you’ve done to improve your site’s bottom line? Let us know in the comments!

9 thoughts on “Optimizing Site Performance: Cookieless Domains

  1. I tried to do the same thing, but used a subdomain: static.mysite.com.
    I set up the vhost for http://www.mysite.com so that ServerAlias is *.mysite.com.

    That way I cannot separate the log files, though the cookie thing was partially solved. I say partially, as I still see some cookie stuff being sent over, but a whole lot less.

    Like

    1. The subdomain is definitely the way to go. I was able to separate the log files for static stuff, and, as this accounts for almost 90% of the log data, I can now use Splunk for digging through the “business requests”.

      Like

  2. As our domain was globally covered by cookies, I had to move all the static content to a new one. We had some image uri’s covered in the configuration, but a lot of hard coding was done to embed js and css files. All of these had to be changed to use the new static domain.

    So “environment variable changes” should actually be “application & configuration changes” and I’ve updated the post accordingly!

    Like

  3. I would get a new domain for static components but I am worrying about the traffic from Google Images. What will happen to that? Will Google link directly to that image files without sending traffic to the page?

    Thanks for any help

    Like

  4. If you get a significant amount of traffic from Google Images, you should avoid to push those to a new domain. Goolge considers it as a different source than your main domain.

    The approach is only feasible for static assets like background images, icons, etc – but not for “content” images.

    Like

  5. How many additional subdomains could be set ? My forums load about 35-45 static componant, i wonder which is the best thing to do. Load 50 % of those componants from 1 static domaine, or spread them bettwen 2 or 3 static subdomains.

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.