Homepage can render raw pre-render payload when Cache Components are enabled
Summary
The default next.config.ts currently enables cacheComponents: true and experimental.cachedNavigations: true. On Next.js 16, cacheComponents opts the app into Cache Components / Partial Prerendering (PPR).
Because the chat shell reads request-time data such as auth() and cookies(), a Vercel deployment can serve the homepage as a raw pre-render payload instead of normal HTML. In that failure mode the request returns HTTP 200, but the browser renders text that starts with a multipart boundary and includes application/x-nextjs-pre-render, so the app appears not to open.
Why this happens
cacheComponents: trueenables Cache Components / PPR behavior in Next.js 16.experimental.cachedNavigations: truedepends on Cache Components being enabled.- The homepage/chat shell is not a purely static shell; it depends on request-time auth and cookie state.
- When the pre-render payload is served as the top-level document, the browser receives internal React/Next payload content instead of a standard HTML document.
Reproduction signal
A failing deployment response looks like this:
--<boundary>
content-type: application/x-nextjs-pre-render
...A healthy homepage response should instead start with:
<!DOCTYPE html>and the chat input (data-testid="multimodal-input") should be visible in the browser.
Suggested fix
Disable these PPR-related defaults in the template:
- remove
cacheComponents: true - remove
experimental.cachedNavigations: true
Users who intentionally want PPR can re-enable it after auditing request-time data access and Suspense boundaries according to the Next.js 16 Cache Components migration guidance.
Source: vercel/chatbot