How to cache dynamic pages on the edge?

[mastoj]

Summary

It seems like only pages with a "fixed" route are cached on edge.

\app
    \page.tsx //-> cached and served super fast (x-vercel-cache: HIT)
    \[...slug]\page.tsx //-> nothing is cached so much slower response time (x-vercel-cache: MISS).

What do I need to do to cache the pages under the second route?

Example

I have a small example app where I have a static route: https://nextjs-vercel-caching-git-wat-mastoj.vercel.app, that loads super fast when on cache, like 20ms waiting on server. https://nextjs-vercel-caching-git-wat-mastoj.vercel.app/1 on the other hand, it always waits on the server so it is almost an order of magnitude slower when it comes to wait time on server. The first url will also have the x-vercel-cache set to HIT when fast, but the second url always has it set to MISS. The code for that specific deployment is this one: https://github.com/mastoj/nextjs-vercel-caching/tree/wat

[leerob]

dynamicParams is true by default – are you wanting false here? If you want static pages, you should also explore generateStaticParams.

• https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams
• https://nextjs.org/docs/app/api-reference/functions/generate-static-params

Let me know if this helps!

[arichard-info]

Hello @leerob @mastoj,

I don't know if he's talking about exactly the same thing, but I agree with @mastoj's post.

In fact, if I understand correctly, for routes that contain dynamic parameters: either they are completely dynamic (generated with each request), or they are pre-rendered in the build if you use generateStaticParams (and revalidated if necessary).

But it would be nice to have a mix of the two.
Dynamic pages are not necessarily predictable at build time. But they could very well be cached when they are generated for the first time at runtime

And then they would have the normal lifecycle of static pages: it's always the cached page that's served. And it can be revalidated (either via the tags or via the pathname).

I thought it worked like that but I was surprised to see that it didn't. Is this by design? How can I implement the behaviour I've described?

[markomitranic]

Yes, @leerob percisely like @arichard-info wrote. Let me illustrate, in hopes that you could use this example in order to discuss this lack of functionality internally:

• A product category page needs dynamic parameters such as route parameters (for category name), or searchParams (for filters).
• We wish to server-render this page, makes the whole thing much simpler and more powerful to write.
• We wish to cache this page once it is generated, so that we avoid regenerating it millions of times for every user.
• We also do not want to prerender this page, as we could have thousands of categories and tens of thousands of searchparams combinations.

So it would be best to:

• Not prerender
• Do SSG at runtime
• Cache the output until something revalidates it

However it seems impossible to do so.

Now, If one would use a different framework such as Laravel, this type of usage would be the happy path. Or if one were to use a different CDN such as Cloudflare, using the cache headers would guarantee distributed cache, or x-vary god forbid. But when we try to be good boys and use this exactly as Next docs imagined it - there seems to be no way to achieve this :(

Alternatives:

The closest I could get to is forcing the page to be dynamic, and setting a cache header (which has horrible devex in next btw, should fix that and colocate it to the page) in hopes that the Vercel CDN will listen to it and cache the page.

Another option was, I was hoping that the following would achieve this, but unfortunately it starts crying about DYNAMIC_SERVER_USAGE when used:

export const revalidate = 360; // 5 minutes
export const generateStaticParams = () => [];

A third and seemingly only option is to rely on PPR to do the trick. And trust me, I'd love to - but it is simply not ready yet. It is kinda clunky in its current state and makes it very unclear what happens to the page. Also, i have PTSD from using <Suspense> which would opt all these pages into streaming, which was shown to be quite tricky to monitor and expensive to run.

Finally the only way this can be done is the 2010s favourite - Static page, wrap half the page into a <OnlyClient> component and use APIs to fetch and render results on client.