Next.js has several cache layers. An external CDN needs a policy that preserves the framework’s representation and revalidation behavior.
Hashed static files are the easy win
/_next/static and fonts are immutable. Long TTL, ignore query strings, never purge unless you reuse a filename (you should not).
This alone improves LCP for returning and new sessions once the HTML references those hashes.
The delivery model
Next.js CDN caching
- 01Build assetsUse content-hashed framework assets.
- 02ResponsesPreserve relevant headers, variants, and private routes.
- 03RevalidateAccount for upstream and CDN copies separately.
ISR and anonymous SSR
If a page is identical for every anonymous visitor, cache the HTML (and shareable RSC payload) at Cloud CDN. Revalidate or deploy should purge those URLs so you do not wait on TTL.
Draft mode, preview tokens and cookie-personalised App Router trees must bypass. If middleware sets a shopper cookie on every HTML response, you cannot cache that HTML as public.
Images
You can keep the Next image optimizer as origin and cache its output, or point public images at Cloud CDN transformation and skip some origin resize work.
Either way the public hostname should be the CDN, not the Node process.
Hosting does not have to change
Self-hosted Node, a container or another host can all be the origin. Cloud CDN is the public edge. Validate on a test hostname including a preview URL that must not be cached.
Validate before production
Check the documentation for the exact Next.js version and hosting adapter. Test HTML and client-navigation responses separately, preserve framework Vary behavior, and verify that tag or path revalidation does not leave an older external CDN copy.
- Record the configuration and expected result before changing traffic.
- Keep evidence of the test and a working rollback for the previous behavior.
