Wendeson Gomes
← Back to blogNext.js

Next.js 16 in practice: Cache Components day to day

Oct 14, 20268 min readby Wendeson Gomes

Cache Components, turned on with cacheComponents: true in next.config.ts, changes the rules: by default, Next.js now requires you to be explicit about what can become static HTML at build time and what's genuinely dynamic.

The first time I ran the build after enabling it, the budget page (this site's interactive quote chat) didn't break — because it doesn't read from any external API or cookies, just React state in the browser. Synchronous data coming from an imported module still counts as "predictable" and joins the static shell automatically.

Where I expected a headache and didn't get one: any async function that only reads a local file (fs.readFileSync, importing JSON) also counts as predictable. That means the blog's content can live in plain TypeScript files, with no 'use cache' or Suspense anywhere — the whole build stays static.

Where I would have had a headache, if I needed it: anything reading cookies(), headers() or searchParams has to sit inside a <Suspense> boundary, or the dev overlay points straight at the problem line. I'd rather find that out in development than in production.

The core idea is: the deeper in the component tree dynamic data lives, the more of the page can be served straight from the CDN as ready-made HTML. Worth designing components with that in mind from the start, not just when the build starts complaining.

Next up
How I scope a React freelance proposal
→