Maru@maru

Dev Hub

Translated from Korean

Next.js 15 Released: What’s Changed?

The release of the stable version of Next.js 15 has brought significant changes to the code patterns developers use daily. The most noticeable shifts are the move to asynchronous request-based APIs and changes to default data caching behaviors. As the synchronous calls and automatic cache behaviors we took for granted in previous versions have changed, it is essential for those running existing projects or planning new services to clearly understand these new operational mechanics.

Disabling Default fetch Caching and Predictable Data Flow

Up until Next.js 14, fetch requests were cached by default at build time or runtime without needing extra configuration. While this offered faster response times, many developers faced confusion when backend database updates were not immediately reflected on the screen.

Starting with Next.js 15, these defaults have been reversed. Now, fetch requests and GET route handlers are uncached by default. Fetching fresh data with every request is now the standard, so you only need to explicitly add options for endpoints where response caching is strictly necessary.

Cookies and Route Parameters Shifted to Asynchronous

The cookies(), headers(), and page props previously accessed via params and searchParams in Server Components or route handlers have all been converted to asynchronous Promise forms.

In traditional server-side rendering, the server had to pause and wait for the entire rendering process until request headers or cookies fully arrived. The Next.js team overhauled the architecture to separate request-dependent data from static components, allowing the server to prepare rendering in advance. To achieve this optimization, the point at which request information is read has been changed to an explicit asynchronous call.

This is the standard pattern for reading dynamic route parameters and cookies in Next.js 15.

tsx

params and cookies() must now be prefixed with await, and accessing properties directly using the old synchronous method will trigger a console warning. If you need to handle asynchronous params in Client Components, you can unwrap the Promise using React 19's use hook.

Turbopack Stabilization and Configuration File Improvements

Turbopack, designed to improve dev server speeds, has entered the official stabilization phase in development mode. Even in large codebases, page navigation and hot reloading react much faster than in the previous Webpack-based environment.

In line with the shift toward using TypeScript as the primary language, next.config.ts is now officially supported. Since type checking and auto-completion are applied to the configuration object, you can prevent configuration errors caused by typos in advance. The newly added <Form> component, which supports client-side navigation by default, also makes implementing search forms or filters much more concise.

Adoption Criteria and Migration Guide

If you are starting a new project, feel free to choose Next.js 15. The cache defaults are now more intuitive, reducing the time spent debugging data freshness issues, and you can take immediate advantage of the latest React 19 ecosystem features.

For migrating large-scale Next.js 14 projects currently in production, a gradual approach is safer. The shift to asynchronous request APIs affects type definitions and utility functions throughout your project. We recommend running the official migration tool, @next/codemod, to clean up syntaxes that can be automatically converted first, followed by checking whether key API calls that relied on global caching need the cache: 'force-cache' option.

Loading comments…