Missing Cache-Control headers on api.consentpro.com runtime — failing Lighthouse "efficient cache policy" check

Consent Pro
1

Hey team,

Running SEO audits on a client’s Webflow site (~1,400 pages) and SEMrush is flagging the Consent Pro runtime script on every page as an uncached resource. Verified in DevTools and via curl — the response from api.consentpro.com is missing all cache-related headers.

Response Headers actually returned:

  • Access-Control-Allow-Credentials

  • Alt-Svc

  • Cf-Ray

  • Content-Encoding: zstd

  • Content-Type: application/javascript

  • Date

  • Nel

  • Priority

  • Report-To

  • Server: cloudflare

  • Server-Timing

  • Vary: Origin

Missing:

  • Cache-Control

  • Expires

  • ETag

  • Last-Modified

Without explicit cache directives, browsers fall back to heuristic caching and most treat the file as effectively uncacheable — repeat visitors re-download the runtime on every pageview. Lighthouse’s “Serve static assets with an efficient cache policy” audit expects a minimum TTL of ~30 days for cacheable subresources, so this fails by default.

The runtime filename already includes a content hash (674d649ddd92d4cd09236107.js), which means it’s effectively immutable per build — config updates generate a new hash. That’s the ideal setup for aggressive caching with zero staleness risk.

Could you set something like Cache-Control: public, max-age=31536000, immutable on the hashed runtime, or at minimum a 30-day TTL to clear the Lighthouse threshold?

Happy to share curl/DevTools screenshots if helpful.

Thanks! @Support-Luis

2

Hey @brycerdrawe.b!

Your analysis is technically sound — the content-hashed filename pattern on the runtime script is exactly the right setup for aggressive long-term caching, and the absence of Cache-Control, ETag, and Last-Modified headers is a legitimate gap worth looking into.

Here’s what we can confirm: the Consent Pro runtime script is served from api.consentpro.com, which is Finsweet’s own infrastructure. That means cache header configuration sits entirely on our server side — there’s nothing in the Consent Pro setup that exposes cache TTL as a user-configurable option, and it’s not something you’d be able to address from within Webflow or your Cloudflare account.

We don’t want to speculate on whether the missing headers are by design (e.g., to ensure real-time config propagation when consent settings change) or simply a configuration gap — our docs don’t cover this level of detail, so we’d just be guessing either way.

We’re escalating this now with your detailed findings attached so the team who built the CDN layer can give you a straight answer. :folded_hands:

3

Hey @brycerdrawe.b

Update: The dev team got back with this

Consent Pro scripts can’t be 100% cached since we need to query for things like License, Geolocation and Domain information, we’re caching the heavy stuff like configs. And at runtime we’re reading the banner elements from source page, so that is a request also that cannot be cached really