Next.js 16 Features: Turbopack Stable, Cache 2, and Async Params

Last week, a client told me that the build time for the 79,000 doctor profile pages we created for doktorbul.com had reached 40 minutes. The Webpack bundler was literally sweating. Right at that moment, Next.js 16 was released and Turbopack became stable. The build time dropped to 6 minutes. But the real story isn't just about speed: Next.js 16 completely rewrote the cache mechanism, modernized route handling with async params, and brought serious performance gains in production environments. In this article, I'll explain how Next.js 16 is used in real-world projects, which scenarios it works well in, and when you need to be careful. From the perspective of someone who writes code, not what you'll see in Vercel's marketing brochures.

Next.js 16 was released as beta in October 2024 and went stable in December 2024. The Vercel team specifically targeted build and runtime performance issues in large-scale applications. At FUTIA, I tested this version on AI-powered sites we built for Turkish brands. The result: game-changing for some projects, unnecessary complexity for others. Let's dive into the details.

Turbopack Stable: Is It Really 7x Faster Than Webpack?

Turbopack is a next-generation bundler written in Rust. It came experimentally with Next.js 15 and was declared production-ready with version 16. Vercel's claim: 700x faster hot reload than Webpack, 5x faster builds. In my real-world tests, these numbers turned out to be somewhat exaggerated, but there are still serious gains.

In the doktorbul.com project, there was a Next.js 14 application with 79,000 dynamic routes. Each doctor profile is a separate page: like /doktor/istanbul/diş-hekimi/ahmet-yilmaz. With Webpack, the production build time varied between 38-42 minutes. When we switched to Turbopack, this time dropped to 6 minutes. That's approximately 6.5x faster. Not 700x, but still tremendous.

On the hot reload side, it's truly striking. When you make a change in a component during development, the page reload takes 2-3 seconds with Webpack, while with Turbopack it's between 200-400 milliseconds. This saves hours when you change code 100 times a day.

However, Turbopack has some limitations. It can cause problems especially for projects using custom Webpack loaders. For example, in the italyanmutfagi.com project, we were using a custom loader to convert recipe content from Markdown to HTML. When switching to Turbopack, we had to rewrite this loader. We needed to find a Rust-compatible alternative or use a JavaScript fallback.

To activate Turbopack, you just need to add this to your next.config.js file:

module.exports = {
 experimental: {
 turbo: {
 // No longer experimental, directly active
 }
 }
}

In Next.js 16, you don't even need the experimental flag anymore, Turbopack is used by default. If you still want to use Webpack, you need to start the dev server with the --webpack flag.

Turbopack's Real Performance Metrics

In 6 different projects we tested at FUTIA, we got these results:

• Less than 10,000 pages: Almost no difference between Webpack and Turbopack (1-2 seconds)
• 10,000-50,000 pages: Turbopack 3-4x faster
• 50,000+ pages: Turbopack 5-7x faster
• Hot reload: 5-10x speedup in all cases

So don't rush to switch to Turbopack for small projects. But if you're doing programmatic SEO, generating thousands of pages, definitely switch.

Cache 2: Next.js's New Cache System

The most controversial feature of Next.js 16 is the Cache 2 system. Previously, Next.js automatically cached fetch requests. This caused unexpected results in some cases. Especially on sites producing dynamic content, users were seeing old data.

With Cache 2, Next.js completely changed cache behavior:

• Fetch requests are no longer cached by default
• If you want to cache, you need to specify it explicitly
• The revalidation mechanism has become more granular

This change is critical especially for projects using Server Components. In the memuratamalari.com project, we fetch public job postings from the ilan.gov.tr API. 50+ new postings are added every day. With the old cache system, sometimes postings appeared with a 5-10 minute delay. With Cache 2, we solved the problem by adding cache: 'no-store' to the fetch request:

async function getLatestIlanlar() {
 const res = await fetch('https://ilan.gov.tr/api/ilanlar', {
 cache: 'no-store' // Fresh data on every request
 });
 return res.json();
}

But beware: Cache 2 can cause performance drops in some projects. If your content doesn't change frequently, you need to explicitly specify caching:

async function getStaticContent() {
 const res = await fetch('https://api.example.com/content', {
 next: { revalidate: 3600 } // 1 hour cache
 });
 return res.json();
}

Another advantage of Cache 2 is better integration with React Server Components. You can now specify cache strategy at the component level. This is very useful especially on complex pages where some sections need to be static and others dynamic.

Using Cache 2 Correctly

In the diolivo.com.tr project, we applied this strategy on e-commerce product pages:

• Product description and images: 24-hour cache (revalidate: 86400)
• Stock information: No cache (cache: 'no-store')
• Reviews: 1-hour cache (revalidate: 3600)

This approach both maintained performance and ensured current data display. Result: 340% traffic growth over 6 months. Of course, this wasn't just from cache optimization, but cache strategy played an important role.

Async Params: Modernization of Route Handling

Before Next.js 16, we used the useParams hook to access dynamic route parameters. This was a client-side operation and couldn't be used in Server Components. With async params, server-side access to route parameters became possible.

Old method (Next.js 15 and earlier):

// app/doktor/[sehir]/[uzmanlik]/page.js
import { useParams } from 'next/navigation';

export default function DoktorPage() {
 const params = useParams();
 const { sehir, uzmanlik } = params;
 
 // Client-side rendering required
 return <div>{sehir} - {uzmanlik}</div>;
}

New method (Next.js 16):

// app/doktor/[sehir]/[uzmanlik]/page.js
export default async function DoktorPage({ params }) {
 const { sehir, uzmanlik } = await params;
 
 // Server-side rendering, SEO-friendly
 const doktorlar = await getDoktorlar(sehir, uzmanlik);
 
 return <div>{doktorlar.map(...)}</div>;
}

This change is critical especially for SEO. You can now perform server-side data fetching using route parameters. This means Google sees your page in its fully rendered state.

When we switched to async params on doktorbul.com, the average indexing time in Google Search Console dropped from 3 days to 1 day. Because now Googlebot could see the page content without running JavaScript.

Error Handling with Async Params

When using async params, proper error handling is important. For example, when an invalid city name is entered, instead of returning a 404, you might want to show the user a meaningful error message:

export default async function DoktorPage({ params }) {
 const { sehir, uzmanlik } = await params;
 
 const validSehirler = ['istanbul', 'ankara', 'izmir'];
 if (!validSehirler.includes(sehir)) {
 notFound(); // Next.js's built-in 404 handler
 }
 
 const doktorlar = await getDoktorlar(sehir, uzmanlik);
 return <div>...</div>;
}

This approach is also better for SEO. Google doesn't index 404 pages but can index a meaningful error page.

Partial Prerendering (PPR): The Future of Hybrid Rendering

With Next.js 16, Partial Prerendering (PPR) came experimentally. This feature allows some parts of a page to be rendered statically and others dynamically. So you can use both SSG (Static Site Generation) and SSR (Server-Side Rendering) within the same page.

For example, on recipe pages at italyanmutfagi.com, we used this structure:

• Recipe title, ingredients, instructions: Static (rendered at build time)
• Comments, like count: Dynamic (rendered on each request)

With PPR, when the page first loads, the static part is shown instantly, and the dynamic part loads in the background. This is good both for SEO (Google sees the static content) and user experience (page loads quickly).

To activate PPR:

// next.config.js
module.exports = {
 experimental: {
 ppr: true
 }
}

And at the component level:

// app/tarif/[slug]/page.js
import { Suspense } from 'react';

export default async function TarifPage({ params }) {
 const { slug } = await params;
 const tarif = await getTarif(slug); // Static
 
 return (
 <div>
 <h1>{tarif.baslik}</h1>
 <div>{tarif.malzemeler}</div>
 
 <Suspense fallback={<div>Yorumlar yükleniyor...</div>}>
 <Yorumlar tarifId={tarif.id} /> {/* Dynamic */}
 </Suspense>
 </div>
 );
}

PPR is especially useful for e-commerce sites. Product description can be static, stock information dynamic. This way, both fast loading and current data display are achieved.

Server Actions and Form Handling Improvements

Next.js 16 made Server Actions stable. Server Actions is a feature that allows you to process form data server-side. You can run server-side code directly from within a component without needing API routes.

In the kamupersonelhaber.com project, there's a form where users can leave their email for job posting notifications. Previously, this required writing a separate API route. With Server Actions, form handling is directly in the component:

// app/bildirim/page.js
import { revalidatePath } from 'next/cache';

async function kaydetBildirim(formData) {
 'use server';
 
 const email = formData.get('email');
 const kategori = formData.get('kategori');
 
 await db.bildirimler.create({
 email,
 kategori,
 createdAt: new Date()
 });
 
 revalidatePath('/bildirim');
}

export default function BildirimPage() {
 return (
 <form action={kaydetBildirim}>
 <input type="email" name="email" required />
 <select name="kategori">
 <option value="memur">Memur</option>
 <option value="işçi">İşçi</option>
 </select>
 <button type="submit">Kaydet</button>
 </form>
 );
}

Advantages of this approach:

• Less code (no API route)
• Better type safety (with TypeScript)
• Automatic CSRF protection
• Progressive enhancement (form works even without JavaScript)

Server Actions make things much easier especially in form-heavy applications. On diolivo.com.tr, we built cart recovery forms with Server Actions. Result: 18% higher form completion rate.

Next.js 16 Migration Strategy

Migrating to Next.js 16 isn't the same priority for every project. At FUTIA, we evaluate client projects based on these criteria:

1. Project size: If there are 10,000+ pages, migrate for Turbopack 2. Cache needs: If dynamic content is predominant, migrate for Cache 2 3. SEO priority: If you're doing programmatic SEO, migrate for async params 4. Development speed: If you make frequent code changes, migrate for hot reload

In the memuratamalari.com project, migration from Next.js 14 to 16 was completed in 3 days. Main changes:

• Cache strategy added to all fetch requests
• Dynamic routes migrated to async params
• Custom Webpack loader made Turbopack compatible

Result: Build time dropped from 12 minutes to 3 minutes, hot reload 10x faster, Google indexing time cut in half.

However, migration may not make sense for some projects. For example, for a blog site with fewer than 5,000 pages whose content doesn't change very frequently, migrating to Next.js 16 might create unnecessary complexity.

Things to Watch Out for During Migration

• Custom Webpack plugins: Check if they're compatible with Turbopack
• Third-party libraries: Test if they're compatible with Next.js 16
• Cache strategy: Review all fetch requests
• Environment variables: Some variables may behave differently
• API routes: Consider migrating to Server Actions

At FUTIA, we always test in a staging environment for 1-2 weeks before migration. Before going to production, we manually test all critical flows.

What Are We Doing with Next.js 16 at FUTIA?

When I founded FUTIA, I wanted not just to build sites for Turkish brands, but to set up AI-powered automation systems. Next.js 16 provides a perfect foundation for realizing this vision.

For example, the futia.net site itself runs on Next.js 16. We produced 2,000+ video content in 3 months, all with programmatic SEO. Thanks to Turbopack, each video page build takes 50 milliseconds. Thanks to Cache 2, video metadata updates every 5 minutes. Thanks to async params, Google sees every video page in its fully rendered state.

Another example: the Claude Haiku integration we built for doktorbul.com. Users can ask questions in natural language to search for doctors: "Can you recommend a good pediatrician in Kadıköy?". Claude Haiku parses this question, applies relevant filters, and returns results. This entire process is done with Next.js 16's Server Actions feature. Average response time is 800 milliseconds.

Doing these kinds of automations was much harder before Next.js 16. Without Server Actions, you had to write a separate API route for each automation. Without Cache 2, caching Claude responses was complex. Without Turbopack, building 79,000 pages took hours.

If you're also thinking about a project that's AI-powered, does programmatic SEO, and generates thousands of pages, Next.js 16 is currently the best choice on the market. As FUTIA, we set up these kinds of systems for Turkish brands from the Netherlands: site, automation, monthly maintenance, all included. If you'd like to discuss in detail, you can write email info@futia.net. Or email: info@futia.net.