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.