Browser Caching & Cache-Control Guide: max-age, ETag & 304

Browser caching improves repeat-load efficiency by allowing previously downloaded responses to be reused or cheaply revalidated instead of being transferred from scratch every time.

The goal is not to cache everything forever. The goal is to give each response an appropriate freshness policy, use validators such as ETag and Last-Modified where revalidation makes sense, and reserve long-lived caching for assets whose URLs change when their content changes.

This guide explains Cache-Control, max-age, s-maxage, no-cache, no-store, immutable, ETag, Last-Modified, conditional requests and 304 Not Modified, plus how to verify cache behavior in Chrome DevTools.

Last verified: September 16, 2026.

---

---

1. What Is Browser Caching?

Browser caching stores eligible responses locally so they can be reused on later requests. A stored response can be fresh and reusable immediately, stale and in need of revalidation, or not storable because the server explicitly forbids storage.

2. Browser Cache vs CDN Cache vs Server Cache

3. Fresh vs Stale Cached Responses

A response with a freshness lifetime can be reused while fresh. After that period, the response becomes stale and may need a conditional request to confirm whether the stored copy is still valid.

4. Understanding Cache-Control

Cache-Control is the main HTTP header used to communicate caching behavior.

Cache-Control: public, max-age=31536000, immutable

5. What max-age Means

Cache-Control: max-age=3600

This tells the browser that the response is fresh for one hour, subject to the rest of the cache policy.

6. What s-maxage Means

s-maxage defines freshness for shared caches and is ignored by private browser caches.

Cache-Control: public, max-age=300, s-maxage=3600

7. public vs private

public allows shared-cache storage where otherwise permitted. private limits storage to a private cache such as the user's browser.

Cache-Control: private, no-cache

8. no-cache Does Not Mean “Do Not Cache”

no-cache allows storage but requires validation with the origin before reuse.

Cache-Control: no-cache

If the resource is unchanged, that validation can return 304 Not Modified instead of transferring the full body again.

9. no-store Means Do Not Store

Cache-Control: no-store

10. no-cache vs no-store

11. must-revalidate and immutable

must-revalidate requires stale responses to be validated before reuse. immutable tells caches that a fresh response will not change during its freshness lifetime and fits best with versioned assets.

Cache-Control: public, max-age=31536000, immutable

12. Why Versioned Static Assets Work Well With Long Caching

/assets/app.8f3c2a.js
/assets/site.42b91f.css
/images/logo.a912fe.webp

When the asset changes, publish a new URL. The old URL can then remain cached safely for a long period.

13. HTML Usually Needs a Different Policy

HTML commonly changes at the same URL, so aggressive immutable caching is usually a poor fit.

Cache-Control: no-cache
ETag: "abc123"
Last-Modified: Wed, 16 Sep 2026 06:00:00 GMT

14. What Is an ETag?

ETag is a server-generated validator representing a version of a resource.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

15. If-None-Match and Conditional Requests

If-None-Match: "abc123"

If the current resource still has the same ETag, the server can return 304 Not Modified.

16. Last-Modified and If-Modified-Since

Last-Modified: Wed, 16 Sep 2026 06:00:00 GMT
If-Modified-Since: Wed, 16 Sep 2026 06:00:00 GMT

If the resource has not changed since that timestamp, the server can confirm the cached copy is still valid.

17. What 304 Not Modified Means

HTTP/1.1 304 Not Modified
ETag: "abc123"
Cache-Control: no-cache

A 304 response has no response body, so the browser can reuse its stored copy instead of downloading the entire resource again.

18. 200 vs 304 vs Direct Cache Reuse

19. Strong vs Weak ETags

ETag: "abc123"
ETag: W/"abc123"

A weak validator indicates semantic equivalence rather than byte-for-byte identity. For performance work, the practical priority is confirming that validation functions correctly.

20. Practical Cache Policies by Resource Type

21. Third-Party Resources Limit Your Control

You cannot directly change response headers on another company's domain. If a third-party asset uses a poor caching policy, your options are to remove it, choose another provider, or self-host only where licensing and maintenance allow.

22. Browser Cache vs Full-Page Cache

A full-page cache can reduce HTML generation work on the server. Browser caching controls whether the client can reuse a response it already received.

For backend response diagnosis, use the TTFB Optimization Guide.

23. Browser Cache vs Redis or Memcached

Redis and Memcached are server-side object caches. They do not determine whether a browser reuses CSS, JavaScript, images or fonts.

Use the Redis vs Memcached Object Caching Guide for the backend layer.

24. Browser Caching vs Resource Hints

Resource hints optimize first-load discovery and priority. Browser caching optimizes reuse after a response has already been fetched and stored. They solve different stages of the loading lifecycle.

25. Browser Caching and Core Web Vitals

Better caching can improve repeat-visit efficiency, but it does not guarantee passing Core Web Vitals. Heavy JavaScript, layout shifts, slow uncached HTML or rendering work can remain even when static assets are cached.

26. Test Browser Caching in Chrome DevTools

Open DevTools and use the Network panel. Inspect Status, Size, Transferred, request headers, response headers and Timing. Check Cache-Control, ETag, Last-Modified and conditional request headers directly.

27. Use Disable Cache for First-Visit Testing

DevTools can disable the browser cache while DevTools is open. This is useful for simulating a first-time visit without cached resources affecting the result.

Do not leave cache disabled when you are trying to test repeat-load behavior.

28. Test Repeat Loads Separately

With caching enabled, reload again and look for:

• from memory cache
• from disk cache
• 304 Not Modified
• fresh 200 OK responses

The correct outcome depends on the resource's policy.

29. Normal Reload vs Hard Reload

Reload mode affects caching behavior. A normal reload may reuse fresh cached responses, while a force reload can bypass or revalidate more aggressively. Document the exact reload mode when comparing performance.

30. Blogger-Specific Browser Caching

Blogger users have limited control over Google-served HTTP response headers for Blogger-hosted pages and platform-managed assets.

Separate resources into:

• Blogger/Google-managed resources.
• Third-party scripts and fonts.
• Externally hosted assets you control.

Configure cache headers only on infrastructure you actually manage. Avoid recommending Nginx or Apache snippets for Blogger-hosted HTML itself.

31. WordPress-Specific Browser Caching

WordPress sites can often control headers through the web server, CDN, managed host, or performance layer. Avoid stacking overlapping rules in Nginx, Apache, CDN and plugins without understanding which layer wins.

32. Common Browser-Caching Mistakes

• Calling no-cache “no caching”: it allows storage but requires validation.
• Using no-store everywhere: useful browser storage is lost.
• Giving HTML a one-year immutable policy: updated content can remain hidden.
• Giving unversioned CSS/JS a long immutable policy: changed assets may not refresh promptly.
• Testing only with cache disabled: repeat-load behavior is hidden.
• Confusing browser cache with Redis: they are different layers.
• Assuming third-party headers can be changed from your site: the provider controls them.

33. Safe Browser-Caching Optimization Workflow

1. Inventory resource classes. HTML, CSS, JS, images, fonts and APIs.
2. Inspect current headers. Record Cache-Control and validators.
3. Separate versioned assets from changeable URLs.
4. Apply an appropriate policy per class.
5. Test first load with cache disabled.
6. Test repeat load with caching enabled.
7. Check 304 responses where appropriate.
8. Deploy a changed static asset and verify cache busting.
9. Check personalized routes separately.

34. Before-and-After Verification Checklist

• Record URL and change date.
• Capture response headers before changes.
• Check Cache-Control.
• Check ETag.
• Check Last-Modified.
• Test first load with cache disabled.
• Test repeat load with cache enabled.
• Check memory/disk cache reuse.
• Check for 304 Not Modified.
• Confirm versioned assets update when their URL changes.
• Confirm HTML updates remain visible.
• Check personalized responses for shared-cache risks.
• Check CDN headers separately where a CDN is used.

---

Frequently Asked Questions

What does browser caching do?

It stores eligible responses on the user's device so the browser can reuse them later or revalidate them without downloading the full body again.

Does no-cache disable caching?

No. It allows storage but requires validation with the origin before reuse.

What is the difference between no-cache and no-store?

no-cache allows storage but forces revalidation. no-store tells caches not to store the response.

What does 304 Not Modified mean?

It means a conditional request confirmed that the cached response is still valid, so the server does not retransmit the full body.

Should CSS and JavaScript be cached for one year?

Long-lived caching can be appropriate when the asset URL is versioned or fingerprinted so a content change produces a new URL.

Should HTML use immutable caching?

Usually not for ordinary changing pages. HTML commonly benefits from revalidation because the same URL may serve updated content.

Do I need both ETag and Last-Modified?

Servers can provide both. They are validators used for conditional requests and can help avoid retransmitting unchanged resources.

Does browser caching improve TTFB?

Direct cache reuse can avoid an origin request for that resource, but browser caching does not fix slow origin TTFB for uncached requests that still reach the server.

Is browser caching the same as Redis?

No. Browser caching happens on the client. Redis and Memcached are server-side object caches.

Can Blogger users control Cache-Control headers?

Control is limited for Blogger-hosted pages and Google-managed resources. You can control headers for assets served from infrastructure you manage.

---

Final Takeaway

Browser caching works best when the cache policy matches how a resource changes.

Use long-lived caching for versioned static assets, revalidation for content that changes at the same URL, validators such as ETag and Last-Modified to avoid unnecessary retransfers, and no-store only when storage itself is inappropriate.

The strongest strategy is to separate immutable versioned assets, changeable HTML, personalized responses and shared-cache content, then give each class a policy that balances freshness, privacy and repeat-load efficiency.

•