Next.js in 2026: honest practitioner take on what's working and what isn't

Next.js has evolved significantly in 2026, becoming both more powerful and more challenging to manage. The core features like React Server Components, Partial Prerendering, and the App Router are delivering measurable results but come with increased operational complexity due to less comprehensive documentation.

Server Components have become the default mental model for teams committed to Next.js, resulting in efficient content-fetching layers without requiring client JavaScript for certain paths. With server components, a marketing site built on Sanity as a CMS achieved an impressive first load JS size of just 38 kB, including GSAP animations on scroll.

Partial Prerendering (PPR) has proven reliable, implemented on two production sites since early 2026. The approach pre-renders a static shell (header, hero, static content) to the CDN edge and streams personalized or session-dependent content behind a Suspense boundary. This leads to a dramatically improved perceived load time compared to fully dynamic pages, with TTFB (time to first byte) under 40 ms on Vercel's edge network.

Turbopack, Next.js' new bundler in development, shows promising speed improvements. For a medium-complexity codebase, local cold start times dropped from approximately 8 seconds to under 2 seconds. Hot reloads for Tailwind class changes are nearly instantaneous, making development more efficient.

Metadata and image handling are now mature, with the generateMetadata function, next/image integrated with Sanity's CDN, and JSON-LD pattern using `<script type="application/ld+json">` in server components working seamlessly. This setup has greatly simplified SEO optimizations, which were more challenging with the Pages Router's Head API.

However, caching remains a complex area. The four-layer cache model—request memoisation, Data Cache, Full Route Cache, and Router Cache—was initially well-explained but causes bugs that are hard to diagnose in production. A common issue involves stale data persisting in the Router Cache for a 30-second window after a Sanity webhook triggers a revalidatePath, leading developers to add router.refresh() calls to mitigate this problem.

While the `use cache` directive in Next.js 15 helps make caching more explicit, it also necessitates auditing every fetch call, adding significant time to existing workloads.

Version upgrades bring noticeable costs. From Next.js 13 to 15, critical changes to routing, caching, and component boundaries have been required. Tracking the effort spent on upgrades per client engagement reveals that minor version bumps are usually short afternoon tasks, while major version upgrades with App Router changes typically take two to four days, including testing. These upgrade activities can strain maintenance contracts and may require separate billing considerations.

Next.js' rapid iteration brings both benefits and drawbacks. The powerful features like PPR, after(), and Incremental Static Regeneration, optimized for Vercel's infrastructure, are challenging to use when moving away from Vercel. The framework's complexity deters junior developers, as they often struggle with understanding React's concurrent model and asynchronous patterns.

Onboarding developers to Next.js 15 projects has required at least a week to resolve hydration errors and placement issues with `use client` directives. Despite these challenges, the author continues to choose Next.js for content sites and marketing builds, primarily due to the productive combination of React Server Components with Sanity CMS and the efficiency gained from PPR.

However, they emphasize the need to factor upgrade time into maintenance contracts, document Vercel dependencies explicitly, and avoid Next.js for projects that would benefit more from simpler alternatives like Remix.