At a glance
List of static resources with weak or missing cache-control headers, ranked by repeat-visit cost. Lighthouse’s “Serve static assets with an efficient cache policy” audit identifies images, CSS, JS, and fonts where the Cache-Control header sets a short TTL (under 1 month) or is missing entirely. Repeat-visitors pay these bytes again instead of serving from browser cache. The fix is purely server-side header configuration; no code changes required.
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store homepage audit, mobile, Wednesday 15 May 26.
What the ranked list is telling us:
- 3.7MB of repeat-visit bytes are currently re-downloaded unnecessarily because cache TTLs are too short. A returning customer hits the site, downloads the same theme JS, hero image, fonts, and product images they downloaded yesterday. The browser would happily serve from cache if the headers said it could.
-
Theme JS + CSS at 1-day TTL is the simplest fix. BC’s default is conservative because Stencil bundles aren’t content-hashed by default, so the browser can’t tell when content has actually changed. Two paths: (a) Add content-hashing to theme bundle filenames so cache TTL can be 1 year safely (
bundle.a3f8b9.js); (b) Use etag validation so browsers re-validate efficiently without re-downloading. Path (a) is more performant; path (b) is simpler to ship. - Hero banner image at 1-hour TTL is wasteful. The image rarely changes; the 1-hour TTL forces every repeat visitor to re-download 2.8MB. Set 30-day TTL via the image CDN configuration; if the merchant changes the hero image they’ll need to update the URL or trigger a CDN purge, which is fine for occasional content updates.
-
Web fonts at 1-day TTL is wrong. Fonts almost never change. Set 1-year TTL with
immutabledirective; fonts are the canonical case for aggressive caching. - Product images at 1-hour TTL is the same pattern as the hero. Image CDNs typically handle this well but per-merchant configuration sometimes drifts to conservative defaults. Bulk-update via CDN console: set 30-day TTL across product image bucket.
- Klaviyo + Tidio scripts (ranks 7-8) are vendor-controlled. The merchant can’t change these. Out of scope for the merchant; raise with the vendor if it becomes a sustained issue.
- Cumulative impact: setting proper TTLs across ranks 1-6 saves 3.7MB of repeat-visit bytes. Returning customers experience load times near zero for static content; only the dynamic HTML hits the network. For ecommerce, this is the closest thing to “free” performance: zero code changes, immediate impact, proportional to repeat-visit traffic share (typically 40-60 percent of total sessions).
- Industry data: brands with strong caching see 30-50 percent faster repeat-visit LCP than first-visit LCP. The conversion rate impact is smaller than first-visit work (most users are first-visit on a given page) but the cumulative effect across all repeat visitors is meaningful.
- Check Cache-Control headers in DevTools Network tab; the “Cache” column shows TTL.
- Identify high-byte resources with short TTL. Concentrate on resources over 100KB with TTL under 7 days.
- Configure CDN / server / image-CDN to set proper TTLs.
- Re-audit to confirm headers updated as expected.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, “Serve static assets with an efficient cache policy” opportunity in Diagnostics.
- Chrome DevTools → Network tab, the “Cache” column shows TTL per resource; “Disable cache” checkbox lets you compare cold-cache vs warm-cache load times.
- CDN / image-CDN console, usually the right place to configure default cache TTLs for static assets.
Cross-connector reconciliation: primarily internal (with
psi_total_weight, psi_image_optimisation).
Quick rule for support tickets: if a merchant says “I set 1-year TTL on my CDN but Vortex IQ still flags the resource”, the most common cause is CDN edge propagation delay or origin-cache vs edge-cache configuration mismatch. Verify the actual Cache-Control header in DevTools Network tab.
Known limitations / merchant FAQs
My theme bundle has 1-day cache. Why is that a problem? It forces every repeat visitor to re-download 130-300KB of theme JS+CSS that almost certainly hasn’t changed since their last visit. Strong caching (1-year with content hashing) makes the browser skip the download entirely and use the local cached copy. For ecommerce sites with 40-60 percent repeat-visit traffic, this is a substantial win. What if I update my theme? Won’t long cache TTLs cause stale content? Only if you don’t use content-hashing. The pattern: when your build process generatesbundle.a3f8b9.js (with content hash in filename), every theme update produces a new filename. Old browsers serve the old bundle from cache; new browsers fetch the new bundle. Cache invalidation is automatic via the URL change.
Can I just set 1-year TTL on everything?
Not on HTML. HTML pages are dynamic (cart state, login state, dynamic pricing) and need short cache TTLs. HTML default: no-cache or 1-5 minute TTL with revalidation. Static assets (images, CSS, JS, fonts) can be aggressively cached.
My image CDN says it’s caching, but Lighthouse flags my images. Why?
The CDN may be caching at the edge but the Cache-Control header sent to the user’s browser is shorter. Two-tier caching: CDN serves to users, but the user’s browser only caches per the response header. Check the actual response header in DevTools Network tab; the CDN edge cache and browser cache are different layers.
What about service workers? Do they handle this?
Service workers can cache more aggressively than HTTP Cache-Control allows, including offline support. For ecommerce, service workers are powerful but complex; most merchants achieve adequate caching via standard HTTP headers without the maintenance overhead of service worker code.
Can Vortex IQ change my CDN config automatically?
Read-only by design. The card identifies what should be cached longer; the merchant or developer configures the CDN.
My third-party scripts (Klaviyo, GTM, Tidio) have short TTLs. Can I fix that?
Generally no; vendors control their own headers. Workarounds: (a) self-host the script if vendor permits (rare); (b) live with the cost. Most third-party scripts cache reasonably (1-day to 1-week) by default; if you see very short TTLs (under 1 hour), raise with the vendor.
Should I worry about caching for first-time visitors?
No. Caching helps repeat visits; first visits download everything regardless. First-visit performance is driven by image optimisation, render-blocking fixes, and JS bundle work. Caching is the repeat-visit lever.