Is writing a cookie very slow in JS?

Question

I need to make my website faster on the client side. I wonder if my excessive Javascript cookie manipulation could slow down the browser. It uses the harddrive, which is the slowest component of a computer. On a severely fragmented harddrive, could cookie manipulation freeze the browser?

Is JS doing any optimizations for cookie writing/reading (caching, etc..). Could I exploit these optimizations to improve my site?

Replacing client-side cookies with a server side database is out of the question because my servers are overloaded already.

Answer 1

There are a few ways you can speed up your page on the client side, although I'm guessing reducing cookie use would only save a few microseconds at best. Just in general make sure you are only saving what you need.

There are tons of other optimizations that you can do though, such as:

• Serving your files as gzipped content
• Ensuring as much of your site is cache-able
• Using CSS sprites and combing javascript + css files to reduce HTTP requests (will reduce load from your server too)
• Minifying your javascript, css and html

These are all proven methods of reducing page load times.

For more information on how to make your page load faster, get the YSlow! plugin for firefox / firebug http://developer.yahoo.com/yslow/

Answer 2

+1 for a good question, albeit one with scary implications.

Anything done to excess can potentially have a performance impact, though this one will be marginal in almost any case. I am not aware of any optimizations done by JavaScript for reading/writing cookies, but the read/write caches of most disk controllers should smooth out this i/o to the point of negligence.

Why is it scary?

1. Cookies may have size/quantity limits: http://support.microsoft.com/kb/306070 and http://en.wikipedia.org/wiki/HTTP_cookie

2. Cookies can be manipulated, so they aren't secure (unless you are strongly encrypting the values in them, which of course impacts performance, and is still a bad idea).

3. Cookies are sometimes disabled.

You mentioned that your database is slow, but adding a few session variables won't place any additional load on your database. Or try to manipulate client-side data in memory, or even pass a few variables (non-secure information, of course) around on the query string.

Answer 3

cookies are part of the request and response headers, so loading them up means loading up every request and response. Secondly, you are limited to a total of 50 cookies per domain, and 4k per cookie. Thirdly, many users are absolutely terrified of cookies, and tend to delete them even if they are harmless.

Because of those 3 reasons, web developers very rarely use them unless absolutely necessary (i.e. session tokens). Because web developers very rarely use them, there are few "best practices" around them, and they tend not to get much attention.

I would make sure it is actually interacting with the cookies that is the problem before addressing it. The implementation is browser specific, so you will probably see very different results of those tests depending on what browser you try it on.

Answer 4

Cookie manipulation itself would not be performance intensive. However, cookies will get tagged along some or all of your HTTP requests (both up and down) based on the path and domain settings of your cookies. If you have a kilobyte of cookie and are making 10 requests per page, you are essentially increasing the request and response payload by 10kb each.

See ServeFromCookielessDomain for more detail.