[adapter-cloudflare-workers] Support writing rendered page to Cloudflare cache to achieve ISR

[ivanvanderbyl]

Describe the problem

The initial build on Cloudflare is quick, however, we'd like to cache it for a certain number of seconds on the Cloudflare cache or KV store to achieve something akin to Incremental Static Rendering in Next, where it will only re-render every N seconds.

This would also dramatically improve TTFB.

Describe the proposed solution

Add an option (or use information from load()) to indicate to the Cloudflare Worker to write the rendered result to Cloudflare cache with a TTL after rendering. Check if rendered result exists in cache before rendering.

Alternatives considered

No response

Importance

would make my life easier

Additional Information

I'd be happy to implement it, if this aligns with the roadmap etc.

[Rich-Harris]

Do you mean https://kit.svelte.dev/docs/loading#output-maxage? Or something else?

[ivanvanderbyl]

Hey @Rich-Harris — my understanding is that maxage controls the data fetching, but the page will still be rendered on each request, is that right? What I want to do is cache the rendered output on the KV store so that it get synced to every region, then have it expire after maxage. Effectively only rendering public pages once, incrementally, and reducing the TTFB as much as possible.

I did an experiment with a custom worker and pushing the output to KV store and it increased our pagespeed score from 87 to 100. But this is based on my limited understanding of the data loading process in Svelte Kit, so my assumption might be wrong 🤷🏻

[Rich-Harris]

maxage does two things:

1. it causes a cache-control header to be added to the response
2. during client-side navigation, it causes data to be cached in memory (so load doesn't re-run until sufficient time has elapsed)

The cache-control header will be public (i.e. CDN-cacheable) unless you use session or make a credentialled fetch (i.e. a fetch without credentials: 'omit') during SSR.

I'm not sure whether the cached page is synced to other regions or not, would be curious to know. If it isn't, then I can see the value of this — though it can't happen willy-nilly, because in many cases the SSR'd page will use session or a credentialled fetch. Ideally it wouldn't be Cloudflare-specific, but would instead be a generic API that adapters could use or ignore (as I don't think my bosses would forgive me if we supported ISR on Cloudflare before Vercel! Relatedly, the API would ideally support on-demand ISR as well as on-request).

[isaac-mcfadyen]

I'm not sure whether the cached page is synced to other regions or not, would be curious to know.

So this is interesting. I'm a moderator on the Cloudflare Developers Discord and I asked around about this.

Workers and Pages Functions don't use the Cloudflare Cache unless you manually insert with cache.put(response) and retrieve with cache.match(request) (doesn't look like either of the Cloudflare adapters do this, they only pull from KV or Pages for prerendered assets).

The only effect of the Cache-Control headers on the response with Workers is browser cache, it doesn't actually make Cloudflare cache the response. This means that cache does not migrate between locations, since there is no cache on Cloudflare. Were you to insert using cache.put it wouldn't migrate between locations, but KV would.

This means that there would indeed be some benefit to storing responses in the cache depending on render time. One thing to keep in mind here is that KV is eventually consistent (can be 60 sec propagation globally) so wouldn't work well for shorter cache times (less than 60 sec) where you need the freshest page once the cache expires. The regular cache doesn't have this limitation since there's no global distribution, so IMO regular cache would be the better option.