4 Client-Side Web Storage Options That Replace Cookies

Several standards exist for storing large amounts of data in a user's Web browser. Each has its benefits, tradeoffs, W3C standardization status and level of browser support. All are better than cookies.

By Chris Minnick and Ed Tittel
Tue, September 03, 2013

CIO — Today's Web applications handle large amounts of data processing on the client side. They may even need to be able to operate offline. These demands things go a long way toward explaining why client-side data storage is vital to next-generation Web-based applications.

Until recently, however, cookies were pretty much the only way to store data in a user's browser. If a Web app needed repeated access to some bit of data, it needed to ship that data to the server, then make repeated requests to the server, or store that data in cookies.

Cookies offer only limited storage space — a maximum of 4K or 4096 bytes — so large amounts of data had to be broken into cookie-size chunks and managed explicitly and directly.

This isn't a workable approach to storage allocation and management. Obviously, a new approach was needed.

It Doesn't Take Much for Cookies to Crumble

Web browsers were originally nothing more than applications for loading documents via HTTP and parsing HTML. Shortly after the first Netscape browser appeared, however, it became obvious that much more was both possible and necessary, but that some mechanism for tracking state using the inherently stateless HTTP protocol would be needed. Lou Montulli thus implemented the browser cookie (also known as the "magic cookie") in 1994, for version 0.9b of the Mosiac Netscape browser.

Cookies, along with access to server-side scripts that the Common Gateway Interface (CGI) provided, enabled the earliest Web applications. Ultimately, this started us down a path toward browsers transforming into a universal application platform.

Alas, cookies are flawed. As noted, they can store only very small amounts of data, and they're vulnerable to numerous types of attack, which limits their usefulness for storing personal or sensitive data.

Cookies travel from the browser to the server with every HTTP request. Say a Web page contains four images, an external CSS document and a JavaScript document. Set a 4K cookie on that domain and the browser transfers that cookie to the server once for the HTML page, once for each image, once for the CSS document and once for the JavaScript document.

Further compounding the problem is the observation that this theoretical 4K cookie is transferred from the browser to the server; most users have asynchronous Internet connections, whereupon upload speeds are slower than download speeds. Inevitably, transferring cookie data inside HTTP headers creates unnecessary overhead.

Because of these limitations, most cookies are significantly smaller than 4K in size. Google recommends that cookies occupy no more than 400 bytes (or 200 characters) to maximize performance. They also recommend that static files such as images, CSS, and JavaScript come from a distinct domain with cookies disabled.

Continue Reading

Our Commenting Policies