Skip to main content
Cloud CDN has two independent cache audiences: the shared edge cache and the visitor’s browser cache.

​
TTL ownership

Use origin-controlled caching when application owners manage valid cache headers consistently. Use CDN-controlled caching for static paths or when origin headers cannot be changed.

​
Cache keys

By default, query strings can create distinct cache variants. You can:
  • Ignore every query parameter.
  • Ignore every parameter except an allowlist.
  • Ignore only a named list.
  • Define a custom key expression using supported variables such as $request_uri, $uri, $scheme, and $http_x_cdn_real_host.
A cache key that omits tenant, authentication, language, device, or content-version inputs can serve one variant to the wrong requester. Test key behavior before production.

​
Advanced behavior

  • Ignore Set-Cookie: permits caching even when the origin sets cookies. Enable only when the response is truly shared.
  • Serve stale: returns stale content for selected upstream status codes.
  • Slice: divides large objects into cacheable ranges.
  • Cache POST: permits POST responses to enter cache. Use only for deterministic, public requests with an intentional key.

​
Safe baseline

For public static assets, use versioned filenames, a long edge TTL, and a suitable browser TTL. Bypass or disable shared caching for account pages, personalized HTML, authenticated APIs, carts, and responses that vary by cookies or authorization. After changing keys or freshness rules, use a targeted purge.