Add incremental static regeneration

[Nick-Mazuk]

Overview

One of the best features of Next.js is incremental static regeneration. It would be great to have something similar to it.

https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration

The core features being:

• Pages can be dynamically generated
• Resulting page is cached for X time
• After X time, the page is dynamically regenerated again

In the ideal world, there would also be some way to invalidate the cache. vercel/next.js#16488

As I understand Sveltekit, currently, this is not possible.

Proposed solution

Extend the prerender API with a revalidate parameter.

<script context="module">
	export const prerender = true;
	export const revalidate = 900; // 900 seconds, or 15 minutes
</script>

[Conduitry]

This can essentially be done now by returning cache headers and having a proxy sitting in front of the Kit app that understands those cache headers. I'm not entirely convinced this needs its own implementation solely in Kit.

[Rich-Harris]

Your pages can return cache headers via the maxage property: https://kit.svelte.dev/docs#loading-output-maxage

Cache invalidation is always going to be platform-specific. We've vaguely talked about adapters being able to do cache invalidation for you (i.e. adapter-vercel would know how to invalidate URLs in the Vercel cache) but I imagine it will always be a bit of an inexact science.

[lukasIO]

If I understand correctly, the difference to what @Nick-Mazuk is proposing would be that one unlucky user has to wait for the server side requests to complete everytime the cache header expires. In the worst case scenario that unlucky user would experience this on every single (unique) route while navigating the website.

[skrhlm]

I must say that I like the proposed non-solution from @Conduitry. It seems better to leave this kind of implementation to the developer, hence avoiding SvelteKit turning into yet another unconfigurable one-size-fits-all monolith, *cough* nextjs *cough*

@lukasIO what you're mentioning is actually one of the worst things with the implementation in NextJS. It essentially makes an environment dependent on itself since it prerenders these pages in the build-process.

[lukasIO]

@skrhlm I get your point that this might not be suitable in all situations, or rather it's probably only suitable in few situations, but as far as i understood, the static prerending/generation is exactly the point of this proposal.

I could see the value for this proposal for less frequented sites, where the proposed cache-header solution would have a rather negligible effect if every second or third user hits the site with an expired cache header (and thus has to wait for the server side requests to complete instead of being served a static build).

[benmccann]

If there aren't many users then you also don't need to worry about performance very much

[Nick-Mazuk]

This can essentially be done now by returning cache headers and having a proxy sitting in front of the Kit app that understands those cache headers. I'm not entirely convinced this needs its own implementation solely in Kit.

That would work if you controlled the production environment. I'm deploying on Vercel, so I'm not entirely sure that would be possible. Could be wrong, though.

If I understand correctly, the difference to what @Nick-Mazuk is proposing would be that one unlucky user has to wait for the server side requests to complete everytime the cache header expires. In the worst case scenario that unlucky user would experience this on every single (unique) route while navigating the website.

I'm not terribly concerned with this, though I can see how it would be important to others.

I'm actually more concerned with high-traffic sites where every single user visits either an uncached page or an out-of-date page.

[skrhlm]

@lukasIO Good point! Actually my main problem is with the implementation of it in next, not precisely the idea of it. But as @benmccann said the problem diminishes with the size of the crowd.

[Nick-Mazuk]

@skrhlm, out of curiosity, what's your issue with the implementation of it in Next.js?

[lukasIO]

Imho the point about performance impact for less frequented sites boils down to what you are doing in load.
Once load requests data from a headless CMS, static pregeneration would mean a noticable performance improvement even if there are only few users.
But I fully accept that this kind of scenario is probably not in the focus at all 😃

[Rich-Harris]

The thing I'm having a hard time getting my head round is what is doing the regeneration? E.g. you can't have long-lived timeouts in a serverless environment.

Or are we just talking about adding a stale-while-revalidate cache control directive? Is that how Next works? In that case, this...

<script context="module">
  export async function load({ page }) {
    const props = await whatever(page.params);

    return {
      props,
      maxage: 1,
      revalidate: 59
    };
  }
</script>

...could translate to Cache-Control: public, max-age=1, stale-while-revalidate=59 (or private for pages that use user data).

[Rich-Harris]

Next's docs suggest that's not what's happening in their case, but I don't yet understand how what they describe could work in an environment-agnostic way. Is this actually a Next+Vercel feature? And if so what advantages does it have over stale-while-revalidate?

[lukasIO]

...could translate to Cache-Control: public, max-age=1, stale-while-revalidate=59 (or private for pages that use user data).

At least for the use cases that I had in mind, this doesn't sound like a bad option...

For the arguments sake:
The difference I can see (while I'm not familiar with how next implements the static regeneration feature) is that with stale-while-revalidate different routes could get out of sync.

In the case that /foo is visited quite frequently but /foo/bar only less so, the content in /foo/bar could end up significantly older in comparison.

edit:

The thing I'm having a hard time getting my head round is what is doing the regeneration?

Apart from the node-adapter, I have no idea how that could work. Thinking out loud: Optionally expose a server-route to trigger regeneration and leave it up to the app developer how to trigger it regularly or on demand (e.g. cronjobs, a seperate service, CMS content update hooks etc.)

[Nick-Mazuk]

After some research, I'm guessing that incremental static regeneration (ISR) might have originally been just a Next.js on Vercel thing, but other platforms are adopting it.

For instance, the original next-on-netlify plugin did not allow for ISR.

opennextjs/opennextjs-netlify#151

But in December, Netlify announce a new plugin, @netlify/plugin-nextjs, which allows for ISR.

Announcement: https://www.netlify.com/blog/2020/12/07/announcing-one-click-install-next.js-build-plugin-on-netlify/

Repo: https://github.com/netlify/netlify-plugin-nextjs

Code for ISR (potentially): https://github.com/netlify/netlify-plugin-nextjs/tree/main/src/lib/pages/getStaticPropsWithRevalidate

So it seems like ISR is possible in a serverless environment outside of Vercel, but perhaps the implementation will be platform-specific… and not all platforms will support it.

---

The thing I'm having a hard time getting my head round is what is doing the regeneration? E.g. you can't have long-lived timeouts in a serverless environment.

@Rich-Harris With Next.js, the server is doing the regeneration. I could be wrong, but I think this is now Next.js works for static pages with this option.

1. When a visitor visits the page, the server will dynamically generate the page SSR style.
2. The server will cache the file. I assume it uploads it to the build cache or something to prevent long timeouts. It also adds a tag of when the page is invalid (e.g., 15 minutes from now)
3. When another person views the page, the server will check the build cache to see if the page already exists in the cache.
   1. if it does, check if the page is expired. If expired, regenerate the page as before. If it isn't expired, serve the static page from the cache.
   2. If it doesn't exist, generate the page SSR style

...could translate to Cache-Control: public, max-age=1, stale-while-revalidate=59 (or private for pages that use user data).

I don't think this will do what I was asking for. I believe this will cache the HTML on the client, not on the server?

[Rich-Harris]

I believe this will cache the HTML on the client, not on the server?

Or the CDN — if HTML were suitable for caching by the server, it would be served with a public cache control header which means your CDN takes care of that for you. If it uses user data somehow then it should only be cached in the client. Either way, the server doesn't need to retain anything