How a Headless CMS Delivers Content via CDN: Caching Explained

You publish a blog post in ContentGrid. Within 30 seconds, a reader in Tokyo sees it on your site with a 40ms load time. No server rendered the page on request. The HTML was prebuilt, the content was cached at an edge node, and the reader's browser got a response from a CDN 12 milliseconds away. That's the headless CMS content delivery model working as intended.

The Delivery Chain

Content moves through three layers before it reaches a user:

• ContentGrid's API: Returns structured JSON from its origin servers. Responses include Cache-Control headers that tell downstream caches how long to store the response.
• Your build or server: Next.js or Nuxt fetches content from the API, either at build time (static generation) or at request time (server rendering with caching). The result is HTML, which your hosting platform caches at the CDN layer.
• CDN edge nodes: Vercel, Netlify, and Cloudflare cache your HTML and static assets at dozens of global edge locations. Requests are served from the nearest node with no origin hit required.

Static Generation vs. On-Demand Revalidation

For content that changes infrequently — blog posts, product pages, documentation — static generation is the fastest approach. Your Next.js build fetches all content at deploy time, renders HTML for every page, and pushes that HTML to the CDN. Vercel's Edge Network serves it globally.

For content that changes frequently, Next.js Incremental Static Regeneration (ISR) or on-demand revalidation fits better. A page is served from cache; when content changes, a webhook from ContentGrid triggers revalidation of just that page. The next request gets a fresh render; the CDN caches that fresh response.

Cache Invalidation with Webhooks

ContentGrid sends a webhook payload when any entry is published, updated, or deleted. That payload includes the entry ID, type, and updated fields. Your webhook handler — a Next.js API route or an edge function — calls Vercel's revalidation API for the affected page paths. Only the pages that reference the changed content get invalidated. Everything else stays cached.

This is meaningfully better than a full-site cache purge, which forces a rebuild of every page. With targeted invalidation, a content change on one blog post costs one page revalidation, not 500.

Content API Caching

ContentGrid's REST API responses are cacheable at the HTTP level. Use stale-while-revalidate headers to serve slightly stale content immediately while fetching a fresh copy in the background. For high-traffic pages, proxy ContentGrid's API responses through Cloudflare or your CDN with appropriate TTLs. The goal is that no user request ever hits ContentGrid's origin directly — only your build server and your revalidation handler do.