Next.js 15: what changed and what it means for your project
Next.js 15 explained: React 19, async request APIs, new caching defaults, Turbopack and what these changes mean for web projects and upgrades today.
In short: Next.js 15 mainly made caching predictable: fetch requests, GET route handlers and the client-side router cache are no longer cached by default. It also brought React 19, async request APIs such as cookies() and params, a stable Turbopack dev server and better self-hosting support. For existing projects that means an upgrade with a manageable but real set of breaking changes. Next.js 16 has since been released and builds on these changes.
Why Next.js 15 was an important release
With the App Router, Next.js had made aggressive caching the default. Data was cached without developers explicitly asking for it. That gave fast pages but also caused confusion: content went stale, and it was not always clear which cache layer was responsible.
Next.js 15 flipped that default. What gets cached is what you mark as cacheable. For teams and agencies, that means fewer surprises in production and behaviour you can understand by reading the code.
The most important changes
New caching defaults
fetch calls in server components are no longer cached automatically. If you want caching, you opt in, for example with cache: 'force-cache' or revalidation times. GET route handlers are dynamic by default too, and the client router cache no longer holds on to pages unasked.
After an upgrade this can mean more requests to your data sources at first. Check which data really changes rarely and cache it deliberately.
React 19
The App Router uses React 19. That brings Server Actions with useActionState, useFormStatus and useOptimistic, which make forms with loading states and optimistic updates much simpler. The new next/form component adds client-side navigation to forms.
Async request APIs
cookies(), headers(), draftMode(), params and searchParams are now asynchronous and must be awaited. This lets the framework prerender parts of a page before request data is known. An official codemod (npx @next/codemod) handles most of the migration.
Turbopack and developer experience
next dev --turbo made the Rust-based bundler Turbopack stable for development. Startup and hot reloads are noticeably faster in larger projects. Next.js 15 also supports typed configuration in next.config.ts and ESLint 9.
Other additions
The after() API runs work such as logging or analytics after the response has been sent to the user. instrumentation.js is stable and lets you hook up monitoring through onRequestError. Self-hosted setups get better control over cache headers, and image optimisation uses sharp automatically.
What this means for projects and clients
Planning upgrades
Upgrading from Next.js 14 to 15 is not a major project, but it is not trivial either. Async APIs, the new caching behaviour and possible library incompatibilities with React 19 all need testing. Good automated tests make the difference here.
Self-hosting in Germany
Next.js does not require Vercel. With standalone output and the improved cache settings, it runs well on your own servers or with German hosting providers. That matters for companies that care about hosting data in Germany.
Where things stand now: Next.js 16
Next.js 16 made Turbopack the default bundler for development and builds, and introduced an explicit caching model with Cache Components and the use cache directive. New projects should start on the current version. If you are still on 14, going through 15 lets you handle the breaking changes step by step. Our post on why we chose Next.js explains why it is our default framework.
Frequently asked questions (FAQ)
Do I need to upgrade from Next.js 14 to 15?
Older versions stop receiving security updates over time, so an upgrade is needed sooner or later. Plan it deliberately rather than rushing it after a security advisory.
Will pages get slower in Next.js 15 because less is cached?
Not necessarily. Static pages stay static; only data requests are no longer cached silently. With deliberate caching you get the same speed with less stale content.
Does the Pages Router still work?
Yes. In Next.js 15 the Pages Router is still supported and can still run on React 18. New features land almost exclusively in the App Router, though, so we recommend it for new projects; our article on server-side vs. client-side rendering covers which rendering strategy fits.
Is Next.js only worth it for large projects?
No. Company websites and small web apps also benefit from server-side rendering, good SEO and a single React and TypeScript stack.
Conclusion
Next.js 15 made the framework more predictable, and Next.js 16 continues in that direction. What matters most for a business is keeping the stack updated regularly and on a plan, so no upgrade turns into a major project.
If you want to start a new Next.js project or bring an existing one up to date, talk to us about web development.
Related posts
- Why React Remains the Safe Choice for Web Applications
Why React is still the solid choice for business applications: ecosystem, hiring, Server Components, React Native, and an honest look at its weaknesses.
- Full-stack development with TypeScript: a practical guide
Full-stack TypeScript explained: shared types for frontend and backend, runtime validation, database access, project structure and testing in one overview.
- How to Choose the Right Web Development Agency
How to recognise a good web development agency: references, technology, who does the work, contracts, and the questions to ask in the first conversation.
- Server-Side vs. Client-Side Rendering: When to Use Which
SSR, CSR, static generation and React Server Components compared: what each means for SEO, load time and interactivity, and when to choose which model.