Start here
Before You Fix It: What This Check Means
Caching policy determines whether repeat visitors and bots can reuse responses efficiently. In plain terms, this tells you whether users are likely to feel this page as fast, stable, and usable. Scavo samples first-party static assets discovered in page HTML (scripts, styles, images), up to 8 assets, and probes headers.
Why this matters in practice: degraded speed here often compounds into lower conversion and weaker user trust.
How to use this result: treat this as directional evidence, not final truth. Synthetic sampling may not fully match real-user device/network variability. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Use hashed/immutable asset filenames for JS/CSS/media. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: Cache-Control and Expires headers are missing or set too low, forcing returning visitors to re-download assets they already have.
Google recommends a minimum cache lifetime of 30 days for all cacheable subresources, with one week as the absolute minimum and one year recommended for static assets (Chrome DevTools Lighthouse). Without caching headers, every return visit downloads your CSS, JavaScript, images, and fonts from scratch — wasting bandwidth and making your site feel slow for your most engaged users.
What Scavo checks (plain English)
Scavo samples first-party static assets discovered in page HTML (scripts, styles, images), up to 8 assets, and probes headers.
A sampled asset is considered strongly cacheable when:
Cache-Controlhasmax-age >= 86400(1 day), orCache-Controlincludesimmutable, orExpiresis sufficiently far in the future
It also treats no-store / no-cache as weak for static assets.
How Scavo scores this check
Result behavior:
- Pass: >=70% sampled assets have strong caching
- Warning: 40-69% strong caching (mixed)
- Fail: <40% strong caching
- Info: sampling inconclusive or no eligible first-party assets
In your scan report, this appears under What failed / What needs attention / What is working for caching, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
caching - Category:
PERFORMANCE
Why fixing this matters
Weak caching increases repeat page-load cost, bandwidth, and render delays, especially on mobile/constrained networks. Good cache policy is one of the fastest practical performance wins.
Operationally, strong caching also stabilizes delivery under load because fewer repeat requests hit origin for unchanged versioned assets.
Common reasons this check flags
- Static files served with no cache headers.
- Shared default header middleware sets short or no-store policies globally.
- Unversioned asset URLs force conservative cache settings.
- CDN policy differs between file types or path prefixes.
If you are not technical
- Ask your dev team whether static files use versioned filenames/hashes.
- Confirm repeat visits should not redownload unchanged JS/CSS/images.
- Prioritize high-traffic page templates first.
- Re-run Scavo and watch strong-cache percentage trend upward.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Browser Caching (caching). Please apply strong cache directives to versioned first-party static assets (max-age >= 86400 and/or immutable), and share before/after header evidence.If you are technical
- Use hashed/immutable asset filenames for JS/CSS/media.
- Set long-lived cache headers for versioned assets.
- Keep HTML/document cache policy separate from static-asset policy.
- Avoid
no-storefor versioned static files unless absolutely required. - Verify CDN and origin policies are aligned by path/type.
How to verify
- Inspect response headers for sampled first-party assets.
- Confirm
Cache-Controlis strong on versioned assets. - Ensure caching rules differ appropriately between HTML and static files.
- Re-run Scavo and confirm strong-cache ratio improves.
What this scan cannot confirm
- It does not verify cache hit ratio in your CDN analytics.
- It samples only a subset of first-party assets per page.
- It does not evaluate third-party asset cache strategy.
Owner checklist
- [ ] Assign owner for static-asset cache policy.
- [ ] Standardize cache headers by asset type/path.
- [ ] Add regression tests for cache headers in release checks.
- [ ] Recheck after CDN migrations or build-pipeline changes.
FAQ
Is one day (max-age=86400) enough?
It is the minimum "strong" threshold in this check. Versioned assets often benefit from much longer lifetimes with immutable.
Should HTML pages also be long-cached?
Usually no. HTML often needs faster revalidation; static assets can be far more aggressive.
Why can this be inconclusive?
Some probes are blocked or return insufficient header data, reducing confidence.
What should we fix first?
Start with JS/CSS bundles and hero/media assets on key landing pages.
Sources
Need a path-based cache policy template (HTML vs static vs API) for your stack? Send support your routing pattern.
