A few builds ago, we quietly stopped defaulting to the old Next.js Pages Router and switched every new project to the App Router. It wasn't a trend thing — it changed how we structure a project from the very first commit, not just how the URLs get wired up.
Server components change more than you'd expect
The biggest shift is server components. Data that used to load client-side — spinner, waterfall of requests, the whole dance — now gets fetched on the server before a single byte reaches the browser. For a content-heavy marketing site, that alone makes a page feel noticeably faster to interact with, especially on the mid-range Android phones a lot of our clients' actual visitors are using.
It also changes how much JavaScript we ship in the first place. Instead of marking a whole page as client-side because one button needs `useState`, we can push that interactivity down to just the button itself and leave everything else static. Less JavaScript in the browser means less for a phone's processor to chew through — and that matters far more on a slow connection than it does on a developer's office fibre.
Layouts quietly fix a problem you didn't know you had
Nested layouts are the other win nobody talks about enough. A dashboard sidebar or a site's navbar doesn't re-render or re-fetch every time someone clicks to a new page — it just stays put, and only the content underneath swaps out. On a multi-page client site, that alone kills a whole category of janky page transitions we used to paper over with loading spinners.
It's not entirely painless, to be fair. Figuring out what should run on the server versus the client takes some getting used to, and a few older libraries built for the client-rendered era need extra care to wire up correctly. But for anything new we're starting, it's worth it — faster first loads, less JavaScript shipped, and a project that holds together better as it grows past a handful of pages.