Browser cache
A browser cache is a temporary local storage area on a user's device where a web browser keeps copies of files it has already downloaded, so it doesn't need to fetch them again on the next page load.
What is a browser cache?
Every modern browser (Chrome, Firefox, Safari, Edge) stores copies of files it downloads, HTML documents, CSS stylesheets, JavaScript bundles, images, fonts and other static assets, in a local cache on the visitor's device. Instead of re-downloading every file on each page load, the browser reads them straight from disk or memory, which cuts load time, reduces bandwidth usage and lowers the load on the origin server. The rules that govern what gets stored and for how long come from HTTP headers set by the server.
How browser caching works
When a browser requests a resource, the server response includes caching headers that tell the browser whether, and for how long, it can reuse that file without asking again. The two headers that matter most are Cache-Control and ETag:
- Cache-Control: max-age=31536000 tells the browser to reuse the file for up to a year without contacting the server.
- Cache-Control: no-cache forces the browser to revalidate with the server before using a cached copy.
- ETag is a fingerprint of the file's content; if it hasn't changed, the server replies with a lightweight 304 Not Modified instead of resending the whole file.
A typical response header looks like this:
Cache-Control: public, max-age=604800, immutableCache types and directives
- Private cache: stored only in the visitor's own browser.
- Shared or proxy cache: stored on an intermediary such as a CDN edge server or an ISP proxy, shared across visitors.
- Memory cache: kept in RAM for the current browsing session, cleared when the tab or browser closes.
- Disk cache: persisted on the device's storage across sessions, until it expires or the user clears it.
Common directives include no-store (never cache), must-revalidate, immutable (the file will never change at that URL, typically used with a hashed filename) and stale-while-revalidate (serve the cached copy instantly while fetching a fresh one in the background).
Browser cache vs. CDN cache
| Aspect | Browser cache | CDN cache |
|---|---|---|
| Location | User's device | Edge server |
| Scope | Single visitor | All visitors near that edge |
| Typical TTL | Minutes to 1 year | Minutes to weeks |
| Controlled by | Cache-Control header | CDN configuration and headers |
Best practices and common pitfalls
Use long max-age values with immutable on versioned static assets (files with a hash in their name, like app.3f2a1c.js), since a new deploy simply ships a new filename instead of invalidating a cache. Keep HTML uncached or short-lived (no-cache) so users always get the latest markup. A frequent mistake is caching an HTML page aggressively, which then serves stale content or broken links after a deploy. Another is forgetting to bump a filename or query string after editing a cached CSS or JS file, which leaves visitors on an outdated version until the cache expires.
Cache and Core Web Vitals
An efficient cache policy directly improves Largest Contentful Paint and Time to First Byte on repeat visits, since the browser skips the network round trip entirely for cached assets. Google's own guidance recommends a caching strategy as part of page speed optimisation, which in turn affects Core Web Vitals scores and, indirectly, search ranking signals tied to page experience.
Browser cache at BeBranded
We configure cache headers as part of every website and web app build, balancing fast repeat loads for visitors with the ability to ship updates without waiting on stale assets.