Channels ▼
RSS

Tools

Understanding Client-Side Storage in Web Apps


How Much Data Can You Store?

The APIs also differ in the quantity of data they can store, so even if you are storing strings, your API choice is affected by how much string data you need to store.

As mentioned earlier when we were discussing the limitations of cookies, they can only store up to 4KB each (~4000 ASCII characters), and the specification recommends that browsers support a minimum of 20 per domain and a 300 total. The localStorage quota varies, with some browsers supporting 2MB per domain, some seemingly unlimited, and most averaging around 5MB.

The indexedDB and File API specifications don't yet give recommendations for how much browsers should give to websites, so Chrome is currently experimenting with a unified quota API for those APIs. With their quota system, there are two types of storage — temporary and permanant. Any data in temporary storage can be evicted by the browser whenever it feels the need. Data in permanent storage will only be removed when the website or user requests it. For temporary storage, a website can use up to 20% of the total available temporary storage space, but for any permanent storage, the website must explicitly ask the user for the permission to use that space, and then can request however much space is available.

With all of these APIs, you can never safely assume that you can store everything. It's the user's computer that you're storing data on, not your own server, and it's ultimately up to the users to decide what to do with their hard drive space.

This table summarizes the storage restrictions:

Cookies 4KB each, 20 per domain min
localStorage 2.5-5MB average
IndexedDB Temporary: up to 20% of available space per app. Permanent: Can request up to 100% of available space.
File API See IndedexedDB

How Do You Query Data?

Once you've stored the data, you need a way to get it back out. With most of the APIs — cookies, localStorage, the File API — your "query" is just a key name. It's basic, but if you have well-named keys, that may be enough for you. With IndexedDB, you can create indexes on properties and cursors with key ranges (maxs and mins), and then retrieve the matching objects. You could accomplish that same thing in the other APIs by retrieving all your data and sorting through it in JavaScript, but once you are storing a significant amount of data, you will probably find it more efficient to ask the client to perform the query itself.

This table summarizes the query capabilities:

Cookies Key document.cookie
localStorage Key localStorage.getItem('fish');
IndexedDB Indexes var index = store.index("name"); index.openCursor(IDBKeyRange.bound("A", "B")
File API Filename fs.root.getFile('image.png',
 {}, function(fileEntry) {});

How Well Does It Perform?

For all of these APIs to store data persistently across browser restarts, the browser must write the data to disk and read it from disk — and that makes the performance of these APIs subject to the duration of read/write operations on the hard drive. Besides the read/write overhead for all of them, there are other performance characteristics for each technique.

As mentioned earlier, cookies are added to HTTP requests, so they affect the actual size of HTTP requests over the wire and the subsequent loading time of a webpage. localStorage is a synchronous API, so when your code attempts to set or get an item, it blocks the rest of the code from executing until the operation is done. In addition, if you are using localStorage to store objects by serializing them into JSON strings, your code is slowed down by how long it takes to do in-browser serialization.

The IndexedDB and File APIs are both asynchronous APIs, which makes code more complex, but can also make for a more performant website because the read/write operations aren't blocking the execution of the rest of your code.

In figuring out how performance matters to your particular use case, think about how much data you're planning to store/retrieve, how often you're planning to store and retrieve that data, and how complex that data is.

This table summarizes performance considerations:

Cookies Bigger HTTP requests, Read/writes to disk
localStorage Blocking read/writes, Serialization, Read/writes to disk
IndexedDB Async read/writes, Read/writes to disk
File API Async read/writes, Read/writes to disk

What Browsers Does It Work In?

In an ideal world, you would pick the best API for the job based on just the previous considerations, but since we're dealing with emerging API standards here, you need to seriously consider which browsers support which API, and what browsers you need to support for your website — and ultimately, this may be the only question that matters at this point in time.

The HTML5 storage options have a wide range of browser support, as there's been a lot of disagreement in the standards world about what a client-side storage API should look like. The localStorage API was the simplest and least controversial of the APIs, and so it was the first to be implemented. It's now supported in all "modern browsers," including IE8. The IndexedDB and File APIs are growing in acceptance among browser vendors and I hope to see significantly more support for them over the next year. At the time of writing, however, the IndexedDB is supported only in FireFox 4+ and Chrome 11+. The File API is only supported in Chrome.

Figure 1 summarizes the current support. For the latest, check caniuse.com.


Figure 1.

Which API to Use?

If you're in the rare (quite fortunate) situation of having to develop only for one browser (like making a Chrome extension or an internal tool), you could consider using the File API or IndexedDB API. However, most Web developers are trying to target multiple browsers and given the browser support situation, the only practical cross-platform HTML5 data storage option is the localStorage API.

It certainly has its drawbacks — notably, the blocking synchronous methods and the potentially slow serialization — but as long as you stay aware of those shortcomings when working with it, you can use this simple storage API for improving your websites.

Stay tuned for part 2 of this series, in which I’ll dive deeper into localStorage and present different ways it can enhance your sites. In the meantime, if you want more information on local storage, you can watch and listen to my 30-minute webinar on client-side storage for Dr. Dobb’s on this topic.


Pamela Fox went to USC for her bachelor's & master's in computer science, spent five years at Google helping developers use the Maps and Wave APIs in their apps, and is now working on her own web apps using a mix of Python, JavaScript, and HTML5.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video