Caching and Updates
How Coframe SDK bundles are versioned and cached at the edge
Copy this guide and your current settings as a prompt for your AI agent.
Preview agent promptSee the guide, code and settings included when you copy.
The Coframe edge worker serves the SDK in two ways: immutable versioned bundles tied to a specific content hash, and a default route that assembles a fresh personalized bundle per request.
01Versioned bundles
Script URLs that embed a 12-character hexadecimal content hash — for example:
https://edge.cofra.me/cf-static-d1afdec09cc5.jsare served from a static asset map compiled into the edge worker with the response header:
Cache-Control: public, max-age=31536000, immutableThe one-year max-age combined with immutable tells browsers and intermediate caches that this URL’s content will never change, allowing it to be cached indefinitely without revalidation. Both minified and non-minified variants follow the same scheme (the non-minified form appends a -non-minified suffix before .js).
Historical hash URLs continue to resolve after new deployments because the full asset map is bundled with each worker release.
For how versioned URLs are generated and how to update your install snippet, see Delivery and Versioning.
02The default cf.js route
Requests to /cf.js (and any path that does not match a static hash URL) are handled by the default route, which assembles a response that includes your project’s experiment configuration baked in alongside the SDK bundle.
This route is cached briefly and revalidated rather than cached forever: the response sets Cache-Control: private, max-age=60 along with an ETag (a hash of the content). For 60 seconds a browser may reuse its copy; after that it revalidates, and the edge returns 304 Not Modified when the ETag still matches. This keeps the SDK and your project configuration fresh — changes propagate within about a minute — while avoiding a full re-download when nothing has changed. See Delivery and Versioning for more on delivery.
# Caching and Updates How Coframe SDK bundles are versioned and cached at the edge The Coframe edge worker serves the SDK in two ways: immutable versioned bundles tied to a specific content hash, and a default route that assembles a fresh personalized bundle per request. ## Versioned bundles Script URLs that embed a 12-character hexadecimal content hash — for example: PLAINTEXT ``` https://edge.cofra.me/cf-static-d1afdec09cc5.js ``` are served from a static asset map compiled into the edge worker with the response header: PLAINTEXT ``` Cache-Control: public, max-age=31536000, immutable ``` The one-year `max-age` combined with `immutable` tells browsers and intermediate caches that this URL’s content will never change, allowing it to be cached indefinitely without revalidation. Both minified and non-minified variants follow the same scheme (the non-minified form appends a `-non-minified` suffix before `.js`). Historical hash URLs continue to resolve after new deployments because the full asset map is bundled with each worker release. For how versioned URLs are generated and how to update your install snippet, see [Delivery and Versioning](../docs/delivery-and-versioning.html). ## The default cf.js route Requests to `/cf.js` (and any path that does not match a static hash URL) are handled by the default route, which assembles a response that includes your project’s experiment configuration baked in alongside the SDK bundle. This route is cached briefly and revalidated rather than cached forever: the response sets `Cache-Control: private, max-age=60` along with an `ETag` (a hash of the content). For 60 seconds a browser may reuse its copy; after that it revalidates, and the edge returns `304 Not Modified` when the `ETag` still matches. This keeps the SDK and your project configuration fresh — changes propagate within about a minute — while avoiding a full re-download when nothing has changed. See [Delivery and Versioning](../docs/delivery-and-versioning.html) for more on delivery. ## Related - [Delivery and Versioning](../docs/delivery-and-versioning.html) — script tag formats, version pinning, and upgrade path - [Config Reference](../docs/config-reference.html) — `projectId` and other SDK configuration options