Website Performance: Taxonomy of Tips introduced a classification scheme to help us organize the many performance tips found on the Internet. Today’s article introduces the journey-to-the-servercategory by looking at how cookies impact that journey.
Problem #1 – Cookies Are Sent, But Not Used
Here’s a riddle for you: Why should we send cookies to a server if we’re downloading an image? Did you figure it out yet? The riddle is hard because it’s a trick question. The answer is that we shouldn’t. When we’re downloading an image, the server does nothing with the cookies, so why send them?
Would you be surprised to learn that most web pages actually send cookies to the server when downloading images, scripts, stylesheets, and other resources, even though those components don’t use the cookies? When a client requests a component from a specific directory on a specific node, it checks its cookie jar to see if has any cookies for that node/directory combination, any super-domain, or any parent directory. If it does, it sends all those cookies along with the request. Example: Cookies set for b.c.com/w/ also apply to a.b.c.com/w/, b.c.com/w/x, and a.b.c.com/w/x.
Sending cookies that the server doesn’t need usually increases the network traffic between the client and the server, which impacts performance. Even if the cookies are small, when you multiply by the number of components on the web page and multiply again by the number of hits on the server, the impact can be huge. So we’re left with that nagging question, “Why send cookies when they’re not needed?”
Solution #1a – Access Components Via IP Address
This solution will not work if our server uses a dynamic IP address, or if we are sharing our IP address with other domains (e.g., virtual hosting). In these cases, skip to Solution #1b below.
Cookies cannot be created for IP addresses, so accessing components through an IP address instead of a domain name will guarantee that cookies are not sent or received, so the problem goes away.
Example: My domain is acme.com, which resolves to 100.200.300.400. I can change my existing code to download everything that doesn’t require cookies from 100.200.300.400 instead of acme.com. For example, every webpage used to download the page header with ‘<img src=”https://acme.com/img/pgHeader.png/”>’, but I changed that to ‘<img src=”https://100.200.300.400/img/pgHeader.png/”>’. Now cookies aren’t sent when my pages download the header.
Solution #1b – Access Components from a Cookieless Domain
If we’re willing to spring for a few extra bucks, we can buy another domain name. It can point to the same docroot as our “real” domain, but there’s no need to advertise it because it’s not intended for public use. If we never specify the new domain when setting cookies, that domain will remain cookieless. When we want to download an image, script, stylesheet, or other resource that doesn’t use cookies, we can specify our new, cookieless domain name instead.
Example: My domain is acme.com. I buy a new domain named acmecomponents.com. Both domain names resolve to 100.200.300.400, which is my IP address. I can now change my existing code to download everything that doesn’t require cookies from acmecomponents.com instead of acme.com. For example, every webpage used to download the page header with ‘<img src=”https://acme.com/img/pgHeader.png/”>’, but I changed that to ‘<img src=”https://acmecomponents.com/img/pgHeader.png/”>’. Now cookies aren’t sent when my pages download the header.
Of course, putting the new domain and all the cookieless components on another machine will be even better, but that performance improvement is a topic for another day.
Problem #2 – Too Many Cookies are Sent
Similarly, when the user clicks on a link or button, the web page he/she is viewing may send every cookie for every component for every web page in every application on our server. If the upcoming page uses only one cookie, this degrades performance. This happens because the client sends cookies for all the super-domains and parent directories, too.
Solution #2a – Plan the Hierarchies
We need to plan the layout of our cookie hierarchy. Cookies should be stored as low down the hierarchy as possible.
For example, cookies that apply to docroot should contain company-wide data only. There can be one subdirectory of docroot for each webapp. Cookies that apply to those subdirectories would then contain only application-specific data. Within each application’s subdirectory, we can have one sub-sub-directory for each web page. Cookies that apply to those sub-sub-directories would then contain only page-specific data.
Solution #2b – Reduce Our Reliance on Cookies
Perhaps the cookie mechanism isn’t the best choice. Perhaps the data can be stored on the server in session variables, local databases, or some other form of storage.
If we must use cookies, we should always remember to set their expiry dates as early as possible. The only limiting factor is the impact on the user.
Conclusion
Clients often send unneeded cookies to the server. We can reduce both the number and size of those cookies, maybe even eliminating them entirely. IP addresses and cookieless domains can stop the transmission of cookies for components that don’t use them. Planning our cookie hierarchy can limit cookie transmission to only those cookies that are relevant.
References
Best Practices for Speeding Up Your Web Site by Yahoo’s Exceptional Performance Team. Published by Yahoo at developer.yahoo.com/performance/rules.html. Accessed 2012.01.13.
Minimize Request Overhead. Published by Google at https://code.google.com/speed/page-speed/docs/request.html. Accessed 2012.01.21.
Web Performance Best Practices. Published by Google at code.google.com/speed/page-speed/docs/rules_intro.html. Accessed 2012.01.13.
Website Performance: Taxonomy of Tips by Warren Gaebel. Published 2011.12.29 by Paid Monitor at blog.monitor.us/2011/12/website-performance-taxonomy-of-tips. Accessed 2012.01.13.
Try Paid Monitor For Free. A 15-day free trial. Your opportunity to see how easy it is to use the Paid Monitor cloud-based monitoring system. Credit card not required. Accessed 2012.01.13.
The Paid Monitor Exchange at GitHub. This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Paid Monitor system to its full potential. Accessed 2012.01.13.
