A single server reference is duplicated across all 1,600+ pages — server-reference-manifest scales O(refs × pages), reaching 170MB+ with output: 'standalone' (Next 16, Cache Components)

[TariqulislamTuhin]

This is performance/design feedback from a large production App Router app (not a minimal repro — the codebase is proprietary, but every number below is from a real next build). The ask: the server-reference-manifest scales O(server-references × pages) and reaches 170MB+, which seems like a manifest-encoding problem worth revisiting.

Environment

• Next.js 16.2.9 (Turbopack)
• output: 'standalone'
• cacheComponents: true (Cache Components / 'use cache')
• ~1,650 routes; heavy use of Server Actions ('use server') and 'use cache'

Measured artifact sizes (single production build)

artifact	size
.next/server/server-reference-manifest.js	182 MB
.next/server/server-reference-manifest.json	170 MB
duplicate copy in .next/standalone/.../server/server-reference-manifest.{js,json}	+352 MB
per-route server-reference-manifest.json (1,703 files)	~314 MB

≈ 1 GB of a 2.5 GB standalone image is just these manifests.

Root cause — it scales O(references × reachable-pages)

Each server-reference — every 'use server' action and every 'use cache' function ($$RSC_SERVER_CACHE_*) — gets a workers map with one object per page route that can reach it, and the full filename / exportedName strings are repeated verbatim in every object:

"<refId>": { "workers": {
  "app/(dashboard)/.../a/page": { "moduleId": 160630, "async": true, "exportedName": "x", "filename": "apps/web/src/.../x.ts" },
  "app/(dashboard)/.../b/page": { "moduleId": 432536, "async": true, "exportedName": "x", "filename": "apps/web/src/.../x.ts" },
  // ... repeated for ~1,600 routes that can reach this one reference
}}

Measured on this app:

• 1,847 distinct references → 589,349 total workers entries (~290 bytes each ≈ 170 MB).
• A single 'use cache' function is registered on 1,638 pages (≈ every route in the app).
• The split is ~51% 'use server' / ~49% 'use cache' — so adopting Cache Components makes this larger, not smaller, as more reads move to 'use cache'.

A reference becomes reachable from "every page" very easily — anything pulled in through a shared RPC/router client, a global provider, or a root layout — at which point its entry count jumps to ~N_routes.

Why this looks like a manifest-design issue, not just "a big app"

1. Redundant encoding. The same filename and exportedName strings are stored thousands of times instead of being interned. A string table + indices, or inverting the structure to reference → [pageIndex], would cut the size roughly an order of magnitude with no information loss.
2. Shipped twice. The multi-hundred-MB global manifest is copied verbatim into .next/standalone in addition to .next/server.
3. Super-linear growth. Because it is references × pages, it explodes precisely on the large apps that output: 'standalone' is meant for, and grows further as the unstable_cache → 'use cache' migration completes.

How to measure this on any large app

No minimal repro needed — any App Router app on output: 'standalone' + cacheComponents: true with many Server Actions / 'use cache' functions reachable from many routes will show it. Count workers entries:

python3 -c "import json;m=json.load(open('.next/server/server-reference-manifest.json'))['node'];print('refs',len(m),'entries',sum(len(v['workers']) for v in m.values()))"

Suggested directions

• Normalize the manifest: intern filename/exportedName into a lookup table, or invert to reference → [pageId] so each route and filename is stored once.
• Don't duplicate the global manifest into .next/standalone.
• Per-route lazy loading: rely on the already-emitted per-route manifests instead of also shipping one global O(refs × pages) blob.

Related

• .next folder is bigger in Next.js 16 #86320 — .next folder size growth in Next.js 16 (different cause: segment artifacts, not the reference manifest).

Is the O(refs × pages) encoding intended, or is there appetite for normalizing / de-duplicating this manifest? Happy to share more measurements.

[TariqulislamTuhin]

Update: opened a fix PR — #95242.

Root cause located in the Turbopack emitter (crates/next-api/src/server_actions.rs): filename and exportedName are stored both at the action-entry level (correct) and redundantly inside every per-page ActionManifestWorkerEntry. Since those strings are invariant per action and the worker map has one entry per reachable page, they get repeated O(actions × pages) times — the dominant cost of the 170MB+ manifest.

The PR drops the two redundant per-worker fields so worker entries are just { moduleId, async }, matching the webpack backend (which already emits them at the entry level only). It's consumer-compatible — the only first-party reader (get-server-action-by-id.ts) reads the entry-level values and types workers as Record<string, any>. Net diff is −5 lines.

Would appreciate a review / CI run — and if any manifest snapshot fixtures hard-code the per-worker fields, happy to update them.

[icyJoseph]

Good investigation, the PR is now approved.

[TariqulislamTuhin]

Thank you