Pages incorrectly classified as ISR

Help
1

Hello,

I’ve recently upgrade my website code from the Pages router to the App router.

After I deployed this change to Vercel, I can now see massive spikes in usage for Data Cache Reads / Edge Requests / Data Transfer etc.

I can see in the “Deployment Summary” that it specifies I now have 33 ISR functions (I think have 33 pages so that lines up), but I don’t understand WHY they are being classified as ISR and I haven’t been able to cause it to not recognize it as such.

I don’t make use of any fetch functions in any of my server side components and since I was just moving from Page to App router I made very simple page.tsx files that almost all of them look like:

export default function Page() {
    return (
        <div>
            <Suspense><SomeClientComponent/></Suspense>
        </div>
    )
}

I don’t know what to do to stop Vercel from thinking my pages are ISR. In my understanding they are static pages that hydrate client side.

Things I’ve tried:

  • I’ve removed my entire layout page and tried a build, still detected all pages as ISR.
  • I’ve changed my pages (which are server components) to simply have return <></> and still that page was treated as ISR.
  • I’ve removed every suspense boundary in my codebase, still all marked as ISR.
  • I’ve added export const revalidate = 604800; to a bunch of pages, no impact.
  • I’ve added “use client” on every file I have that has a fetch call even though it’s not part of any server components, still no luck.

My code is pretty complex/terrible, but it is open source and is available here: GitHub - Sludging/idleon-efficiency. Happy to provide context / links to relevant sections if needed.

Any help with understanding why my pages are classified as ISR would be greatly appreciated!

2

Hi @sludging. Adding export const dynamic = 'force-dynamic' in layouts would disable ISR by forcing dynamic pages. That could be combined with cache-control headers in next.config or middleware to opt in to CDN caching.

4

Hey, thank you for the response!

I’ve tried export const dynamic = 'force-dynamic' on my layout and now in my deployment summary I’m seeing 35 Functions when compared to before which I had 1 Functions and 33 ISR Functions so that seems to have helped, thank you very much!

I’m confused about the suggestion around Cache-Control headers in next.config as looking at the documentation it’s clearly called out as unsupported for pages: next.config.js Options: headers | Next.js. Can you clarify how I can opt into CDN caching? I want to cache the static portion of my pages for at least a week (probably even more since they won’t change at all between releases as it stands, only my dynamic content wrapped inside <Suspense> will).

Lastly, is it possible to get some clarification as to WHY my pages were flagged as ISR? As far as I’m aware I’m not using any data fetching methods so I’m confused why it’s not treated more like static content. Any information you can share will be appreciated in helping me understand this behaviour.

Thank you again for your help, looking forward to your continued assistance!

5

I ended up solving my own issue.

I gave the middleware approach a shot but it didn’t lead to any dersiable outcome, all the caching headers I put there were being ignored and I just ended up with 100,000s of middleware calls.

The solution in the end was very simple, treat my website as a Static Export.

Removing the middleware, removing ‘force-dynamic’, and adding output: 'export' to my next.config.js worked perfectly fine and dropped my usage significantly and obviously proved that my pages were not ISR as that’s called out as not-supported for Static Export.

So all in all I still don’t know WHY vercel considered my pages as ISR, but at least now I fixed the usage problem.

1 Like
6

Thanks for coming back with a solution, @sludging! I hope it helps other community members. :slight_smile:

7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.