The Next.js App Router

What actually changed

Moving from the Pages Router to the App Router is the biggest shift in Next.js since the framework was released. Layouts became shareable, nested loading states became the norm, and React Server Components moved most rendering work off the client.

Where your code runs now

• Components are Server Components by default; they render on the server and send only HTML.
• A bundle never contains what a component never has to run in the browser.
• "use client" is now an explicit opt-in, not the default.

Why data fetching got simpler

Pages used to need `getServerSideProps` or `getStaticProps` as a separate step. In the App Router you fetch directly inside a component, and Next.js deduplicates and caches requests. That removed a whole category of props-drilling bugs I used to fix.

Measuring the result

The most visible win was bundle size. The home page of the website this blog runs on dropped roughly 180 KB of JavaScript, and the Largest Contentful Paint improved from 2.4 seconds to about 1.1 seconds on throttled mobile.

When to keep a Client Component

• Interactive forms with optimistic updates.
• Components that listen to browser events like scroll.
• Anything using context for frequently changing state.

Server-first is a great default, but "use client" at the right boundary is still the right call. The skill is deciding where that boundary lives.

The takeaway

Think about the server/client boundary as a performance decision, not a fashion one. Rendering on the server by default, then pushing only what genuinely needs the browser, is a pattern that scales with your product.

Key takeaways

• Components render on the server by default, so keep use client a deliberate opt-in at the right boundary.
• Fetch data directly inside the component and let Next.js deduplicate and cache those requests.
• Measure the migration in bundle size and LCP; this blog's home page shed about 180 KB of JavaScript.
• Keep client components only for interactive forms, browser event listeners, and frequently changing context state.
• Treat the server and client split as a performance decision, not a passing fashion.

FAQ

Q: Do I still need getServerSideProps or getStaticProps in the App Router? A: No. In the App Router you fetch directly inside a component, and Next.js deduplicates and caches the requests for you. That removes a separate data-fetching step and a whole category of props-drilling bugs, and it keeps unnecessary JavaScript out of the page.

Q: How do I decide whether a component should be a Client Component? A: Ask where the work should run. Reserve use client for interactive forms with optimistic updates, components that listen to browser events such as scroll, and anything using context for frequently changing state. Everything else can stay on the server.