Your content is probably in your JavaScript bundle

In a modern React framework, marking a component as client-side does more than enable state and event handlers. It moves that component, and its entire import graph, into the browser bundle. That second part is the one that surprises people.

If a client component imports a module, the bundler has to include that module. It does not know that you only wanted four fields from each entry, or that the remaining fields are long-form copy already rendered into the HTML by a server component elsewhere. It sees an import, so it ships the module.

This is why the problem concentrates in navigation. A header is the most likely component to be interactive — dropdowns, mobile menus, scroll behaviour — and it is also the most likely to want a list of your services or categories. It is also, fatally, mounted in the root layout, so whatever it drags in lands on every route in the application.

There is no error condition here. The code is correct, the types are correct, and the page renders exactly as intended. The only symptom is a number in a report nobody generates, which is why this survives code review indefinitely.

Framework build output does not help much either. It reports first-load JavaScript per route, but when the bloat is in the shared layout chunk, every route reports the same inflated figure. A uniformly high number reads as a framework baseline rather than as a bug, and teams conclude their floor is simply higher than they would like.

That misdiagnosis matters because it changes what people do next. Teams conclude the framework is heavy and start looking at rendering strategies or considering a rewrite, when the actual problem is one import statement.

You do not need a bundle analyser plugin for the first pass. Two techniques will find most of it.

The correct pattern is to keep the data module on the server and hand the client component only what it renders. A server component imports the module, maps it to the minimal shape, and passes that down. The heavy module never crosses the boundary.

In practice this means writing a small derivation next to your data — a function returning just the fields the navigation needs — and having the layout call it. The client component then declares a props type describing exactly what it consumes, which has a pleasant secondary effect: the boundary becomes self-documenting, and the next person to add a field has to think about whether it belongs on the client.

The saving is proportional to how much copy your content modules carry, which for a content-heavy marketing site is a lot. Ours held full funnel copy, FAQs and process steps for every service. Rendering that to HTML is the whole point; shipping it as JavaScript to render a dropdown is not.

A fix that relies on everyone remembering is not a fix. This is a mistake that looks completely reasonable in a pull request — someone needs a list of categories, imports the module, ships it — and reviewers have no signal that anything is wrong.

So we added a check to the build. It walks the source, finds every file carrying the client directive, and fails if any of them value-imports one of our content modules, with an error explaining the props alternative. It is roughly twenty lines and it makes a whole class of silent regression impossible.

That is the general lesson rather than anything specific to one framework. Performance problems that produce no error will always come back, because nothing in the normal development loop surfaces them. If you fix one, spend the extra twenty minutes making it detectable — otherwise you will find the same kilobytes again next year, and be equally surprised.