The biggest source of confusion on a fresh App Router project is not routing or caching — it is deciding where each component lives. Teams type "use client" at the top of every file out of Pages Router habit, and the bundle quietly balloons. Server Components are the default for a reason: they ship zero JavaScript and can talk to your database directly.
Our rule is to start every component on the server and move it client-side only when forced. The forcing functions are concrete: an event handler, a browser-only API, React state or effects, or a library that touches window. If none apply, it stays on the server and the data fetch happens inline with async/await.
The trap is the boundary itself. A client component can still render server-rendered children passed as props.children, which keeps interactive shells thin while the heavy content stays on the server. Get that right and most of your tree stays free of client-side weight.
Key takeaways
- Default every component to a Server Component; add 'use client' only when a real client feature requires it.
- The four triggers for a client component are: event handlers, hooks (state/effects), browser APIs, and window-dependent libraries.
- Fetch data inside Server Components with async/await instead of useEffect plus a loading spinner.
- Pass Server Components into client components via the children prop to keep interactive wrappers thin.
- Never import a Server Component directly into a client file; compose them through props instead.
Practical checklist
- Audit your tree for files that have 'use client' but use no hooks, handlers, or browser APIs.
- Move data fetching out of client useEffect calls and into the nearest Server Component.
- Identify the smallest possible client boundary for each interactive widget and shrink to it.
- Add a bundle-size check in CI so a stray 'use client' on a large module is caught early.
What to do next week
Most 'Next.js feels slow' complaints we review trace back to client components doing work the server should own. If your App Router tree has grown a forest of 'use client' directives and the bundle keeps creeping up, we are happy to walk the boundaries with you in a short call and mark the components that can move back to the server.
How we work with clients at TechTrio
Every engagement at TechTrio Automation starts with a short discovery phase: we map your current stack, traffic, conversion paths, and operational bottlenecks. From there we propose a phased roadmap — quick wins first (tracking, analytics hygiene, performance, or a focused automation), then deeper builds (product modules, integrations, or marketing systems). Our teams in Ahmedabad and Mehsana collaborate closely with stakeholders in India, the UK, USA, Canada, and the UAE, so documentation, handoffs, and support hours stay practical.
