Static page with use cache still shows a Suspense fallback on Vercel

[pauksztello]

Summary

I have two static pages, both deployed to Vercel. Both load the same books from a function marked with "use cache" and cacheLife("max"). Neither page reads cookies, headers, or search params. Both are prerendered.

async function fetchLatestBooks() {
  "use cache"
  cacheLife("max")

  return db.books.findLatest()
}

async function LatestBooks() {
  const books = await fetchLatestBooks()

  return (
    <ul>
      {books.map((book) => (
        <li key={book.id}>{book.title}</li>
      ))}
    </ul>
  )
}

// app/with-suspense/page.tsx
export default function Page() {
  return (
    <main>
      <h1>With Suspense</h1>
      <Suspense fallback={<p>Loading books...</p>}>
        <LatestBooks />
      </Suspense>
    </main>
  )
}

// app/without-suspense/page.tsx
export default function Page() {
  return (
    <main>
      <h1>Without Suspense</h1>
      <LatestBooks />
    </main>
  )
}

On Vercel, a refresh of /with-suspense sometimes shows "Loading books...", then the books. A refresh of /without-suspense shows the books immediately, with no flash.

Why does the Suspense fallback show on a static page when the data is already cached? Should cached content on a static page be rendered without <Suspense>?

I am struggling to understand the difference and proper usage.

Additional information

No response

Example

No response

[HIRATRA]

I think the important distinction here is between the cached data and the rendering boundary created by <Suspense>.

"use cache" makes fetchLatestBooks() cacheable and, since it doesn't depend on request-time APIs, it can participate in prerendering/static-shell generation. cacheLife("max") also tells Next.js to keep that cached result available rather than treating it as short-lived dynamic work.

However, <Suspense> is still a rendering boundary. It doesn't mean “only show the fallback when the cache is empty”. It tells React/Next.js that the subtree is allowed to suspend and that the fallback is the UI for that boundary while the subtree isn't ready for the current render/stream.

So I wouldn't interpret the behavior as:

cache hit → Suspense should never render

I'd interpret it more as:

cached data can make the subtree prerenderable, but the Suspense boundary can still affect how that subtree is delivered/rendered.

In your example, the fact that /without-suspense never flashes while /with-suspense sometimes does is actually a useful signal: the database result itself is probably not the thing causing the visible delay. The difference is introduced by the Suspense boundary and how the prerendered/streamed RSC/HTML is consumed on that navigation.

If the books are genuinely part of the static shell and you don't need a loading state for them, I would simply remove the <Suspense> boundary:

export default function Page() {
  return (
    <main>
      <h1>Books</h1>
      <LatestBooks />
    </main>
  )
}

That matches the Cache Components model: use use cache for content you want included in the prerendered output, and use <Suspense> when you intentionally want a subtree to be deferred/streamed or need a fallback UI.

One thing I'd also verify in a minimal reproduction is whether you're testing with a hard refresh versus client-side navigation. Those exercise different cache/rendering paths, so reproducing the flash consistently in both cases would help determine whether this is expected Suspense behavior or an actual Next.js/Vercel rendering issue.

[pauksztello]

I'm talking specifically about hard refreshes. Some questions:

1. Without Suspense: Does the browser wait for the entire page (including data) before displaying anything?
2. With Suspense: Does the browser receive the page first and then the cached data gets streamed separately?
3. Does Suspense actually improve initial page load time in this case, or is there no performance difference?

I am still a bit confused.

[HIRATRA]

Yes — your questions are exactly the right way to look at it. I think my previous answer blurred two different cases, so let me be more precise.

For your specific example, assuming cacheComponents: true, fetchLatestBooks() is actually being prerendered, and you're testing a production build:

1. Without Suspense

If fetchLatestBooks() is inside a "use cache" scope with cacheLife("max"), Next.js can resolve that cached work during prerendering and include the resulting UI in the static shell.

So on a hard refresh, the browser should not need to wait for a separate request to your database before displaying the books. The HTML shell already contains the prerendered result.

In other words:

prerender → cached DB result → HTML shell → browser

This is different from an ordinary uncached async database query, which would block rendering until the query completes. Next.js explicitly recommends use cache when you want data to participate in prerendering.

2. With Suspense

If the component is actually deferred behind a Suspense boundary, then the model changes:

prerender → static shell + Suspense fallback → request-time work → streamed result

The fallback becomes part of the static shell, while the deferred content can be streamed when it becomes available. That's the main purpose of Suspense in this architecture.

So yes, conceptually your second interpretation is correct — but only if that subtree is actually being deferred rather than already being resolved as part of the cached/prerendered output.

3. Does Suspense improve the initial load here?

For this particular example, probably not.

If fetchLatestBooks() is already cached and included in the static shell, adding Suspense doesn't make the database query faster. The data is already available during prerendering.

Instead, Suspense can actually make the UX look worse if it causes the user to see:

Loading books...

before receiving content that could have been included directly in the initial HTML.

Suspense becomes a performance win when the work is genuinely request-time/slow and you want the rest of the page to become visible without waiting for that work. Next.js specifically describes this as allowing independent dynamic sections to render in parallel rather than blocking each other.

There's one important thing I'd check in your reproduction, though:

Are you testing with next dev, or with a production build (next build && next start)?

This matters a lot here. Next.js intentionally bypasses certain caches in development, and a hard refresh is one of the cases documented as potentially disabling the cache.

So I'd test the exact same two pages in production mode and compare:

• next build && next start
• hard refresh
• View Source / initial HTML
• Network → the initial document response
• whether Loading books... is already present in the initial HTML

If the production hard refresh still sends the Suspense fallback first even though the use cache result is definitely part of the prerendered output, then I think you've got a much more interesting Next.js behavior/bug to investigate, rather than simply normal Suspense streaming.

That distinction would also explain why the two versions behave differently without assuming that Suspense itself is making the cached database query slower.

[halilertekin]

I tried a minimal production reproduction of your two routes on Next.js 16.2.10 / React 19.2.1, with cacheComponents: true and a cached async function using cacheLife('max'). I replaced the database call with a 200 ms delay returning one book. Both routes were built as static pages, and the generated HTML contained the book in both cases. The Suspense version had a completed boundary, not the fallback:

<main><h1>With Suspense</h1><!--$--><ul><li>BUILD_TIME_BOOK_SENTINEL</li></ul><!--/$--></main>

I also checked three document requests per route through next start: each contained the book HTML and no <p>Loading books...</p> element. This was local with next build --webpack, not a reproduction of your Vercel deployment.

So I would not conclude that wrapping already-prerendered content in Suspense necessarily makes it stream separately on every hard refresh.

For your three follow-up questions:

1. Without Suspense: if the books are in the prerendered output, the document already contains them. There is no request-time database wait for that static response. This does not mean the browser must wait for every byte of the entire page before painting.
2. With Suspense: the boundary permits a fallback when its content is unresolved, but it does not require a separate request-time render. In the reproduction, the content was resolved during prerendering.
3. Performance: for already-prerendered books, adding a boundary does not make the query faster. Its useful benefit is letting surrounding content render while genuinely deferred work completes.

To distinguish a rendering issue from cache/revalidation behavior, I would compare:

• The installed Next.js version and next.config against the local reproduction.
• The built route HTML and the actual Vercel document response, including the rendered <main> (the fallback text can also appear in serialized scripts without being displayed).
• Whether the fallback is already present in the response or appears only after client code runs.
• Whether surrounding layouts/components access request-time data, whether content was invalidated, and whether server logs show a rendering error. React can emit a Suspense fallback when recovering from a server-render error, too.

A cached function's runtime cache and the prerendered route output are different things; serverless runtime cache persistence alone does not prove the route should display a fallback. See Next.js caching/prerendering, use cache runtime considerations, and React's server-render error recovery.

Could you share the exact Next.js version and a minimal reproduction/deployment? Your snippet alone did not produce the flash in the setup above, so removing Suspense may hide the symptom without explaining the deployment difference.