Caching Guide for Contentstack Launch

Caching is essential for improving performance, reducing latency, and minimizing load on your origin server. Contentstack Launch uses a CDN to cache content at the edge, enabling fast and scalable content delivery.

This guide explains how caching works in Launch, how to configure it using headers, and the best practices for cache control and revalidation.

How Caching Works in Launch

Launch automatically caches content at the CDN level based on HTTP cache headers. Here's how different types of content are handled:

• Static Assets (for example, images, JS, CSS): Automatically cached with long TTLs.
• HTML Pages: Can be cached using Cache-Control headers.
• APIs or Dynamic Content: Can be cached or bypassed based on your configuration.

General Caching Strategies

1. Static Content

   • Content built during deployment is served as static files.
   • Recommended for content that remains mostly unchanged over time.
   • Automatically cached by the CDN for fast delivery.

2. Dynamic Content with Cache Headers

   • Control caching behavior through HTTP response headers.
     Example:
     Cache-Control: public, max-age=0, s-max-age=60, stale-while-revalidate=30

     This instructs the CDN to:

     • Cache content at the edge for 60 seconds (s-max-age=60).
     • Allow serving stale content while revalidating for 30 seconds (stale-while-revalidate=30).
     • Always revalidate content at the browser level (max-age=0).

   Additional Resource: For a Next.js specific guide, follow Next.js on Launch.

Cache Revalidation

1. Time-Based Revalidation

   Use Cache-Control headers to define caching duration and revalidation behavior.
   Example:
   Cache-Control: public, max-age=0, s-max-age=300, stale-while-revalidate=60

   • Cache content at the CDN for 5 minutes (s-max-age=300).
   • Allow stale content to be served for 1 minute while revalidating (stale-while-revalidate=60).
   • Instruct browsers to always revalidate with the CDN (max-age=0).

2. On-Demand Revalidation

   Trigger revalidation dynamically using one of the following methods:
   • Launch provides deploy hooks to trigger redeployments on demand.
   • Launch supports a framework-agnostic approach to on-demand cache revalidation through Automate.
   • If you're using Next.js, follow the Next.js guide on Launch to opt out of full-route caching. Alternatively, use Cache-Control headers for framework-agnostic caching, and let Automate handle the revalidation.

Disabling Cache

To disable caching completely, set the header as follows:

Cache-Control: no-store

This ensures that the CDN or browser never caches the response.

Disabling cache can significantly impact performance and increase load on your origin server. Use it only when necessary, such as in the following cases:

• Pages that must always reflect real-time data.
• Specific paths where caching would result in incorrect or outdated content.
  Note:

  • Avoid disabling cache globally. Instead, apply it selectively and only when absolutely required.
  • For most scenarios, use short TTLs or stale-while-revalidate for better performance and flexibility.

Purging Cache

Cache purging methods include:

• Redeploying your site (invalidates CDN cache).
• Using Automate to trigger redeploy or webhook.
• Setting short TTLs for dynamic content.

Best Practices

• Prefer Server-Side Rendering (SSR) with custom Cache-Control headers for most use cases. SSR enables on-demand CDN cache revalidation and handles dynamic routes efficiently.
• Use SSG only for simple sites with content that changes infrequently.
• Always define explicit Cache-Control headers for dynamic content to ensure predictable caching behavior.
• Avoid placing another CDN in front of Launch to prevent cache conflicts.
• Monitor cache status using response headers such as x-cache or cf-cache-status.