top of page

How We Store Data on Clients (Browser)

Written by Vlad Antsitovich, Software Engineer


Modern storage makes it possible to store more than just small chunks of data on a user’s device. We can keep data for long-term storage, save sites or documents for offline use, retain user-specific settings for sites, and more. This article explains the very basics of how these work.


Caching and storage can improve performance, reliability and user experience (UX).


Storing a large amount of data on a client is easy to do. Unless you’re trying to store several gigabytes of data, modern browsers are equipped to save a large amount of information, but you need to know the limitations of each browser.


Storage is not just about files and assets, but it can include other types of data. You can manage all device storage with the Storage Manager API on supported platforms.


Types of Browser Storage


Cookies


Cookies are very tiny data stored in your browser, that can save up to 4 KB and it’s the only storage that sent with every HTTP request by the browser from that domain. Cookies are mainly used for session management.


There are 2 ways to create cookies: JavaScript and Web server.


Cookies have scope: Domain and Path


And there are 2 types of cookies:

  1. Session cookies — They are deleted when the client shuts down. Web browsers may use session restoring, which makes most session cookies permanent so that it’s as though the browser never closed.

  2. Permanent cookies — Instead of expiring when the client closes, permanent cookies expire at a specific date (Expires) or after a specific time period (Max-Age).

NOTE: Cookies should never be used for data storage, but they are a great way to share the client state with the server and are mostly used for Cookie-based authentication.




Web Storage API


Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies. It is less useful for storing larger amounts of structured data.


It defines 2 storage mechanisms that are very important: Session Storage and Local Storage, which are a part of the set of storage options available on the Web Platform.


LocalStorage is true to the name – it’s local storage for your browsers, and it can save up to 10MB but only for client side reading.

  • As developers, we should avoid using localStorage because it’s synchronous, causes performance issues, and should not be used to store any security or sensitive data in it.

  • Sensitive data includes: User IDs, Session IDs, JWTs, Personal information, Credit card information, API keys.

SessionStorage works similarly to LocalStorage, but as the name suggests, it’s session based and will be deleted once the browser is closed.



Web SQL Database


Oh, forget about this.


The Web SQL database specification has been deprecated since November 2010.


Read more: Web SQL Database


IndexedDB


IndexedDB is a non-relational database based on events. It works asynchronously through transactions and is good for storing all kinds of data, like: JS objects, files, blobs, etc.


However, IndexedDB works best when storing structured data. This includes data that needs to be searchable or combinable in a NoSQL-like manner, or other data that doesn’t necessarily match a URL request such as user-specific data. Note that IndexedDB isn’t designed for full-text search.



Cache Storage API


CacheStorage API is a powerful tool. We can cache static app resources, like HTML, CSS, and JavaScript, and it allows us to ensure that they’re always instantly available.


You can use the Cache Storage API to download, store, delete or update assets on a device. Then, these assets can be served on the device without requiring a network request.


Use the Cache Storage API for network resources, which are things you’d access by requesting them via a URL such as HTML, CSS, JavaScript, images, videos, and audio.


More about Caching in PWA


Summary


IndexedDB and CacheStorage are supported in every modern browser. They’re both asynchronous and will not block the main thread. They’re accessible from the window object, web workers and service workers.


Using CacheStorage API and IndexedDB lets you effectively store all the resources that an app needs to run. For offline storage, use the Cache API. For storing application state and user-generated content, use IndexedDB.


BUT if you want to create pages with a shareable state (a page that you can share with others) such as a search page, use theURL’s query string to store this information.


Sources


bottom of page