For the last few client builds, we defaulted to the Next.js App Router instead of the older Pages Router — and it's changed how we structure projects from the first commit, not just how routing works.
The biggest shift is server components. Data fetching that used to happen client-side, with a loading spinner and a waterfall of requests, now happens on the server before a single byte reaches the browser. For content-heavy marketing sites, that alone noticeably improves how fast a page feels interactive, especially on the mid-range Android devices a lot of our clients' users are actually on.
It also changes how we think about client-side JavaScript. Instead of marking a whole page as a client component because one button needs `useState`, the App Router lets us push interactivity down to the smallest possible component and keep everything else static. Less JavaScript shipped to the browser means less to parse and execute, which matters more on slower connections than on a developer's fibre line.
Layouts are the other underrated win. Nested layouts mean a dashboard's sidebar or a marketing site's navbar doesn't re-render or re-fetch on every route change — it just persists, and only the page content inside it swaps out. For multi-page client sites, that alone removes a category of janky transitions we used to patch over with loading states.
It isn't friction-free. The mental model for what runs on the server versus the client takes adjustment, and some third-party libraries built for the old client-rendered world need extra care to use correctly. But for anything we're starting fresh, the trade-off is worth it — faster initial loads, less shipped JavaScript, and a project structure that scales better as a site grows past a handful of pages.