Data Persistence
🧠 TL;DR — Browsers give you several different ways to store data on a user's machine — cookies, localStorage, IndexedDB, and the HTTP cache — each with different size limits, lifetimes, and use cases.
A page that forgets everything the moment you close the tab isn't very useful. Browsers expose several storage mechanisms so sites can remember things — from login sessions to entire offline datasets.
🍪 Cookies
Cookies are small pieces of data (about 4KB) that are automatically attached to every HTTP request to the domain that set them. That makes them the classic mechanism for session management, but also the most expensive to overuse — every cookie rides along on every request.
document.cookie = "theme=dark; max-age=86400; path=/";
⚠️ Warning: Because cookies travel with every request, storing large amounts of data in them slows down every single network call to your site.
🗄️ localStorage and sessionStorage
Both store simple key-value string data directly in the browser, without ever being sent over the network.
| localStorage | sessionStorage | |
|---|---|---|
| Lifetime | Until explicitly cleared | Until the tab closes |
| Capacity | ~5–10MB | ~5–10MB |
| Shared across tabs? | Yes (same origin) | No, per tab |
| Sent with requests? | No | No |
localStorage.setItem("theme", "dark");
sessionStorage.setItem("draftId", "1234");
📦 IndexedDB
For anything bigger or more structured than key-value strings — offline datasets, cached API responses, files — there's IndexedDB, an asynchronous, transactional database built into the browser.
const request = indexedDB.open("notesDB", 1);
request.onupgradeneeded = (e) => {
e.target.result.createObjectStore("notes", { keyPath: "id" });
};
Unlike localStorage, IndexedDB is asynchronous by design, so large reads and writes don't block the main thread — the same main thread we talked about being precious back in the rendering posts.
⚡ The HTTP cache
Separate from anything JavaScript controls, the browser also maintains an HTTP cache governed by response headers like Cache-Control and ETag. This is what lets a repeat visit skip the network entirely for unchanged assets.
⚡ Tip: A well-configured cache means returning visitors can skip straight to parsing and rendering — no network round trip needed at all.
✅ Key takeaways
Cookies: small, automatic, sent with every request — best for session tokens, not bulk data.
localStorage/sessionStorage: simple key-value storage, synchronous, no network overhead.
IndexedDB: the right tool for structured or large data, and it's async so it won't block rendering.
The HTTP cache works underneath all of this, deciding whether the network is even involved.
With this post, we've now covered all three pillars this series promised: the rendering engine (parsing through compositing), the browser's process architecture, and data persistence — the full inner workings of how browsers work.
#browsers #webstorage #caching #performance