Another is setting the cookie path attribute differently from the ubiquitous “/” means that the cookie will be resent upstream by the browser for each external file requested, including images, javascript and CSS files that have no use for cookies. Setting your static content in a different folder than your code and NOT specifying path=”/” solves this problem.

Yet another method is setting the cookie’s domain attribute: set your static content to a different subdomain than your code and limit your cookie’s domain to the code’s domain.

One lesson I learned after managing the QoS of a telco web site for several months is that https uses really less connections to connect to the server, and that securing requests takes much longer. If you a have a big cookie (such as and identity cookie, ususally 1024 bytes long), you find yourself creating secure requests for each file you need to download, sending that big cookie over a DSL line (which is usually smaller in bandwidth from the browser to the server), and doing so an inappropriate number of times (because all your cache is down the trash, with https).

The solution? You need to accomodate : use an alternate domain or subdomain or server to serve static files (without cookies), with a cname to have two parallel downloads and good cache directives.

Use frames, if you have a heavy graphic design, and secure only the parts that need it.

Try to keep the number of css and js files to a minimum : each file you download costs you, even before you start getting the response, and the browser WILL NOT RENDER the page unless it has downloaded all css it needs.

I recommended all these actions to the different engineering teams that are in charge of the self-care, store and portal of the company. We saw wonderful successes, withe a 50% decerase in homepage load time, or a 10% decrease of bandwidth use while we had a 20% increase of traffic (page views). It works!