Caching

Published Delivery responses are immutable until content changes, so they are safe to cache hard. Wriven sets cache headers and surrogate tags, then purges exactly the affected responses when you publish, unpublish, or delete.

Response headers

# a published list response
Cache-Control: public, s-maxage=60, stale-while-revalidate=300
Surrogate-Key: proj_abc type_blog_post entry_1 entry_2
Cache-Tag:     proj_abc type_blog_post entry_1 entry_2

Cache tags

Each response is tagged with its project, its content type, and every entry it contains. When an entry is published, unpublished, or deleted, Wriven purges the tags it touches — so a CDN can drop precisely the stale responses without invalidating anything else.

Putting a CDN in front

Point Fastly or Cloudflare at the Delivery API and let the headers do the work: serve cached copies for up to 60 seconds, refresh in the background for 300 more, and rely on tag-based purge to stay fresh on publish. This is the cheapest way to scale and to keep usage under your plan’s request allowance.

Next.js ISR

In a Next.js app, pass the cache directives straight through to the framework fetch so pages regenerate on a schedule and on-demand:

// revalidate this page at most every 60 seconds
const res = await fetch(url, {
  headers: { Authorization: 'Bearer ' + token },
  next: { revalidate: 60, tags: ['blog_post'] },
});