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?

[khanakia]

@markomitranic Were you able to cache the page ?

I am using Code highlighter which slows down the page rendering.

I am getting DYNAMIC_SERVER_USAGE error when I used

src/app/blog/[slug]/page.tsx

export const dynamicParams = true
export const generateStaticParams = async () => {
  return []
}

[hdodov]

This can be done by leveraging middleware and using rewrites.

In your middleware, you have to fetch (and very reliably cache) all dynamic params that you may need. For example:

export async function middleware(request) {
  const productCategories = await carefullyCached(getCategories());
  const pageNumber = request.nextUrl.searchParams.get("page") || 1;
  const country = request.headers.get("CF-IPCountry"); // e.g. with Cloudflare

  const path = request.nextUrl.pathname;
  const activeCategory = path.match(/\/products\/(.+)/)?.[0];

  if (productCategories.includes(activeCategory)) {
    const attrs = [
      ["cat", activeCategory],
      ["page", pageNumber],
      ["country", country],
    ]
      .map(([k, v]) => `${k}=${v}`)
      .join("&");
    return NextResponse.rewrite(new URL(`/products/${attrs}`, request.url));
  } else if (activeCategory) {
    return NextResponse.rewrite(new URL("/404", request.url));
  }
}

By doing this, you essentially "lift up" the data that would opt your components out of caching (searchParams, cookies, headers, etc.), you put it in the middleware, and "translate it" to a path:

• /products/microwaves → /products/cat=microwaves&page=1&country=ES
• /products/bicycles?page=2 → /products/cat=bicycles&page=2&country=BG
• …and so on

Then you just need a dynamic route app/products/[attrs]/page.jsx to parse the attributes:

export const revalidate = 300

export default async function ProductsPage({ params }) {
  const { attrs } = await params;
  const parsedAttrs = Object.fromEntries(
    decodeURIComponent(attrs)
      .split("&")
      .map((kv) => kv.split("="))
  );
  const {
    cat, // "bicycles"
    page, // "2"
    country, // "BG"
  } = parsedAttrs;

  return (
    <main>
      <h1>Products ({cat})</h1>
    </main>
  );
}

This way, each combination of attributes will be cached for 5 minutes.

The cool thing here is that you could have different caching behaviors for different combinations of attributes by rewriting to different routes in the middleware:

if (["phones", "laptops", "watches"].includes(activeCategory)) {
  return NextResponse.rewrite(new URL(`/main-cats/${attrs}`, request.url));
} else {
  return NextResponse.rewrite(new URL(`/other-cats/${attrs}`, request.url));
}

…so the following would happen:

• /products/laptops → /main-cats/cat=laptops&page=1&country=ES
• /products/bicycles → /other-cats/cat=bicycles&page=1&country=BG

…and you would obviously need these two routes:

• app/main-cats/[attrs]/page.jsx (e.g. with revalidate = 300)
• app/other-cats/[attrs]/page.jsx (e.g. with revalidate = 3600)

---

The downside is that you basically have to do your own routing and hack around the actual Next.js router. It's not that easy to maintain and you could easily get some things wrong.

You also have to be extremely careful with the number of unique combinations of attributes. For example, you need to allow only specific values for stuff coming from searchParams and treat others as undefined. In the code above, you'd have to make sure that the page coming from the URL is a number and is less than 1000, for example (ideally you'd get the exact number of pages in the middleware, carefully cached, and compare with that). Otherwise you could get spammed with all kinds of trash URLs (?page=asdf, ?page=来自中国的问候, etc.), which will consume up all the disk space of your servers and halt them. Learned this the hard way.

This seems pretty hacky, but it does the job. @leerob can you think of a better way?

[markomitranic]

Thanks for the response @hdodov ! I love how it showcases the insane loops we need to jump through in order to get this fairly simple feature working.

Next.JS should have a built-in feature for this. This should be the happy path to run any next app for most websites.

[nachodeh]

Was just trying to achieve the same behavior and stumbled upon this thread. Totally agree NextJS could support this out of the box for a much better devex. Prerendering thousands of pages at build time can be too expensive, but it makes sense for them to be cached for a while after they receive a visit.

[tlmader]

@markomitranic Going down this rabbit hole myself, where I am trying to increase page load speed for a ton of content pages I do not know ahead of time. I was wondering if ISR gets you closer to what you are looking for?https://nextjs.org/docs/app/guides/incremental-static-regeneration

However, it does come with some ergonomic challenges related to useSearchParams. Related: #58884