.next folder is bigger in Next.js 16

[diaz-hfc]

Summary

We have an app serving about 6k static pages, when using Next.js 15.x, our folder was about 3.5GB, now with Next.js 16 the folder is about 6.3GB.

We want to know if this is normal behavior of the new version, something we have to accept, or if something is wrong with our implementation.

Additional information

• Seeing exponencial increases in .next/server/app with 5.3GB.
• This occurs with just changing from 15.x.x to 16.0.3 in the package.json, reinstall dependencies and running the build again.
• Tried other things like the React Compiler, no effect in size, so non-related.
• No cache components in use.

This is the distribution of size across my .next folder.

du -sh .next/*
4.0K    .next/BUILD_ID
4.0K    .next/app-path-routes-manifest.json
900K    .next/build
4.0K    .next/build-manifest.json
567M    .next/cache
8.0K    .next/diagnostics
4.0K    .next/export-marker.json
4.0K    .next/fallback-build-manifest.json
4.0K    .next/images-manifest.json
8.0K    .next/next-minimal-server.js.nft.json
 40K    .next/next-server.js.nft.json
4.0K    .next/package.json
4.0M    .next/prerender-manifest.json
 84K    .next/required-server-files.json
120K    .next/routes-manifest.json
5.3G    .next/server
5.1M    .next/static
 12K    .next/trace
4.0K    .next/trace-build
  0B    .next/turbopack
 36K    .next/types

Example

No response

[icyJoseph]

What's the .next/server/app/ folder like? Don't share it! it is likely private and verbose too, but I wonder if there's .prefetch.rsc files, and what their sizes are? What about .body or .meta extensions, or .html?

What about .next/server/chunks? Is the bulk of size increase there?

Also, is this just running build again? As in npx next build or via package.json without changes? I see .next/turbopack - but is turbopack being used in the not-so-large build?

[diaz-hfc]

.next/server/app/* looks like is the biggest one with 5.3GB and the one that changes when building 15 vs 16, full of .segments files in folders depending on the route, most of them with files called _full, _head, _index, _tree, $c$slugs and so on. And also .html .meta and .rsc files there on the root.

This folder schema is completely different to what we have in V5, no .segments folders per path.

[icyJoseph]

And no cache components at all right? 🤔 Any chance to know what flags/options are active in your Next config file?

[diaz-hfc]

• No react compiler.
• No cache components.
• No experimental configs.
• No turbopack config.

[AntonGre]

We are experiencing the same issue with similar setup after upgrading to next 16.

App router with output: export - we are generating around 13,241 pages.

This is with using turpoback. The speed of build & deploy CI has decreased by about 30 % going from 7 mins to 10 mins after switching to nextjs 16 because of the increased build size.

• Next.js 15.x.x: 3.64 GB
• Next.js 16.0.3: 6.37 GB

[icyJoseph]

Right, so I had forgotten about this https://nextjs.org/blog/next-16#enhanced-routing-and-navigation

This more or less breaks each page into different building blocks, which means more files output. Not necessarily maps 1:1 to bigger output. It does look like there's a certain pattern that causes that to happen. I haven't identified what yet. Understandably a larger output folder can go anywhere, from unexpected but ok, to perhaps some associated business cost.

In your cases, is it more of an unexpected situation, but ok to proceed?

In terms of going forward, let's keep this open to collect more input/feedback and see what needs to be done. Hopefully we can try to figure out recommendations, if possible at all no promises, to reduce or mitigate the increase.

[AntonGre]

@icyJoseph

We’re discussing this internally, but at the moment the increased output size is preventing us from upgrading to Next.js 16.

During our investigation into the generated artifacts, we noticed that the issue appears to be related to how bigData is handled when returned from page.tsx. For example:

export default async function productPage({ params }: IPageProps<IProductParams>) {
  const { url, sku } = await params;
  const bigData = await getBigDataProps(url, sku);

  return <Page {...bigData} />
}

In this scenario, the contents of bigData appears both in .__full.txt and __PAGE.txt

[icyJoseph]

And in this case Page is a client component? A follow up would be, is it possible to select or reduce the amount of data passed? Cuz it sounds like all of that data is ending up in the client, or rather, being used in the final result?

[diaz-hfc]

In our case is not that bad, we are just going to be cautious by increasing the storage of our instances = almost no cost difference, but is still something we want to explore more.

[AntonGre]

yes page is a client component. It is definitely something i'll look into if/how much we can reduce the amount of data sent to the client.

[Umuts-Codes]

I understand your concern about the increased .next folder size after upgrading to Next.js 16. Here is an explanation and some recommendations to help clarify this behavior.

This behavior is expected in Next.js 16 due to changes in the build system and server-side optimizations.

Explanation

1. Build system changes

   • Next.js 16 includes additional metadata and intermediate build files to improve performance and incremental builds.
   • This leads to larger .next/server/app folder sizes compared to 15.x, especially for projects with thousands of static pages.

2. Server and cache files

   • output: standalone mode stores extra files for server execution.
   • .next/cache and other internal files may also contribute to the increased folder size.

3. Normal for large projects

   • For an application with 6,000 static pages, a .next folder size of 6GB+ is reasonable.
   • The size does not necessarily indicate a misconfiguration.

Recommendations

• Ensure that old builds are cleared before measuring folder size:

rm -rf .next
npm run build

• Review if all static pages are necessary to be prerendered. Consider using Incremental Static Regeneration (ISR) to reduce build size.
• Monitor updates from the Next.js team as future versions may optimize build output further.

Summary

The increased .next folder size in Next.js 16 is largely due to enhancements in the build process and server optimizations. It is generally expected and not indicative of an error or misconfiguration. Proper build management and optional use of ISR can help control folder growth.

[WayahHendra]

What are your thoughts on the performance and resource usage between Next.js 14 and Next.js 16? I’ve experienced fairly high RAM consumption with Next.js 15, so I’d like to know whether version 14 is more stable or version 16 is more optimized.

[Umuts-Codes]

Hi WayahHendra,

Memory and resource usage: 14 vs 16

• Versions 14 or 15 of Next.js could already exhibit high memory usage during build or dev‑server, especially for large projects. For example, build-time caching and bundling can consume several GB RAM if there are many dependencies or static pages. :contentReference[oaicite:1]{index=1}

• Upgrading to Next.js 16 brings architectural and build‑system changes: there’s more metadata, optimizations, and possibly different caching/build output behaviors this may lead to larger .next output and higher disk / memory usage in some contexts. :contentReference[oaicite:2]{index=2}

• That said — I’ve seen some reports that 16 improves development startup times, hot‑reload, build stability vs older versions under certain configurations. :contentReference[oaicite:3]{index=3}

What you should consider when choosing version 14 vs 16

• If you’re on a smaller project or want minimal overhead and memory footprint, staying on 14 / 15 might be lighter assuming you don’t need new 16‑specific features.

• If you use server components, newer features, or need long‑term support and optimizations from 16 -> might be worth upgrading — but watch memory / build output closely.

• Monitor your dependencies and bundle size carefully: heavy dependencies, many static, generated pages -> memory and .next size explode regardless of version.

My recommendation (for large‑scale apps)

• Use Next.js 16 if you benefit from its new features / optimizations but combine with good practices:

• Clear old builds before new builds (rm -rf .next),

• Use incremental/static regeneration instead of prerendering thousands of static pages,

• Monitor memory and tune build configuration (disable unnecessary caches/source maps if possible).

• If resource constraints are tight (low RAM server, dev machine), test both versions under your actual load see which behaves better.

I don’t think there’s a one‑size‑fits‑all. Next.js 16 does not automatically guarantee lighter and faster. It depends heavily on project size, config and usage. This is all I can explain.