Engrain by ByteRush

WEB.13.02 Mid-level· 11 minCore — asked often

Cache layers: memory, disk, service worker, CDN and the back/forward cache

Every cache a request can hit, in order: memory and disk caches, the service worker, the CDN edge and its cache key. Plus versioned URLs vs purging, and the back/forward cache and what blocks it.

Comes up in: Web fundamentals, Frontend system design

Learn#

Dev’s team purges the whole CDN after every deploy, and the origin server struggles for ten minutes each time. Their back button also reloads every page from scratch.

A request can be answered by several caches, in this order:

  1. The back/forward cache, for back and forward navigations: the whole page, frozen in memory.
  2. The service worker, if one controls the page (WEB.06.04).
  3. The browser’s HTTP cache: memory first, then disk.
  4. The CDN edge, a cache server near the user.
  5. The origin server.

Each layer finds entries by a cache key, usually the method and URL. Different keys for the same file, such as ?utm_source=whatsapp, mean misses.

Cache busting with content-hashed file names (app.3f9a.js) means new versions get new keys, so nothing needs purging, and old pages keep working.

Every cache a request can hitStep 1 of 4

Cache

  • service worker: no match

Network

    empty

    The page asks for /assets/logo.svg. First stop: the service worker, if one controls the page.

    Read the steps as text
    1. The page asks for /assets/logo.svg. First stop: the service worker, if one controls the page.
    2. Next, the browser's HTTP cache: memory for this session, then disk.
    3. Then the network: the request reaches the nearest CDN edge, which looks up its cache key.
    4. Only on an edge miss does the request travel to the origin server. Each layer that hits saves everything after it.

    Predict#

    Predict first

    A user presses Back. The previous page was fully stored in the back/forward cache. What happens to its JavaScript state?

    Interview angle#

    Say it like this — about 30 seconds

    “For a back or forward navigation, the bfcache can restore the whole page instantly. Otherwise a request goes to the service worker if one controls the page, then the browser’s memory and disk HTTP cache, then the CDN edge, and finally the origin. CDNs look up a cache key, usually the URL, so I strip tracking parameters. I deploy with content-hashed file names instead of purging. Pages leave the bfcache because of unload handlers, no-store on the HTML, or open connections; I use pagehide instead of unload.”

    Stays on your device. Nothing is uploaded.
    Follow-up What is the back/forward cache, and what prevents a page from using it?
    An in-memory snapshot of the whole page for instant back and forward. Unload listeners (Firefox), Cache-Control: no-store on the HTML, and open IndexedDB connections or in-flight requests can block it.
    Follow-up Walk through all the caches a request can hit.
    bfcache, service worker, memory cache, disk cache, CDN edge (sometimes a regional shield), then the origin.
    Follow-up How do you test bfcache?
    Chrome DevTools, Application, Back/forward cache, Run test; in the field, the NotRestoredReasons API.

    Practice#

    Guided

    Build a CDN cache key that ignores tracking noise, and list what may keep a page out of the bfcache.

    Done when

    • cacheKey drops utm_* and listed parameters, and sorts the rest.
    • bfcacheRisks returns the matching codes in the given order.
    Your solution
    Ctrl/⌘ + Enter

    Remember#

    Try to answer each card before you open it. Then add them to your reviews.

    Which cache can restore a whole page, JavaScript state included?

    The back/forward cache (bfcache).

    Which event should replace unload?

    pagehide.

    Why strip utm_ parameters from a CDN cache key?

    They split one file into many keys, so the cache misses more.

    Why are hashed file names better than purging the CDN?

    New versions get new keys, so nothing needs purging.

    Go deeper

    Four layers. Stop at the one your interview needs; each ends with a quick check.

    The core ideaEvery round
    The service worker sees requests before the HTTP cache; its fetch() calls then go through the HTTP cache. Memory cache entries last only while the tab lives.
    Check yourself: Which comes first for a normal request: service worker or HTTP cache?

    The service worker.

    How it works underneathSenior rounds
    On restore, pageshow fires with event.persisted === true; refresh stale data there. Firefox will not cache pages with unload listeners, and Chrome has deprecated unload .
    Check yourself: What event tells you a page came from the bfcache?

    pageshow with event.persisted === true.

    Edge cases and trapsWhere people slip

    Cache-Control: no-store on the HTML has historically kept pages out of the bfcache; use no-cache for non-sensitive pages. Open IndexedDB connections and in-flight requests can block it too, so close them in pagehide.

    Check yourself: Does Cache-Control: no-store on the HTML affect bfcache?

    Historically it kept pages out; Chrome is working to relax this.

    In productionStaff-level answers

    Normalize CDN cache keys: ignore tracking parameters and sort the rest. Version assets by content hash, keep HTML short-lived, and measure the CDN hit ratio. Cloudflare’s cache rules can change the key .

    Check yourself: Where do you see why a page was not restored?

    The NotRestoredReasons API, or DevTools' Back/forward cache panel.

    Finished the five steps? Mark it, and its cards join your reviews.

    Last checked 2026-11-01. Spot a mistake? Use “Report an error” below — fixes are listed on the corrections page.

    Interview questions this answers

    • What is the back/forward cache and what prevents a page from using it?
    • Walk through all the caches a request can hit.