Browser Storage: What Are the Options?

The term I hear most often is “offline storage”, but I want to stress that the use of storage can actually benefit both offline and online.

The idea of offline storage is that when users view a site while they are online, the resources that are required to view that site are stored to the user’s device, so that if they try to view that site while they are offline, they will have all the resources they need.

But this idea can also really benefit online users.  If all of the resources that are required to view a site are already stored to the user’s device, whether they are online or offline, then those resources do not have to be downloaded again (at least for some time).  And while browsers do normally cache files for a certain period, studies have shown that current browser cache sizes are too small to maintain cached resources for long periods of time and previously cached resources are likely to have been replaced by another site’s cached resources before.

Therefore, “offline storage”, can also be used to enhance online experiences.

Now, if only there were a way to reliably store those resources…  Well, there are several options…

  • Cookies
  • AppCache
  • localStorage
  • sessionStorage
  • IndexedDB
  • WebSQL
  • FileSystem API

…but all of these have something about them that sucks…

I’m going to reference HTML5Rocks.com a lot, because some really smart people have already researched and written just everything we need to know about all of this, so we might as well use that knowledge…

Cookies

I add this because it is well-known and is still a solid, viable option for storing some data on client devices.

Pros:

  • Solid browser support.
  • Well-known API.
  • Very simple to use: create key/value pairs and write to browser.
  • Can set expiration date.
  • Persistent across sessions, until either cleared by user or expires.

Cons:

  • Access is restricted to same-domain.
  • Cannot store physical files, only strings of data. (For something like images, you could convert the image to a Data URI and store the result, but see below regarding size constraints.)
  • Inconsistent cross-browser restrictions regarding number of cookies you can store and how much memory they can consume.
  • With each server request, all cookie information for that domain is sent to server.
  • User can block.
  • User can delete stored content.

AppCache

HTML5Rocks describes the process quite well.

Pros:

  • Browser support is pretty good.
  • Very simple API: just put a bunch of resource URLs in a file (called a manifest), reference that file in your HTML, and voila, you have cached files on user devices!
  • You can cache physical files (such as images, audio and video) on the user’s device.
  • Persistent across sessions, until either cleared by user or replaced by developer.

Cons:

  • Access is restricted to same-domain.
  • Requires a minor server setting (to serve the manifest with the proper mime type).
  • Cannot update individual files referenced in the manifest, must update all files referenced in the manifest.
  • Update does not happen with current page load, will happen with next page load. (There is a hack to force updated files into current page load, but it does require a page refresh.)
  • Cannot set expiration date on files.
  • Developers cannot delete a file that AppCache has cached.  To avoid using a file previously cached, you would have to overwrite it with a different file, or change the references to that file to no longer reference it.
  • If loading of the manifest file fails, the entire caching process fails, and the site loads fresh from the web (and if there is no connectivity, the site cannot load).
  • Firefox used to ask the user if it was okay to download files; this is supposed to be going away.
  • Initial storage capacity of 5MB, inconsistent cross-browser results if trying to store beyond that.
  • User can delete stored content.

localStorage

Brief section by HTML5Rocks.

Pros:

  • Very good browser support.
  • Very simple to use, key/value pairs, set/get/delete.
  • Persistent across sessions, until cleared by developer or user.

Cons:

  • Access is restricted to same-domain.
  • Cannot store physical files, only strings of data. (For something like images, you could convert the image to a Data URI and store the result, but see below regarding size constraints.)
  • Because all stored data must be a string, no form of data integrity.
  • Synchronous API.
  • Initial storage capacity of 5MB, inconsistent cross-browser results if trying to store beyond that.
  • User can delete stored content.

sessionStorage

Any resource stored using sessionStorage is deleted with the user closes the browser or browser tab, so I do not consider this a viable option for this discussion, but wanted to mention it for completeness.

IndexedDB

HTML5Rocks, again, has a nice, brief section.

Pros:

  • Fairly simple to use (key/value pairs) but somewhat complex API.
  • Loose data structure, so can store anything, anywhere (so it’s flexible, but dangerous).
  • You can have as many databases as you like, and as many stores within each database.
  • Asynchronous API.
  • Persistent across sessions, until cleared by developer or user.

Cons:

  • Terrible mobile browser support.
  • Fairly simple to use (key/value pairs) but somewhat complex API.
  • Loose data structure, so can store anything, anywhere (so it’s flexible, but dangerous).
  • Only Chrome has support for both database types, and the other browsers are somewhat split on supporting either IndexedDB or WebSQL, so to use one, you have to use both.
  • Initial storage capacity of 5MB, inconsistent cross-browser results if trying to store beyond that.
  • User can delete stored content.

WebSQL

HTML5Rocks, again, has a nice, brief section.

Pros:

  • Good browser support, especially among mobile devices, but see below.
  • Fairly simple to use (key/value pairs) but complex API (based on RDBM).
  • Tight data structure, so good integrity (this means it’s also not very flexible).
  • You can have as many databases as you like, and as many stores within each database.
  • Asynchronous API.
  • Persistent across sessions, until cleared by developer or user.

Cons:

  • Officially deprecated, IE and FF have already stopped supporting, others will surely follow.
  • Fairly simple to use (key/value pairs) but complex API (based on RDBM).
  • Tight data structure, so good integrity (this means it’s also not very flexible).
  • Only Chrome has support for both database types, and the other browsers are somewhat split on supporting either IndexedDB or WebSQL, so to use one, you have to use both.
  • Initial storage capacity of 5MB, inconsistent cross-browser results if trying to store beyond that.
  • User can delete stored content.

FileSystem API

This is the closest thing to what we, the developers, want, and yet it is currently the farthest thing from reality

Pros:

  • Can store physical files, like images, audio, video, PDF, etc.
  • Asynchronous API.
  • Persistent across sessions, until cleared by developer or user.
  • Relative URLs will map to FileSystem URLs in browser.

Cons:

  • Early implementation, in Chrome only, no standards yet.
  • Access is restricted to same-domain.
  • Initial storage capacity of 5MB, inconsistent cross-browser results if trying to store beyond that.
  • User can easily delete stored content.

Conclusion

Until the FileSystem API gains enough support, localStorage is the most reliable option that I think we have. With localStorage, we can easily stringify and store site JS and CSS, saving users quite a bit download the next time they visit.

In addition, AppCache could also serve a purpose of storing files, such as logos, favicon or other semi-permanent files that might not need to be updated until the next visit.

Additional Resources

Advertisements

2 responses to “Browser Storage: What Are the Options?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s