Introduction
A browser should not have to download the same file every time someone visits your website. Browser caching and Cache-Control help websites reuse previously downloaded resources instead of requesting every file again on each visit. With suitable cache headers, browsers can store images, stylesheets, JavaScript, fonts, and other eligible resources for an appropriate period, reducing repeat downloads and improving loading efficiency. The right configuration depends on how frequently a resource changes, whether it contains personalized information, and how the website handles versioning and updates.
If a visitor downloads your logo, CSS file, JavaScript bundle, font, or other static asset today, the browser may be able to reuse that resource on a later visit instead of requesting it again.
That is the basic idea behind browser caching.
The difficult part is deciding how long the browser should keep a resource, when it should check for a newer version, and what should happen when cached content becomes stale.
This is where the Cache-Control HTTP response header becomes important.
Used correctly, browser caching can reduce repeat-downloads, improve repeat-visit performance, reduce network traffic, and take pressure off your server.
Used incorrectly, it can leave visitors with stale files—or cause browsers to revalidate resources unnecessarily.
This guide explains the practical side of browser caching and Cache-Control, including the directives that matter most and how to troubleshoot caching behavior.
Quick Answer
Browser caching allows a browser to store resources locally and reuse them for later requests.
The server controls much of this behavior through HTTP caching headers, especially:
Cache-Control: max-age=31536000, immutable
For static assets that are versioned when they change, a long cache lifetime can be appropriate.
For HTML documents, a shorter lifetime or revalidation strategy is often more suitable because HTML is more likely to change.
A practical approach is:
- Cache versioned static assets for a long time.
- Use content hashing or another reliable versioning system when assets change.
- Give HTML a different caching policy from static assets.
- Avoid unnecessarily caching personalized or private responses.
- Use ETag or Last-Modified when revalidation is useful.
- Inspect actual response headers rather than trusting a performance plugin’s settings.
- Test both first visits and repeat visits.
- Remember that browser caching is different from CDN or server-side caching.
What Is Browser Caching?
Browser caching is the process of storing HTTP resources locally so they can potentially be reused later.
A browser may cache resources such as:
- HTML
- CSS
- JavaScript
- images
- fonts
- videos
- JSON responses
- other HTTP resources
Suppose someone visits a website for the first time.
The browser requests:
style.css
app.js
logo.webp
font.woff2
The server responds with those resources and caching instructions.
On a later visit, the browser may already have some of them stored.
If the cached response is still considered fresh, the browser may use it without downloading the resource again.
That can make repeat visits considerably faster.
Why Browser Caching Matters for Website Performance
Caching does not magically make the first visit faster.
The browser has nothing cached on a user’s first visit.
Its biggest advantage is that it can reduce unnecessary network activity on subsequent requests.
That can mean:
- fewer bytes downloaded
- fewer network requests
- faster repeat page loads
- lower bandwidth consumption
- less work for servers and CDNs
- better perceived performance for returning visitors
Caching can also indirectly help performance metrics.
For example, if critical CSS, JavaScript, fonts, or images are already cached, subsequent page loads may have fewer resources competing for network bandwidth.
However, caching should not be treated as a guaranteed Core Web Vitals fix.
A first-time visitor may still experience the full loading path.
Browser Cache vs Server Cache vs CDN Cache
These are often confused.
Browser cache
The resource is stored on the user’s device by the browser.
The website does not need to send the resource again when the browser can reuse a fresh cached copy.
Server-side cache
A server may store generated results so it doesn’t have to perform the same expensive work for every request.
For example, a CMS might cache a generated HTML page.
CDN cache
A CDN can store resources closer to visitors at edge locations.
Instead of every request reaching the origin server, the CDN may serve a cached response.
These caching layers can work together.
A visitor might receive an HTML document from a CDN, while their browser separately reuses a cached stylesheet from a previous visit.
Understanding which cache is responsible is important when troubleshooting.
What Is Cache-Control?
Cache-Control is an HTTP response header that tells caches how a response may be stored and reused.
A response might contain:
Cache-Control: max-age=86400
This tells a browser or other cache that the response can generally be considered fresh for 86,400 seconds—one day.
Another example:
Cache-Control: public, max-age=31536000, immutable
This allows shared caches to store the response and gives it a one-year freshness lifetime, with immutable indicating that the representation is not expected to change while fresh.
The correct header depends on the resource.
There is no single Cache-Control value that should be copied onto every response.
Understanding max-age
max-age specifies how long a response can be considered fresh, in seconds.
For example:
Cache-Control: max-age=3600
means the response can be considered fresh for up to one hour.
Some common values are:
| Duration | Seconds |
| 1 minute | 60 |
| 1 hour | 3,600 |
| 1 day | 86,400 |
| 1 week | 604,800 |
| 1 month* | 2,592,000 |
| 1 year | 31,536,000 |
*Using 30 days as a practical approximation.
A long max-age is particularly useful for resources whose URLs change whenever their contents change.
Why Static Assets Can Use Long Cache Lifetimes
Consider:
/app.83f92c.js
The filename contains a version or content hash.
When the JavaScript changes, the build system produces another filename:
/app.1a72cd.js
The browser can safely cache the old file for a long time because the new version has a different URL.
This is called cache busting through asset versioning.
It is one of the most useful techniques for combining aggressive caching with reliable updates.
Cache Busting Explained
Imagine your website uses:
style.css
A visitor caches it for a year.
You then change the CSS.
The visitor’s browser may continue using the cached version because the URL hasn’t changed and the response is still considered fresh.
That can create a stale-site problem.
Instead, the build system can produce:
style.a83d91.css
When the CSS changes, the URL changes too:
style.b51e24.css
The browser sees a new URL and downloads the new resource.
The old cached file can remain stored without affecting the new page.
This is why long browser cache lifetimes work particularly well with hashed or versioned assets.
What Does immutable Mean?
The immutable directive tells caches that the representation is not expected to change while it is fresh.
For example:
Cache-Control: public, max-age=31536000, immutable
This can be useful for fingerprinted assets whose URL changes whenever the content changes.
It is not appropriate for every resource.
You should not casually add immutable to HTML or other frequently changing responses.
The directive works best when your URL versioning strategy is reliable.
What Does public Mean?
public indicates that a response may be stored by shared caches, even in situations where other caching rules might otherwise restrict shared caching.
For genuinely public static assets, a header such as:
Cache-Control: public, max-age=31536000
can be appropriate.
But don’t assume every response is public.
Personalized pages, account information, and private user-specific data require a different caching strategy.
What Does private Mean?
private indicates that a response is intended for a private cache, such as a user’s browser, rather than a shared cache.
For example:
Cache-Control: private, max-age=300
might be appropriate for certain user-specific responses.
Whether a response should be private depends on the data and application behavior.
The important principle is:
Never allow shared caching of content that could expose one user’s personalized response to another user.
What Does no-cache Actually Mean?
no-cache is frequently misunderstood.
It does not simply mean:
“Do not cache this.”
Instead, it generally means that a cached response must be revalidated with the origin before being reused when the directive applies.
For example:
Cache-Control: no-cache
allows storage but requires validation before reuse.
This is different from:
Cache-Control: no-store
no-cache vs no-store
| Directive | Basic idea |
| no-cache | May store, but must revalidate before reuse |
| no-store | Do not store the response |
This distinction is important.
Using no-store everywhere eliminates useful caching.
Using no-cache everywhere may still result in frequent validation requests.
Choose the behavior you actually need.
What Does no-store Do?
no-store tells caches not to store the response.
For example:
Cache-Control: no-store
This may be appropriate for particularly sensitive responses where storage is undesirable.
It should not be added indiscriminately to every page.
If a public static stylesheet is marked no-store, the browser loses an obvious opportunity to reuse it.
What Is must-revalidate?
must-revalidate tells a cache that once a response becomes stale, it must follow the specified revalidation rules rather than simply serving the stale response when those rules would otherwise permit stale reuse.
For example:
Cache-Control: max-age=3600, must-revalidate
This can be useful when serving stale content is not acceptable.
It is another directive that should be used because the application needs its behavior—not because a performance checklist says every response should have it.
What Is s-maxage?
s-maxage applies specifically to shared caches.
For example:
Cache-Control: public, max-age=300, s-maxage=3600
This can allow a shared cache to treat the response as fresh for one hour while the browser uses a five-minute freshness lifetime.
This can be useful when CDN behavior needs to differ from browser behavior.
It is more relevant to websites with a CDN or other shared caching infrastructure than to simple static sites.
Browser Cache Headers for Different Resource Types
A practical caching strategy usually distinguishes between resource types.
Versioned CSS
For example:
Cache-Control: public, max-age=31536000, immutable
Suitable when the URL is reliably versioned.
Versioned JavaScript
Similarly:
Cache-Control: public, max-age=31536000, immutable
can work well for fingerprinted assets.
Fonts
Fonts that are versioned and rarely changed can also use long cache lifetimes:
Cache-Control: public, max-age=31536000, immutable
Images
Static images can often have relatively long cache lifetimes, particularly when filenames or URLs are versioned.
HTML
HTML often needs a more cautious strategy because it can change frequently.
A site might use:
Cache-Control: no-cache
or a short freshness lifetime depending on how the application handles updates.
There is no universal HTML caching value.
Cache-Control and HTML
HTML deserves special attention.
Suppose the homepage contains:
- new articles
- updated navigation
- changing promotions
- personalized information
If the browser keeps an old HTML document fresh for a long time, visitors may not immediately receive those changes.
Static assets are easier to cache aggressively because their URLs can change when their contents change.
HTML often acts as the document that points to the latest asset versions.
That makes a sensible HTML caching policy an important part of the overall strategy.
ETag and Browser Caching
ETag is another HTTP caching mechanism.
A server can return something like:
ETag: “abc123”
The browser can later use that identifier when validating its cached copy.
If the resource hasn’t changed, the server can respond with:
304 Not Modified
The browser can then reuse its cached representation instead of downloading the full response again.
This is called revalidation.
It is useful when a resource changes occasionally but you still want the browser to validate its cached copy.
Last-Modified
Another validation mechanism is:
Last-Modified: Wed, 07 Oct 2026 08:00:00 GMT
The browser can later send a conditional request asking whether the resource has changed since that time.
If it hasn’t, the server can return 304 Not Modified.
ETag and Last-Modified can be used as validators for cached responses.
You don’t necessarily need to manually configure them. Your web server, framework, CDN, or hosting platform may already generate them.
What Happens When a Cached Resource Expires?
A simplified lifecycle looks like this:
Fresh response
The browser has a cached resource whose freshness lifetime has not expired.
It may reuse the cached response without contacting the server.
Stale response
The freshness lifetime has expired.
The browser may need to revalidate the resource before using it.
Revalidation
The browser sends a conditional request using information such as an ETag or modification date.
If the resource hasn’t changed, the server can return:
304 Not Modified
The browser can continue using its cached copy.
If it has changed, the server sends the new resource.
This is one reason caching does not simply mean “download once and never check again.”
Fresh vs Stale Is an Important Distinction
A cached resource can exist on a user’s device while still being considered stale.
That distinction matters when troubleshooting.
Seeing a resource in the browser cache does not necessarily mean the browser will reuse it without contacting the server.
The browser considers:
- freshness lifetime
- validation requirements
- request and response directives
- cache behavior
- resource URL
- other HTTP caching rules
Caching is governed by the HTTP protocol, not simply by whether a file happens to exist somewhere on disk.
How to Check Cache-Control Headers
You can inspect caching behavior directly in Chrome.
Open:
DevTools → Network
Then:
- Reload the page.
- Select a CSS, JavaScript, image, or font request.
- Open the Headers section.
- Find Response Headers.
- Look for Cache-Control.
- Check ETag, Last-Modified, and related headers.
- Inspect whether the request was served from memory cache, disk cache, or the network.
This is much more reliable than assuming your website’s caching configuration is correct because a plugin says “browser caching enabled.”
Test a Real Resource
Don’t inspect only the homepage HTML.
Check several important resource types:
- CSS
- JavaScript
- images
- fonts
- HTML
- API responses where relevant
You may discover that CSS has a one-year cache lifetime while HTML has a completely different policy.
That is normal.
Different resources often need different caching strategies.
How to Check Cache Headers From the Command Line
Developers can also inspect headers using tools such as curl.
For example:
curl -I https://example.com/style.css
A response might contain:
HTTP/2 200
cache-control: public, max-age=31536000, immutable
etag: “abc123”
This gives you the server’s actual response headers rather than the settings you believe the server is using.
For a real website, replace the example URL with the exact resource you want to investigate.
Browser Caching and Core Web Vitals
Browser caching can improve performance, but it should be understood in context.
LCP
Cached resources can reduce the amount of work required on repeat visits.
However, LCP for a first-time visitor still depends on the initial delivery path.
If your LCP is poor because the server responds slowly or the LCP resource is discovered late, browser caching may not solve the underlying problem.
INP
Browser caching can reduce resource downloads, but INP is primarily concerned with interaction responsiveness.
If poor INP comes from long JavaScript tasks or expensive event handlers, changing cache lifetimes won’t directly fix the problem.
CLS
Caching generally does not directly fix layout instability.
If an image has no dimensions or an ad changes the layout, giving the resource a longer cache lifetime does not solve the underlying CLS issue.
Caching and Core Web Vitals are connected, but they address different parts of the performance problem.
Browser Caching vs Cache-Control in PageSpeed Insights
Performance tools may recommend improving browser caching when static resources have short cache lifetimes.
Treat that recommendation as a clue rather than a command to set every resource to one year.
Ask:
- Does the resource change?
- Is its URL versioned?
- Is it public?
- Can stale content cause problems?
- Is it personalized?
- Does the resource need revalidation?
- Is the browser actually requesting it frequently?
The correct caching policy comes from the resource’s behavior.
Common Browser Caching Mistakes
Mistake 1: Giving everything a one-year cache
Long caching is excellent for immutable, versioned assets.
It can be problematic for frequently changing resources.
Mistake 2: Using no-store everywhere
This prevents useful storage and can force repeated downloads.
Mistake 3: Confusing no-cache with no-store
They are not equivalent.
no-cache generally permits storage but requires revalidation before reuse.
no-store tells caches not to store the response.
Mistake 4: Long caching without cache busting
If a CSS or JavaScript URL never changes, visitors can retain an old version for a long time.
Mistake 5: Changing headers but not testing the browser
Server configuration can look correct while another layer changes the response.
Always inspect the actual response.
Mistake 6: Forgetting CDNs and reverse proxies
The browser may not be the only cache involved.
A CDN can have its own caching behavior.
Mistake 7: Caching personalized content publicly
This can create serious privacy and correctness problems.
Caching policy must respect whether content is public or user-specific.
Browser Caching on WordPress
WordPress sites often rely on a combination of:
- web server configuration
- caching plugins
- CDN settings
- theme-generated assets
- plugin assets
- hosting-level caching
This creates several places where caching rules can be defined.
A plugin may recommend browser caching, while the CDN or server already sets the headers.
Adding another caching layer without understanding the existing configuration can make troubleshooting harder.
For WordPress, start by inspecting the actual response headers.
Then determine where those headers originate.
Do not assume the plugin that contains the caching checkbox is necessarily responsible for the final behavior.
How to Set Browser Cache Headers
The exact implementation depends on your server or hosting platform.
Common places include:
- Apache configuration
- Nginx configuration
- application/framework configuration
- CDN settings
- hosting control panels
The principle remains the same:
Set the HTTP response headers according to the resource’s caching requirements.
For example, an Nginx configuration might contain rules that assign long caching periods to static assets.
An Apache setup might use mod_headers or related configuration.
The syntax differs between environments, so don’t copy configuration intended for one server into another without checking how that server handles HTTP caching.
A Practical Cache-Control Strategy
For a typical website, a sensible starting architecture might look like this:
| Resource | Typical strategy |
| Versioned CSS | Long-lived cache |
| Versioned JavaScript | Long-lived cache |
| Versioned fonts | Long-lived cache |
| Versioned images | Long-lived cache |
| HTML | Shorter lifetime or revalidation |
| Personalized responses | Private or otherwise restricted |
| Sensitive responses | Often no-store, depending on requirements |
| Frequently changing API data | Short cache or revalidation |
These are patterns, not universal rules.
The application’s update behavior should determine the final policy.
How to Improve Browser Caching
If your website has poor caching behavior, use this process.
Step 1: Inventory important resources
Identify:
- CSS
- JavaScript
- images
- fonts
- HTML
- APIs
Step 2: Inspect the actual headers
Look for:
- Cache-Control
- ETag
- Last-Modified
- Expires
- other relevant caching headers
Step 3: Separate static from dynamic content
Static assets are usually easier to cache aggressively.
Dynamic and personalized responses need more careful policies.
Step 4: Add reliable asset versioning
Use hashed filenames or another cache-busting mechanism for assets that change.
Step 5: Increase cache lifetimes where appropriate
Longer caching is particularly useful for assets that are immutable once published.
Step 6: Test updates
Change a CSS or JavaScript asset and verify that users receive the new version.
A caching strategy isn’t successful if it makes updates unreliable.
Step 7: Test repeat visits
Clear the cache and measure a first visit.
Then repeat the visit without clearing it.
The behavior should make sense for the caching strategy you configured.
A Simple Mental Model
When thinking about browser caching, ask four questions:
Can this response be cached?
How long can it remain fresh?
What happens when it becomes stale?
How does the browser know that a new version exists?
Those four questions explain most practical caching decisions.
For a versioned JavaScript file, the answer might be:
Yes. Keep it for a long time. It doesn’t need to be revalidated while fresh. If the file changes, its URL changes.
For HTML, the answer might be:
It can be cached, but changes need to become visible relatively quickly, so use a shorter freshness period or revalidation.
For personalized account information:
It should not be treated like a publicly cacheable static asset.
This mental model is more useful than memorizing a single “best” cache header.
Browser Caching Checklist
Static assets
- CSS has an appropriate cache lifetime.
- JavaScript has an appropriate cache lifetime.
- Fonts are cached appropriately.
- Images are cached appropriately.
- Static assets use reliable versioning when long caching is enabled.
HTML
- HTML has a caching policy appropriate for how frequently it changes.
- Updates become visible within the expected timeframe.
- HTML is not accidentally cached for an excessive period.
Headers
- Cache-Control has been inspected.
- ETag or Last-Modified is available where useful.
- no-cache and no-store are being used for their intended purposes.
- Public and private responses are correctly distinguished.
Infrastructure
- Browser cache behavior has been tested.
- CDN caching has been checked separately.
- Server-side caching has been checked separately.
- Caching plugins are not conflicting.
- Production response headers have been verified.
Testing
- First visit tested.
- Repeat visit tested.
- Updated assets tested.
- Mobile behavior tested where relevant.
- Important resources inspected individually.
Final Verdict
Browser caching is one of the simplest ways to avoid repeatedly downloading resources that haven’t changed.
But good caching isn’t about assigning the longest possible expiration time to everything.
The better strategy is to match the cache policy to the resource.
Versioned static assets can usually be cached aggressively. Frequently changing documents need more careful handling. Personalized content requires additional protection.
Cache-Control gives you the controls to make those distinctions.
If you’re troubleshooting browser caching, don’t start by copying a header from another website.
Inspect the actual response.
Identify what the resource is.
Determine how often it changes.
Decide what should happen when it becomes stale.
Then choose the caching policy that fits.
That approach gives you a cache that is not only fast, but predictable.
Related Guides
- Website Speed Optimization Checklist
- What Is TTFB? Time to First Byte Explained
- How TTFB Affects LCP
- Lighthouse vs CrUX: Lab Data vs Real-World Data
- How to Eliminate Render-Blocking Resources
- Third-Party Scripts and Core Web Vitals
- Image Optimization: WebP, AVIF, Sizing and Lazy Loading
- What Is LCP? Largest Contentful Paint Explained
Recommended Resources
For further reading on HTTP caching and cache-header configuration, explore these authoritative resources:
- MDN: HTTP Caching: Understand browser caching, fresh and stale responses, validation, and cache revalidation.
- MDN: Cache-Control Header: Explore directives such as
max-age,no-cache,no-store, andpublic. - RFC 9111: HTTP Caching: Read the official specification for HTTP caching behavior.
- web.dev: Learn Performance: Explore caching and other techniques for improving website performance.
- Google PageSpeed Insights: Measure page performance and review available optimization diagnostics.