Part 7 · 2 chapters · ~25 min

Application

Every storage tier as a tree (Local and Session, IndexedDB, Cookies with rejections living in Network, Cache Storage, the quota overview), symptoms mapped to tiers, the service worker view with its lifecycle and development checkboxes, the back/forward cache test, background services recorded with DevTools closed, the manifest and the Frames view.

20

Storage, tier by tier

the tree
  1. Local and Session storage: key-value tables per origin, editable; strings only (an object is its JSON); Session is per tab. A 4 MB row here is a 4 MB synchronous read wherever the page reads it.
  2. IndexedDB: databases with versions, stores with key paths and paged records, indexes; values are structured (Dates and typed arrays appear as themselves). A database the page cannot open (version mismatch, blocked upgrade) is listed with its version; "Delete database" is the reset.
  3. Cookies: per domain with every attribute (HttpOnly, Secure, SameSite, Partition key, Priority). Rejected cookies never appear here; the Network → request → Cookies tab shows them with the reason (SameSite=None without Secure, domain mismatch, third-party blocking). "Show only blocked cookies" filters to those.
  4. Cache Storage: the service worker's named caches as request → response pairs with headers and previews; delete an entry to test the miss path. The HTTP cache has no tree: only the Network panel's Size column.
  5. Storage overview: usage per mechanism against the origin's quota (navigator.storage.estimate() agrees), "Simulate custom storage quota" to reproduce QuotaExceededError, and "Clear site data" with per-mechanism checkboxes including unregistering service workers.
symptom → tier
  1. "Forgot my settings": the Local storage row is missing, or the origin changed (www versus apex are different origins with different storage).
  2. "Login lost on return": the cookie expired or was rejected (Network Cookies tab).
  3. "Offline shows a blank page": Cache Storage lacks the shell; the SW's install step failed.
  4. "Stale data forever": IndexedDB holds an old schema, or a cache has no eviction policy.
  5. "QuotaExceededError": the overview bar, and whether the transaction aborted cleanly.
go to the lab
  1. /storage/localstorage-cost: write 4 MB, find the row in Local storage, then record the read in Performance and find the synchronous block.
  2. /storage/idb-await-trap: run the fixed version, then open IndexedDB → lab-trap → s and read the two records as structured values.
  3. /storage/cookie-matrix: set the cookies, read Application → Cookies (two present, None rejected), then Network → the fetch → Cookies tab for the rejection reason.
  4. /storage/quota: simulate a 10 MB quota, write until it fails, read the overview bar and the console error, then Clear site data.
THE APPLICATION PANEL: STORAGE
every tier the Browser course named, inspectable and editable
swipe the figure sideways, or tap expand for full screen
1/6
Local, Session
Local and Session storage: a table of key and value per origin; double-click to edit; a filter box; values are strings (an object you stored is its JSON). The lab's 4 MB value sits here as one row. Session storage shows per tab. Changes made by the page appear live.
21

Service workers, bfcache and background services

the service worker view
  1. Per registration: source, status (#N activated and is running), the lifecycle with a skipWaiting link on a waiting worker; Update (fetch and byte-compare the script), Unregister, Push, Sync, Periodic sync test triggers; checkboxes: Offline (every request fails unless the SW answers), Update on reload (install and activate a new worker every reload: development only, and off when testing waiting), Bypass for network (the app without its SW).
  2. The lifecycle on screen: change one byte, Update: a new worker sits in waiting while the old one controls the page; its install ran (console output in the worker context); skipWaiting activates it and the page sees controllerchange. The Browser course part 7 has the states; this is where you watch them.
  3. Offline finds half-served apps: a fetch handler that serves the shell but not the API loads and then errors; one that caches an error response is worse. Check response.ok before caching.
bfcache, background services, frames
  1. Test back/forward cache: navigates away and back and lists every blocker with a doc link: an unload listener (use pagehide), Cache-Control: no-store on the document (a product decision), an open WebSocket or IndexedDB transaction at navigation (close on pagehide), a BroadcastChannel with a listener, an in-flight fetch with a body. Fix one, test again.
  2. Background services: Push messaging, Background sync, Notifications, Background fetch, Periodic sync, Reporting API: a record button logs events for up to three days including with DevTools closed and the page gone. The only way to see what a push did at 3 am.
  3. Manifest: installability criteria (icons, start_url, display) checked rather than guessed; the install prompt's state.
  4. Frames: the document and every iframe with origin, security state, cross-origin isolation, and the APIs removed by sandbox, Permissions-Policy or isolation. "Why is this API missing in the iframe" is answered here.
go to the lab
  1. /js/sw-lifecycle: register; change VERSION in public/sw.js and rebuild (or click Update after editing the served file); watch #2 in waiting; click skipWaiting; read controllerchange in the lab's log. Tick Offline and reload: the page still loads (the SW passes through; nothing is cached), so the Network panel shows failures: that is a pass-through handler's honest behaviour.
  2. /nav/bfcache: run the test with the unload listener on: read the blocker; untick it; test again: restored. Then open the no-store variant and test: the document-level blocker.
  3. /security/isolation: open the COOP+COEP variant and read the Frames view: cross-origin isolated ✓, and the font request blocked under COEP.
SERVICE WORKERS, BFCACHE AND BACKGROUND SERVICES
the lifecycle made visible, the back/forward cache test, and the events that fire with the page closed
swipe the figure sideways, or tap expand for full screen
1/6
the SW view
Service Workers: per registration, the source file, the status (#N activated and is running / stopped), the lifecycle: installing, waiting (with a "skipWaiting" link), active; buttons: Update (fetch the script and compare bytes), Unregister, Push (deliver a test push), Sync and Periodic sync (fire the events), and checkboxes: Offline (fail every request: the fetch handler must answer), Update on reload (install and activate a new worker on every reload, for development), Bypass for network (skip the SW).