Start from responsibilities
A page often contains several different jobs: explaining a topic, reading public data, handling a button and responding to browser state. These jobs do not all need the same execution environment. In the App Router, decide which part needs interactivity, then place the client boundary around that part rather than adding use client to the entire page by habit.
Keep descriptive content straightforward
An article heading, publication date and paragraphs can remain in a Server Component. A filter box or image-processing form needs client state and event handlers. This separation keeps the architecture close to the user task. It also makes it easier to inspect which dependencies enter the client module graph instead of treating the whole application as one browser bundle.
Use a tool page example
A resizer route can read the tool record, generate metadata and render instructions on the server side. Its ToolRunner child handles the selected file, quality settings and download URL in the browser. The child receives a simple slug or configuration object. It does not need the entire article collection just to decide which input fields to show.
Respect the data crossing
Props crossing a server-to-client boundary need to be serializable in the supported model. Avoid passing arbitrary callbacks or database objects as if both sides share one runtime. Shape data deliberately: labels, options and identifiers are often enough. Keep browser APIs out of module initialization and server rendering, even in a Client Component that will later hydrate in the browser.
Do not equate client with browser-only HTML
Client Components can participate in prerendering for the initial load. The directive establishes a module boundary; it does not mean that every expression is safe to evaluate only in a browser. Access window, localStorage or document in an appropriate effect or event handler, and ensure the initial render is consistent enough to hydrate correctly.
Review the actual bundle and behavior
Inspect build output and the browser network panel after moving a boundary. Verify that the controls still work, page metadata remains available and direct navigation renders meaningful content. Optimize based on the dependencies and work you removed, not the number of server files you created. A boundary is useful when it clarifies responsibilities and reduces unnecessary client work without breaking the experience.
Further reading
Put the idea to work.
Explore free browser tools for images, text and developer workflows.