JavaScript Caching Test
The JavaScript Caching Test inspects the Cache-Control headers on every .js file referenced by a URL and reports whether each can be cached aggressively, briefly, or not at all.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The JavaScript Caching Test inspects the Cache-Control headers on every .js file referenced by a URL and reports whether each can be cached aggressively, briefly, or not at all. Versioned bundles (output by webpack, Vite, esbuild with content-hash filenames) can be cached for one year with the immutable directive — repeat visits become instant. Unversioned scripts must be cached more cautiously to allow updates.
What This Tool Checks
- Cache-Control header per .js file
- max-age and immutable directives
- Versioned bundle detection (hashed filenames)
- Third-party script cache policies
- CDN cache hit ratio for JavaScript
- ETag presence for conditional requests
Why It Matters for SEO
JavaScript bundles are often the largest single asset on a page. Caching them aggressively turns repeat visits into instant loads — zero bytes, zero parse time. Modern build tools emit content-hashed filenames so the URL changes when the content changes, making 1-year + immutable safe. Most performance issues with JS caching come from misconfigured CDN headers, not from bad build pipelines.
How to Fix It
For hashed bundles: Cache-Control: public, max-age=31536000, immutable. For unhashed scripts: shorter max-age (e.g. 1 hour) with revalidation. Audit third-party scripts and route them through your CDN where possible to control caching. Add ETag for conditional 304 responses on edge-case clients.
How It Works
We walk every <script> on the page, make a HEAD request to each src, capture the Cache-Control headers, and determine whether the URL appears versioned (hash in filename or query string). Versioning detection lets us recommend immutable safely.
Common Mistakes to Avoid
- Versioned bundles cached for only a few hours
- Missing immutable on hashed URLs (forces unnecessary revalidation)
- Third-party scripts (Tag Manager, Intercom) with short cache lifetimes
- Cache-Control: private blocking CDN caching
- Cache-busting query strings instead of hashed filenames
Quick Checklist
- Hashed JS bundles cached 1 year with immutable
- Unhashed scripts cached briefly with revalidation
- Third-party scripts cached or proxied via CDN
- No Cache-Control: private on public scripts
- CDN responds HIT on repeat requests
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
Hashed bundles (e.g. app.a3f9c2.js) can be cached for 1 year with immutable. Unhashed scripts should cache for shorter periods so updates propagate.
Tells the browser the response will never change during its max-age, so the browser does not even revalidate. Safe only on versioned URLs where filename changes when content changes.
Most third parties set short cache lifetimes so they can update their scripts quickly. You can self-host stable third parties (Google Tag Manager via gtag, fonts via local copies) for full cache control.
Yes, indirectly. Cached scripts mean faster repeat visits, better INP scores (less JS to parse) and better Core Web Vitals from real-user data — feeding Google's page-experience ranking signal.
Use content-hashed filenames in your build pipeline. The URL changes whenever the content changes, so the browser fetches the new file automatically and the old cached file simply expires unused.