Next 13 static page x-vercel-cache is always MISS instead of HIT

[flexdinesh]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.13.4
    Relevant packages:
      next: 13.0.0
      eslint-config-next: 13.0.0
      react: 18.2.0
      react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

I moved my pages/index.tsx static page to app/page.tsx. The page is completely static and I was hoping to cache the page in the edge. I tried Segment config with error but the pages don't seem to be cached from the edge. If it helps, I also set the same segment config in app/layout.tsx.

export const dynamic = 'error';
export const runtime = 'experimental-edge';

The cache headers always come back as MISS. x-vercel-cache: MISS

Unrelated: I'm also curious if there is a way to debug Vercel edge caching in local when using Next.js. It's a pain to deploy to vercel every time to check if it's working or not.

Expected Behavior

The cache headers always come back as HIT for the static page. x-vercel-cache: HIT.

Link to reproduction

https://github.com/flexdinesh/next13-edge-cache-bug

To Reproduce

I have deployed the bug repo here: https://next13-edge-cache-bug.vercel.app

Inspect the page in dev tools network tab and you'll see that the cache hit is always MISS.

Or follow these steps.

1. Create a new next@13 app.
2. Turn on experimental appDir in next config.
3. Create app/page.tsx and app/layout.tsx with boilerplate code.
4. Set segment config dynamic as error.
5. Deploy to Vercel

When you inspect the page in browser developer tools, x-vercel-cache will be MISS but it should be HIT after the first load.

[remorses]

To cache at CDN level you would need to set the Cache-control header (currently not possible)

I think when the docs talk about cache they are referring the the fetch cache and not the page html cache

[jmikrut]

I'm seeing this same thing at the moment with the new Payload CMS site that we're working on. Homepage cache is HIT but all our docs pages are MISS, no matter what we do.

[michaeljakob]

We have the same issue!

[ijjk]

Hi, this is due to experimental-edge (related export) being used which requires always being dynamic currently although is being investigated.

[neoromantic]

Seems like enormous problem?

We too have problem with out static site that is built on DatoCMS. So now, we have SSR on every hit instead of serving static webpages with ISR, as it was with Next12.

[junedkhatri31]

I am also facing similar issue. NextJS13 page returns cached data with x-vercel-cache: HIT header. I do not want it be cached.

[nabildroid]

same here! i'm using Middleware x-vercel-cache: MISS

[mxseev]

This seems to be fixed in Next 13.1

[vitaliemiron]

I have the same issue with [13.3.1-canary.17]

[swarchen]

Same issue with {"next": "13.4.1"}

[mattvb91]

This is still a massive issue. Ive lost the cache-control header control on my side. @ijjk im assuming its related to this experimental-edge. Is there any way for me to turn it off?

[carlosjunod]

I'm facing the same issue "next": "^13.4.12" any solution/work around.

[carlosjunod]

I'm facing the same issue "next": "^13.4.12" any solution/work around.

I was able to find a work around. in my case disabling Apollo Cache (not be optimal)

return new ApolloClient({
    link: ApolloLink.from([
      ....//
    ]),
    cache: new InMemoryCache(), // just deleting this is was giving me an error
    defaultOptions: {
      query: {
        fetchPolicy: "no-cache",
      },
    },
  });

[Darshan-Naik]

cache-control headers can be controlled through middleware.ts ref : https://nextjs.org/docs/app/building-your-application/routing/middleware

but its not supported through the page.tsx

[steven-tey]

Steven from Vercel here – I just made a minimal repro that confirms this – it looks like it's a bug that's caused when you use export const runtime = 'edge' on a page/layout.

Will work with the team to fix this! 🙏

[mattvb91]

@steven-tey is there any chance this issue is related?: https://github.com/vercel/next.js/issues/50914#issuecomment-1666455274

[steven-tey]

Closed this issue by accident, sorry about that! Re-opening 😅

[github-actions[bot]]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases. You can also use the GitHub templates (preferred) for App Router and Pages Router, or the CodeSandbox: App Router or CodeSandbox: Pages Router templates to create a reproduction with canary from scratch.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[leerob]

It would be helpful to verify this is still an issue on canary, especially since you no longer need the experimental appDir flag. Further, just for completeness, if you're building static pages you might not need to use the edge runtime anyway. Typically, I would recommend the edge runtime when you're wanting to dynamically render a page 👍

[samburgers]

for anyone else struggling with this, this currently works for dynamic page.tsx routes for super fast CDN delivered static pages

ie app/posts/[slug]/page.tsx

// Force static pages
export const dynamic = "force-static";

// CDN cache currently only works on nodejs runtime
export const runtime = "nodejs";

// Revalidate in seconds
export const revalidate = 60;

// If you want to pregenerate routes/pages at build time
// export async function generateStaticParams() {
//   return (await getPostSlugs()).map((slug) => ({ slug: slug }));
// }

interface PageProps {
  params: { slug: string };
}

export default async function Page({ params }: PageProps) {
  const data = await getPost(params.slug);

  return <div>{JSON.stringify({data})}</div>;
}

[balazsorban44]

This issue has been automatically closed because it wasn't verified against next@canary. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

[samburgers]

Fresh minimal repro on next@canary here:

https://github.com/samburgers/vercel-edge-test

Deployed: https://vercel-edge-test-liart.vercel.app/

Confirming the behaviour still appears to be:

Cache MISS

export const runtime = "edge";
export const dynamic = "force-static";

Cache HIT

export const runtime = "nodejs";
export const dynamic = "force-static";

Cache HIT

// default runtime is currently nodejs
export const dynamic = "force-static";

Definitely agree that static pages wouldn't benefit much from edge runtime, but folks that are chasing page performance may easily arrive at the first configuration, and have a difficult time understanding why the CDN cache isn't working at all. Possibly throwing a warning somewhere might help even (or some addition to the docs). Thanks again!

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.