- Keep them targeted – you can specify the URLs that should receive a given cookie. By default, no URL or path is specified and this means that the cookie is transported on every request, even requests for images, script files and other non-business content. That can add up to an enormous waste of time transporting cookie data that no-one needs.
- Prefer session-tracking – all web servers have the ability to track sessions, if you turn on that feature. Even a stateless application can do it. The only difference between tracking sessions and tracking users is the duration of the ID cookie in the user’s browser. A new session ID is handed out on every session the user has with the application (typically by the web server). A user ID is only given out once, typically by the application. If you want to remember preferences for an anonymous user, it doesn’t mean that he has to sign in or register. It just means that you need to set a user ID cookie with a random number or string and associate the user’s preferences with that ID in some centralized location. Using just a session ID and user ID, you can keep all of your bulky information inside your application and off the network.
NOTE: you should never put any targeting on session IDs or user IDs, since that will interfere with effective monitoring of your application.
Don’t introduce needless bottlenecks and overhead through bad cookie practices. Keep them small and targeted at all times. Most importantly, always question whether you truly need them or are just being lazy.