DEV Community: Piotr Żarów

React Native vs Flutter in 2026: a practical comparison

Piotr Żarów — Fri, 16 Oct 2026 15:12:18 +0000

Originally published on devanddeliver.com.

Introduction

React Native's New Architecture has closed most of the performance gap that made Flutter the go-to for animation-heavy apps - and if your team already writes TypeScript and React, the case for switching languages has never been weaker. We cover the architecture shift, real pain points on both sides, and side-by-side code for the patterns you will actually build.

Versions covered: React Native 0.85.3 · Expo SDK 56 · Flutter 3.44.0
Last verified: May 2026

The short version

If your team writes JavaScript or TypeScript and already knows React: React Native. The knowledge transfer is direct, the ecosystem is enormous, and the New Architecture has erased most of the performance arguments that used to favour Flutter. You are building mobile apps with the same language, the same mental model, the same tooling, and - increasingly - the same people who build your web product.

If you are starting from zero with no existing React knowledge, care deeply about animation consistency at 120fps, or are building an app where pixel-perfect parity across iOS and Android is a hard requirement: Flutter. Dart is a faster learning curve than many engineers expect, and Flutter's rendering model removes an entire class of "why does this look different on Android" problems.

This is not a close race decided by benchmarks. It is a question of team fit and project requirements. For most product companies and agencies building TypeScript web stacks, React Native is the natural extension. Flutter is the right call when you are specifically optimising for what it is best at.

The fundamental difference

This is the one thing to understand before anything else.

React Native runs your JavaScript code in a JS engine (Hermes, by default since RN 0.70) and renders actual native UI components - UIButton on iOS, android.widget.Button on Android. Your code is JavaScript. Your UI is native. The New Architecture (mandatory as of RN 0.82) replaced the old async JSON bridge with JSI - direct C++ bindings that allow JS to call native code synchronously and hold references to native objects.

Flutter compiles Dart code to native ARM and x86 binaries and renders every pixel itself using the Skia/Impeller graphics engine. There are no native platform widgets involved. A Flutter Button is drawn on a canvas, not an iOS UIButton. This is why Flutter has perfect cross-platform pixel parity - and why it has to work harder to look native on each platform.

Neither approach is wrong. They have different trade-offs:

	React Native	Flutter
UI layer	Native platform widgets	Custom-rendered canvas
Cross-platform parity	Close, with platform quirks	Pixel-perfect
"Looks native"	Yes -uses actual native components	Approximated (very well)
Native component access	Direct	Via PlatformView (has overhead)
Language	TypeScript / JavaScript	Dart
Compilation	JS + native modules	Fully compiled to native

React Native in 2026: the New Architecture story

For several years, the main argument for Flutter over React Native was performance. The async bridge at the heart of the old architecture caused frame drops during complex animations and made synchronous native access impossible. That argument is no longer valid in 2026.

The timeline:

RN 0.76 (October 2024): New Architecture became the default for new projects
RN 0.82 (October 2025): Legacy Paper renderer fully removed - New Architecture is the only option
RN 0.84 (February 2026): Hermes V1 becomes default; precompiled binaries on iOS; legacy architecture code fully deleted
RN 0.85 (April 2026): Improved animation backend, DevTools improvements, Metro TLS support
Expo SDK 55 (February 2026): Legacy architecture support removed from Expo

The New Architecture ships four interconnected pieces:

JSI (JavaScript Interface) - replaces the JSON bridge with direct C++ bindings. JS can now call native methods synchronously and hold native object references, enabling patterns that were impossible before (like react-native-reanimated's UI-thread animations and react-native-vision-camera's frame processors).
Fabric - new concurrent renderer. Supports React 18/19 concurrent features: Suspense, transitions, startTransition. Layout calculations run on multiple threads instead of blocking the JS thread.
TurboModules - lazy-loaded native modules. The old architecture loaded every registered native module at startup regardless of whether you used it. TurboModules load on first access, improving startup time meaningfully.
Codegen - auto-generates type-safe C++ binding code from TypeScript specs. Write your native module interface in TypeScript, Codegen produces the platform glue code.

The practical result: React Native's animation and interaction performance on New Architecture is genuinely close to Flutter for the vast majority of application patterns. The gap remains at the extremes - very heavy custom animations, games, frame-by-frame camera processing - but for business apps, the New Architecture is good enough to make performance a non-issue in the RN vs Flutter decision.

Start with Expo

In 2026, the right way to start a new React Native project is Expo. The old distinction between "Expo managed" and "bare workflow" has largely dissolved. You can now:

Use Expo's managed workflow with full native code access via config plugins - no ejecting required for most customisations
Run EAS Build (Expo Application Services) for CI/CD, without maintaining your own macOS build agent for iOS
Ship over-the-air updates via EAS Update without app store review for JS-layer changes
Use Expo Router for file-based routing that mirrors Next.js conventions - if your team already knows Next.js, the mental model is identical

Expo SDK 56 targets React Native 0.85 and React 19.2.3. Legacy architecture support was removed in SDK 55 - there is no managed path back to the old bridge.

The only reasons to skip Expo in 2026: you have a highly custom native module that Config Plugins cannot accommodate, or you are integrating into an existing native app that already has its own build infrastructure.

Code comparison

VIRTUALISED LIST WITH PULL-TO-REFRESH

React Native:

import { useState } from 'react';
import { FlatList, RefreshControl, Text, View, StyleSheet } from 'react-native';

type Item = { id: string; title: string };

export default function ItemList({ items }: { items: Item[] }) {
  const [refreshing, setRefreshing] = useState(false);

  const handleRefresh = async () => {
    setRefreshing(true);
    await fetchItems(); // your data fetch
    setRefreshing(false);
  };

  return (
    <FlatList
      data={items}
      keyExtractor={(item) => item.id}
      renderItem={({ item }) => (
        <View style={styles.row}>
          <Text>{item.title}</Text>
        </View>
      )}
      refreshControl={
        <RefreshControl refreshing={refreshing} onRefresh={handleRefresh} />
      }
    />
  );
}

const styles = StyleSheet.create({
  row: { padding: 16, borderBottomWidth: 1, borderBottomColor: '#eee' },
});

Flutter:

class ItemList extends StatefulWidget {
  final List<Item> items;
  const ItemList({required this.items, super.key});

  @override
  State<ItemList> createState() => _ItemListState();
}

class _ItemListState extends State<ItemList> {
  Future<void> _handleRefresh() async {
    await fetchItems(); // your data fetch
  }

  @override
  Widget build(BuildContext context) {
    return RefreshIndicator(
      onRefresh: _handleRefresh,
      child: ListView.builder(
        itemCount: widget.items.length,
        itemBuilder: (context, index) {
          final item = widget.items[index];
          return ListTile(title: Text(item.title));
        },
      ),
    );
  }
}

Note: Flutter's ListView is not virtualised by default - ListView.builder is the lazy equivalent of RN's FlatList. For short, static lists ListView is fine; for long or dynamic lists always use ListView.builder.

FORM WITH VALIDATION

React Native - no built-in form handling; react-hook-form + zod is the community standard:

import { useForm, Controller } from 'react-hook-form';
import { z } from 'zod';
import { zodResolver } from '@hookform/resolvers/zod';
import { TextInput, Text, Pressable, View } from 'react-native';

const schema = z.object({
  name:  z.string().min(1, 'Name is required'),
  email: z.string().email('Enter a valid email'),
});

type FormData = z.infer<typeof schema>;

export default function SignUpForm() {
  const { control, handleSubmit, formState: { errors } } = useForm<FormData>({
    resolver: zodResolver(schema),
  });

  const onSubmit = (data: FormData) => console.log(data);

  return (
    <View>
      <Controller
        name="name"
        control={control}
        render={({ field: { onChange, value } }) => (
          <TextInput placeholder="Name" onChangeText={onChange} value={value} />
        )}
      />
      {errors.name && <Text>{errors.name.message}</Text>}

      <Controller
        name="email"
        control={control}
        render={({ field: { onChange, value } }) => (
          <TextInput placeholder="Email" onChangeText={onChange} value={value} keyboardType="email-address" />
        )}
      />
      {errors.email && <Text>{errors.email.message}</Text>}

      <Pressable onPress={handleSubmit(onSubmit)}>
        <Text>Sign up</Text>
      </Pressable>
    </View>
  );
}

Flutter - form validation is built into the SDK:

final _formKey = GlobalKey<FormState>();
final _nameController = TextEditingController();
final _emailController = TextEditingController();

Form(
  key: _formKey,
  child: Column(
    children: [
      TextFormField(
        controller: _nameController,
        decoration: const InputDecoration(labelText: 'Name'),
        validator: (value) =>
            (value == null || value.isEmpty) ? 'Name is required' : null,
      ),
      TextFormField(
        controller: _emailController,
        decoration: const InputDecoration(labelText: 'Email'),
        keyboardType: TextInputType.emailAddress,
        validator: (value) =>
            (value != null && value.contains('@')) ? null : 'Enter a valid email',
      ),
      ElevatedButton(
        onPressed: () {
          if (_formKey.currentState!.validate()) {
            // submit
          }
        },
        child: const Text('Sign up'),
      ),
    ],
  ),
)

Flutter's built-in Form + TextFormField + validator is a genuine ergonomic win. React Native requires three separate packages (react-hook-form, zod, @hookform/resolvers) to achieve equivalent functionality. Both patterns work well; Flutter's requires less setup and fewer dependencies.

REST API WITH LOADING STATE

React Native with TanStack Query (v5 - production standard for client-side data fetching):

import { useQuery } from '@tanstack/react-query';
import { FlatList, ActivityIndicator, Text } from 'react-native';

type Post = { id: number; title: string };

async function fetchPosts(): Promise<Post[]> {
  const res = await fetch('https://jsonplaceholder.typicode.com/posts?_limit=10');
  if (!res.ok) throw new Error('Network response failed');
  return res.json();
}

export default function PostsScreen() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['posts'],
    queryFn: fetchPosts,
  });

  if (isLoading) return <ActivityIndicator />;
  if (error) return <Text>Error: {error.message}</Text>;

  return (
    <FlatList
      data={data}
      keyExtractor={(post) => String(post.id)}
      renderItem={({ item }) => <Text>{item.title}</Text>}
    />
  );
}

Flutter with FutureBuilder (built-in) or Riverpod for more complex state:

Future<List<Post>> fetchPosts() async {
  final response = await http.get(
    Uri.parse('https://jsonplaceholder.typicode.com/posts?_limit=10'),
  );
  if (response.statusCode != 200) throw Exception('Failed to load posts');
  final List data = json.decode(response.body);
  return data.map((e) => Post.fromJson(e)).toList();
}

FutureBuilder<List<Post>>(
  future: fetchPosts(),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const CircularProgressIndicator();
    }
    if (snapshot.hasError) {
      return Text('Error: ${snapshot.error}');
    }
    return ListView.builder(
      itemCount: snapshot.data!.length,
      itemBuilder: (context, i) => ListTile(title: Text(snapshot.data![i].title)),
    );
  },
)

FILE-BASED NAVIGATION (EXPO ROUTER)

One of the biggest React Native improvements in recent years is Expo Router - file-based routing that works exactly like Next.js App Router:

app/
  _layout.tsx         # root layout (NavigationContainer, providers)
  (tabs)/
    _layout.tsx       # tab bar definition
    index.tsx         # Home tab → /
    profile.tsx       # Profile tab → /profile
  post/
    [id].tsx          # Dynamic route → /post/123

// app/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';

export default function TabLayout() {
  return (
    <Tabs>
      <Tabs.Screen name="index"   options={{ title: 'Home' }} />
      <Tabs.Screen name="profile" options={{ title: 'Profile' }} />
    </Tabs>
  );
}

// app/post/[id].tsx
import { useLocalSearchParams } from 'expo-router';

export default function PostScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();
  return <Text>Post {id}</Text>;
}

If your team already works with Next.js, this is almost zero learning curve.

Performance

THE HEADLINE: THE GAP IS MOSTLY CLOSED

Flutter still has a raw advantage in sustained 60/120fps animations. Because it draws every pixel itself via Impeller (the newer Skia replacement, default on iOS since Flutter 3.10 and Android since 3.16), there is no negotiation with the platform's native rendering pipeline. Frame timing is consistent.

React Native with New Architecture is very close for typical application patterns. The JSI bridge is effectively zero-cost for most operations. react-native-reanimated v4 (the animation library) runs entirely on the UI thread via worklets - it does not touch the JS thread during animation. For the ~95% of apps that do not involve custom particle systems or frame-by-frame video processing, React Native's performance is not a limiting factor.

Where Flutter still pulls ahead: applications with long lists of complex custom-rendered items, multi-step transitions with many animated properties, or intensive canvas work. Where React Native has the edge: anything that embeds native platform components - WebViews, native maps, video players. Flutter wraps these in a PlatformView, which renders through a separate texture layer and can cause jank or visual glitches in complex layouts.

APP SIZE

Release build sizes vary by app complexity, but published benchmarks put minimal apps at:

	Android (AAB)	iOS (after App Thinning)
React Native (bare, Hermes)	~7-10 MB	~20-25 MB
Flutter	~5-8 MB	~16-22 MB

Flutter edges ahead on baseline size because there is no JS bundle and no Hermes runtime to ship. In practice, as app complexity grows both frameworks converge - the difference becomes negligible against the size of your own code, assets, and libraries.

React Native's Hermes engine compiles JavaScript to .hbc bytecode at build time rather than at runtime. This means zero JS parsing on the device at startup - a significant improvement to cold start time and a 3-7 MB reduction in effective bundle size compared to shipping raw JS.

Ecosystem

REACT NATIVE HAS THE DEEPER ECOSYSTEM

The React Native ecosystem benefits from a decade of JavaScript library development. Almost anything you need has a well-maintained package:

Use case	React Native	Flutter
Animation	react-native-reanimated v4.3.1	Built-in AnimationController
Camera + ML	react-native-vision-camera v5.0.10 (frame processors via worklets)	camera plugin (less capable)
Navigation	expo-router (file-based) / @react-navigation v7	GoRouter (officially recommended)
State management	zustand v5, jotai, redux	Riverpod, Provider, Bloc
Server state / caching	@tanstack/react-query v5	Riverpod + custom (no direct equivalent)
Forms	react-hook-form v7 + zod	Built into SDK
Canvas / 2D	react-native-skia	Built-in (Flutter is Skia-native)
OTA updates	EAS Update (Expo)	Code Push (third-party, or Shorebird)
CI/CD	EAS Build	Codemagic, GitHub Actions

Flutter's ecosystem is smaller but growing fast. The packages that exist are generally well-maintained and backed by Google. The gap that matters most in practice: server-state caching (TanStack Query has no Flutter equivalent with comparable maturity) and camera/ML processing (vision-camera's frame processor worklets are a genuinely unique capability with no Flutter match).

Flutter's built-in advantage: Form, TextFormField, DatePicker, Drawer, and the full Material 3 and Cupertino widget libraries are part of the SDK with zero third-party dependencies.

Real pain points

REACT NATIVE

Platform divergence adds up. Even with a shared codebase, you will write Platform.OS === 'ios' branches. Keyboard behaviour, shadow rendering, font rendering, scroll physics, StatusBar behaviour - iOS and Android handle all of these differently. In a real production app, 15–25% of your UI code will have platform-specific paths. This is rarely discussed in comparison articles.
Metro bundler slows down on large projects. Cold start of the Metro bundler on a project with 1,000+ modules can take 30-60 seconds. Hot reload is fast once running, but that initial start is a daily tax on developer experience. There is active work on this (faster resolver, lazy bundling) but it has not been fully solved.
The New Architecture migration was painful. RN 0.82 removed the legacy bridge entirely. Teams that relied on third-party native modules found that many packages were slow to ship TurboModule support. The findNodeHandle API was removed silently, breaking code that used it. Shadow thread removal changed layout timing in ways that caused subtle animation bugs. If you have a brownfield RN app older than 2024, budget 2-8 weeks for the migration depending on how much custom native code you have.
Native crash debugging is immature. When Hermes or JSI crashes at the native layer, symbolication - mapping the crash back to readable source - requires extra tooling and is less reliable than the native iOS/Android crash reporters you would get with Swift or Kotlin.

FLUTTER

Code Push does not exist natively. React Native can ship JS-layer updates over the air without an app store review via EAS Update. Flutter has no official equivalent - Shorebird is the main third-party option, but it is not yet as mature or widely adopted. If OTA deployment is a requirement, this matters.
Dart is a hiring constraint. The Dart talent pool is smaller than JavaScript's by a large margin. Flutter developers exist, but if you need to hire quickly or integrate with a team of existing web developers, the onboarding cost is real.
PlatformView jank is a known issue. Embedding native components (Google Maps, WebView, video players) inside Flutter layouts triggers PlatformView, which renders through a separate texture layer. On Android in particular, this causes visible frame drops when animating around a PlatformView or scrolling it in a list. The Flutter team has worked on this for years and it has improved, but it is not fully solved.
"Looks native" requires effort. Flutter renders its own widgets. The default Material 3 widgets look polished and consistent, but they look like Material, not like iOS. Building a truly platform-native feel (Cupertino on iOS, Material on Android) requires maintaining two widget trees or a library that handles it. React Native's use of actual native components gives you platform-native appearance for free.

The language question: TypeScript vs Dart

Dart is not a difficult language. Engineers with JavaScript backgrounds typically become productive in Dart within a week. It is strongly typed, garbage collected, has async/await, and its syntax is closer to Java/TypeScript than to anything exotic.

That said, the language switch has real costs for a JavaScript team:

No npm. Pub.dev is Flutter's package registry. The ecosystem is smaller and there is no path to reusing your existing JS libraries.
No shared code with your web stack. If your web app is in Next.js and your mobile app is in Flutter, you maintain two separate codebases in two languages.
Your React knowledge does not transfer. Component model, hooks, context, state management - all of it needs to be relearned in Flutter's widget/State/Riverpod model.

React Native's answer to this is direct: your TypeScript, your React patterns, your npm packages, and increasingly your team. A Next.js developer can be productive in a React Native + Expo Router project within hours. The mental model is the same; only the output primitives differ.

Choosing between them

React Native + Expo is the right choice when:

Your team writes TypeScript and knows React
You want to share developers, tooling, and potentially code between your web and mobile products
You need the depth of the npm ecosystem - particularly for data fetching, state management, or device integrations
OTA updates matter (shipping JS fixes without app store review)
You want file-based routing that mirrors your Next.js conventions
You are building a business application where "good enough performance" is genuinely good enough

Flutter is the right choice when:

You are building from scratch with no existing React investment
Your app has intensive custom animation requirements or needs consistent 120fps on all supported devices
Pixel-perfect cross-platform parity is a hard requirement
You are targeting desktop or web in addition to mobile (Flutter's multi-platform story is more mature than RN's)
You are comfortable hiring specifically for Dart and building a Flutter-specialised team

The choice that requires more thought: a company with a large React/TypeScript web team that wants to add mobile. On paper React Native is obvious - leverage the existing team. In practice, if the mobile product has heavy animation requirements or the team is willing to invest in learning Dart, Flutter may deliver a better long-term result. Neither answer is wrong, but it is worth making the decision deliberately rather than defaulting to RN because JavaScript is familiar.

What's coming

React Native 0.85's improved animation backend and RN 0.84's Hermes V1 default continue the performance trajectory. The next significant milestone to watch: bridgeless mode becoming fully stable (the New Architecture can now also run without any bridge code compiled in, reducing binary size further).

Flutter's 2026 roadmap includes three more releases: 3.47 (August), 3.50 (November). The most watched open issue is code push / OTA updates (#14330, the most upvoted open issue in the Flutter repo) - if Flutter ships a first-party OTA solution, it removes one of React Native's clearest practical advantages.

Agency take

For most of our clients - product companies and agencies building TypeScript web stacks that need a mobile app - React Native with Expo is the recommendation. The engineering team already knows the language and the framework. The tooling is production-ready. Expo's managed workflow has removed most of the native build headaches that plagued RN projects for years. And the New Architecture has made the performance arguments against RN largely obsolete for business apps.

Flutter earns a serious look when the client's requirements push to the edges of what React Native handles well: sustained heavy animation, a dedicated mobile-only team willing to invest in Dart, or a product that genuinely needs pixel-perfect cross-platform rendering.

The old answer - "Flutter for performance, React Native for JavaScript teams" - is less accurate in 2026 than it used to be. The New Architecture closed the gap. What remains true: React Native fits into a JavaScript organisation without friction. Flutter requires commitment. Both can build excellent apps. Choose the one your team can maintain confidently five years from now.

Need help with this in your product? Our senior team builds React Native apps for iOS and Android. See how we built Hemfrid's employee app while the legacy app stayed live, or book a free 15-minute call.

NestJS vs Express vs Fastify in 2026: a practical comparison

Piotr Żarów — Fri, 16 Oct 2026 15:12:18 +0000

Originally published on devanddeliver.com.

Introduction

Raw throughput benchmarks make NestJS look slow - but 17,000 requests per second is 1.5 billion requests a day, and the real question is whether your codebase can handle your team. We ran the benchmarks ourselves and made the case for NestJS as the professional default for Node.js backends in 2026.

Versions covered: Express 5.2.1 · Fastify 5.8.5 · NestJS 11.1.24
Benchmarks: Node.js 24.15, Apple Silicon, 100 connections, 20s
Last verified: May 2026

The short version

NestJS is the right default for professional backend work in Node.js in 2026. It is the only one of the three that gives you a complete application framework - dependency injection, module system, guards, interceptors, lifecycle hooks, and a testable architecture out of the box. Every serious team building a multi-module API in TypeScript will be better served by NestJS than by assembling the same things manually from Express middleware.

Fastify is the right choice when raw throughput is a first-class requirement - IoT ingestion, public APIs handling tens of thousands of requests per second per instance, or anything where cold start time matters (serverless, edge). It is an excellent HTTP server. It is not an application framework.

Express is the right choice when you are prototyping, maintaining an existing codebase, or need a thin layer with zero opinion. It is the foundation the Node.js ecosystem was built on. In 2026 it is still the right tool for small, focused services.

The mistake is comparing all three on throughput benchmarks and concluding NestJS is the slowest. NestJS trades a portion of raw req/s for something more valuable at scale: a consistent, testable, team-friendly application architecture. If your server is handling 20,000 requests per second, it is serving over 1.7 billion requests a day. The question is not whether NestJS can handle your load. It almost certainly can. The question is whether your codebase can handle your team.

First, understand what each one is

Express is a routing layer with middleware. That is almost all it does - deliberately. It gives you (req, res, next) and gets out of the way. Express v5 (the current stable) arrived in late 2024 after years in beta and fixed the most common footgun: unhandled promise rejections now propagate to your error middleware automatically. Everything else is largely the same as it has been for a decade. That is partly a strength: the Express mental model is universal, its middleware ecosystem is enormous, and there are no surprises.

Fastify optimises for throughput. Its two architectural choices - a compiled JSON serializer and AJV-based schema validation baked into the router - make it the fastest mainstream Node.js HTTP framework. It uses a plugin system with encapsulation rather than Express's flat middleware chain. The result is a framework that is opinionated about performance and relatively unopinionated about everything else: you still compose your own structure, your own testing patterns, your own cross-cutting concerns.

NestJS is an application framework that runs on top of Express or Fastify and solves the problems those frameworks leave to you. It brings Angular-style architecture to the backend: a dependency injection container, a module system, decorators for controllers and services, guards for auth, interceptors for cross-cutting logic, exception filters for consistent error handling, and a TestingModule API that makes unit testing injectable services trivial. NestJS does not compete with Express or Fastify on throughput. It uses them as its HTTP layer and adds everything a production application actually needs on top.

NestJS v11 defaults to the Express v5 adapter. It supports the Fastify adapter natively via @nestjs/platform-fastify.

Framework snapshots

	Express 5.2.1	Fastify 5.8.5	NestJS 11.1.24
Node.js minimum	18+	20+	20+
TypeScript	Optional	Optional	First-class
DI container	❌	❌	✔️
Module system	❌	❌	✔️
Built-in validation	❌	JSON Schema (AJV)	class-validator / Pipes
Auth pattern	Middleware	Plugin hook	Guard (composable, testable)
OpenAPI / Swagger	Manual / plugin	Manual / plugin	Auto-generated from DTOs
Testing utilities	None built-in	None built-in	TestingModule built-in
Microservices support	❌	❌	(gRPC, Kafka, RabbitMQ)
Weekly npm downloads	107M¹	7.9M	10.7M
GitHub stars	~69k	~33k	~67k

¹ Express downloads are heavily inflated by transitive dependencies - NestJS itself pulls Express under the hood. The intentional install numbers are closer to 10-15M per week.

What NestJS gives you that the others do not

Before the code comparison and benchmarks, it is worth being explicit about what you are actually getting with NestJS. These are not marginal conveniences - they are the reason teams choose it.

DEPENDENCY INJECTION AND TESTABILITY

In Express or Fastify, services depend on each other through imports, globals, or manual wiring. In NestJS, every service declares its dependencies and the DI container wires them at startup. The payoff is in testing:

// Test a service in complete isolation - no real database, no HTTP server

const module = await Test.createTestingModule({
  providers: [
    UsersService,
    {
      provide: PrismaService,
      useValue: { user: { findUnique: jest.fn().mockResolvedValue(mockUser) } },
    },
  ],
}).compile();

const usersService = module.get<UsersService>(UsersService);

Three lines to swap the real Prisma client for a mock. This pattern works across your entire application - any service, any dependency, no special wiring required. Achieving equivalent test isolation in Express means passing dependencies through constructors manually everywhere or introducing a third-party DI library yourself.

A MODULE SYSTEM THAT SCALES WITH YOUR TEAM

NestJS organises code into modules with explicit import/export boundaries. UsersModule exports UsersService. AuthModule imports UsersModule to access it. If AuthModule does not import UsersModule, it cannot access UsersService - the DI container enforces the boundary at startup.

This matters less on a solo project. It matters a lot when four developers are working on the same codebase and "which service can I use from this module" has a clear, enforced answer instead of "just import the file and hope nothing breaks."

GLOBAL CROSS-CUTTING CONCERNS - WRITE ONCE, APPLY EVERYWHERE

// main.ts - configure once

app.useGlobalPipes(new ValidationPipe({ whitelist: true }));
app.useGlobalGuards(new JwtGuard());
app.useGlobalFilters(new AllExceptionsFilter());
app.useGlobalInterceptors(new LoggingInterceptor());

Every route in the application now validates input, enforces JWT auth, formats errors consistently, and logs requests - without touching a single route handler. In Express, the equivalent requires adding middleware to every router, trusting that someone remembered, and hoping the chain is in the right order.

Individual routes can opt out or add their own guards without disturbing the global defaults:

@Get('health')
@Public() // custom decorator to skip JwtGuard on this route
healthCheck() { return { status: 'ok' }; }

OPENAPI DOCUMENTATION GENERATED FROM YOUR DTOS

Install @nestjs/swagger, add a few decorators to your DTOs, and NestJS generates full OpenAPI documentation automatically. No separate schema file, no manual sync, no risk of docs drifting from the actual API:

import { ApiProperty } from '@nestjs/swagger';

export class CreateUserDto {
  @ApiProperty({ example: 'Alice' })
  @IsString()
  name: string;

  @ApiProperty({ example: 'alice@example.com' })
  @IsEmail()
  email: string;
}

The same DTO that validates incoming requests also documents the API endpoint. One source of truth.

THE BROADER ECOSYSTEM

NestJS ships first-party packages for the things every real backend eventually needs: @nestjs/config (configuration with environment validation), @nestjs/schedule (cron jobs), @nestjs/bull (queues via BullMQ), @nestjs/event-emitter (in-process events), @nestjs/microservices (gRPC, Kafka, RabbitMQ, NATS with the same Guards/Interceptors pattern as HTTP). These are all maintained by the NestJS core team, follow the same conventions, and require no architectural rethinking to introduce into an existing app.

Mental model: how a request moves through each

Express:

request → middleware A → middleware B → route handler → response

Everything is a function with (req, res, next). You own the chain.

Fastify:

request → onRequest hooks → JSON Schema validation → handler → serialization → response

Validation runs at the framework level before your handler. Invalid bodies are rejected automatically.

NestJS:

request → middleware → guards → interceptors (before) →
  pipes (transform + validate) → controller → service →
    interceptors (after) → exception filters → response

Each layer has one job. Guards decide whether a request is allowed through. Pipes transform and validate the body. Interceptors handle logging, caching, response shaping. Exception filters handle every possible error in one place. You configure each layer once globally, then override per-route only when you need to.

Code comparison: CRUD + validation

The same endpoint in each framework - create a user, list users, get by ID, delete by ID. TypeScript throughout.

EXPRESS V5 + ZOD

// app.ts
import express, { Request, Response, NextFunction } from 'express';
import { z } from 'zod';

const app = express();
app.use(express.json());

const users: { id: number; name: string; email: string }[] = [];
let nextId = 1;

const CreateUserSchema = z.object({
  name: z.string().min(1),
  email: z.string().email(),
});

app.get('/users', (_req: Request, res: Response) => {
  res.json(users);
});

app.post('/users', (req: Request, res: Response) => {
  const result = CreateUserSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ errors: result.error.flatten() });
  }
  const user = { id: nextId++, ...result.data };
  users.push(user);
  res.status(201).json(user);
});

app.get('/users/:id', (req: Request, res: Response) => {
  const user = users.find(u => u.id === Number(req.params.id));
  if (!user) return res.status(404).json({ message: 'User not found' });
  res.json(user);
});

app.delete('/users/:id', (req: Request, res: Response) => {
  const idx = users.findIndex(u => u.id === Number(req.params.id));
  if (idx === -1) return res.status(404).json({ message: 'User not found' });
  users.splice(idx, 1);
  res.status(204).send();
});

// Express v5: async errors now propagate to error middleware automatically
app.use((err: Error, _req: Request, res: Response, _next: NextFunction) => {
  res.status(500).json({ message: err.message });
});

app.listen(3000);

FASTIFY V5 (BUILT-IN JSON SCHEMA)

// server.ts
import Fastify from 'fastify';

const app = Fastify({ logger: false });

const users: { id: number; name: string; email: string }[] = [];
let nextId = 1;

const bodySchema = {
  type: 'object',
  required: ['name', 'email'],
  properties: {
    name:  { type: 'string', minLength: 1 },
    email: { type: 'string', minLength: 3 },
  },
  additionalProperties: false,
};

app.get('/users', async () => users);

app.post('/users', { schema: { body: bodySchema } }, async (request, reply) => {
  const body = request.body as { name: string; email: string };
  const user = { id: nextId++, ...body };
  users.push(user);
  return reply.status(201).send(user);
});

app.get<{ Params: { id: string } }>('/users/:id', async (request, reply) => {
  const user = users.find(u => u.id === Number(request.params.id));
  if (!user) return reply.status(404).send({ message: 'User not found' });
  return user;
});

app.delete<{ Params: { id: string } }>('/users/:id', async (request, reply) => {
  const idx = users.findIndex(u => u.id === Number(request.params.id));
  if (idx === -1) return reply.status(404).send({ message: 'User not found' });
  users.splice(idx, 1);
  return reply.status(204).send();
});

app.setErrorHandler((error, _request, reply) => {
  reply.status(error.statusCode ?? 500).send({ message: error.message });
});

app.listen({ port: 3000 });

NESTJS V11 (CLASS-VALIDATOR + VALIDATIONPIPE)

// users/dto/create-user.dto.ts
import { IsEmail, IsString, MinLength } from 'class-validator';

export class CreateUserDto {
  @IsString()
  @MinLength(1)
  name: string;

  @IsEmail()
  email: string;
}

// users/users.controller.ts
import { Controller, Get, Post, Delete, Param, Body, HttpCode } from '@nestjs/common';
import { CreateUserDto } from './dto/create-user.dto';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }

  @Post()
  create(@Body() dto: CreateUserDto) {
    return this.usersService.create(dto);
  }

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(+id);
  }

  @Delete(':id')
  @HttpCode(204)
  remove(@Param('id') id: string) {
    return this.usersService.remove(+id);
  }
}

// main.ts - register ValidationPipe globally once; every route gets it automatically
import { NestFactory } from '@nestjs/core';
import { ValidationPipe } from '@nestjs/common';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe({
    whitelist: true,              // strips unknown properties automatically
    forbidNonWhitelisted: true,   // returns 400 on unknown properties
  }));
  await app.listen(3000);
}
bootstrap();

What the comparison shows: Express and Fastify require you to choose and wire validation per route or per router. NestJS's ValidationPipe with DTOs applies to every endpoint globally. As the application grows from 4 routes to 40, this difference compounds. No new developer can forget to add validation to a new route - the framework prevents it.

Code comparison: JWT auth

EXPRESS - MIDDLEWARE

import { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';

export const jwtMiddleware = (req: Request, res: Response, next: NextFunction) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ message: 'Unauthorized' });
  try {
    (req as any).user = jwt.verify(token, process.env.JWT_SECRET!);
    next();
  } catch {
    res.status(401).json({ message: 'Invalid token' });
  }
};

FASTIFY - PLUGIN HOOK

import fastifyJwt from '@fastify/jwt';

app.register(fastifyJwt, { secret: process.env.JWT_SECRET! });

app.get('/protected', {
  preHandler: async (request, reply) => {
    try {
      await request.jwtVerify();
    } catch (err) {
      reply.send(err);
    }
  }
}, async (request) => {
  return { user: request.user };
});

NESTJS - COMPOSABLE GUARD

// auth/jwt.guard.ts
import { Injectable, CanActivate, ExecutionContext, UnauthorizedException } from '@nestjs/common';
import * as jwt from 'jsonwebtoken';

@Injectable()
export class JwtGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const req = context.switchToHttp().getRequest();
    const auth = req.headers['authorization'];
    if (!auth?.startsWith('Bearer ')) throw new UnauthorizedException();
    try {
      req.user = jwt.verify(auth.slice(7), process.env.JWT_SECRET!);
      return true;
    } catch {
      throw new UnauthorizedException();
    }
  }
}

// Composing multiple guards on a single route is one line:
// @UseGuards(JwtGuard, RolesGuard)
// @Roles('admin')
// @Delete(':id')
// remove(@Param('id') id: string) { ... }

// Unit testing a guard requires no HTTP server:
// const guard = new JwtGuard();
// const context = createMockExecutionContext({ authorization: 'Bearer valid-token' });
// expect(guard.canActivate(context)).toBe(true);

The NestJS guard model pays off when you need to compose auth logic: JWT check, role check, rate limit check, feature flag check. In Express, that is four middleware functions you must apply in the right order to the right routes and remember to test each combination. In NestJS, it is @UseGuards(JwtGuard, RolesGuard) and each guard is independently unit-testable.

Performance benchmarks

These numbers were run on Apple Silicon, Node.js 24.15.0, using autocannon, 100 concurrent connections, 20-second runs. No external I/O, in-memory data.

GET / - BARE JSON RESPONSE

Framework	req/s	p50	p99
Fastify 5.8.5	100,301	<1 ms	1 ms
Express 5.2.1	53,400	1 ms	3 ms
NestJS 11 + Fastify adapter	41,159	1 ms	7 ms
NestJS 11 + Express adapter	33,344	2 ms	11 ms

POST /VALIDATE - JSON BODY PARSE + FRAMEWORK-NATIVE VALIDATION

Fastify: built-in JSON Schema (AJV).
Express: manual field checks.
NestJS: class-validator + ValidationPipe.

Framework	req/s	p50	p99
Fastify 5.8.5	42,720	1 ms	7 ms
Express 5.2.1	28,764	3 ms	7 ms
NestJS 11 + Fastify adapter	19,693	4 ms	14 ms
NestJS 11 + Express adapter	17,432	4 ms	22 ms

POST /QUERY - VALIDATE + 10MS SIMULATED DATABASE CALL

Same validation as above, with a 10ms async wait added to simulate a real indexed database query. This is what production throughput actually looks like.

Framework	req/s	p50	p99
NestJS 11 + Express adapter	8,812	11 ms	16 ms
NestJS 11 + Fastify adapter	8,929	11 ms	13 ms
Express 5.2.1	8,770	11 ms	13 ms
Fastify 5.8.5	8,612	11 ms	16 ms

All four frameworks converge to the same throughput - within margin of error, in the same order as random noise. The theoretical ceiling with 100 connections and 10ms I/O is 10,000 req/s; every framework reaches ~88% of it. The 2.5× gap from the pure-CPU benchmark disappears completely.

COLD START AND IDLE MEMORY

Framework	Cold start	Idle RSS	Idle heap
Express 5.2.1	83 ms	62 MB	8 MB
Fastify 5.8.5	137 ms	68 MB	11 MB
NestJS 11 (Express adapter)	570 ms	95 MB	21 MB
NestJS 11 (Fastify adapter)	550 ms	95 MB	21 MB

READING THE NUMBERS HONESTLY

The pure-CPU benchmarks (GET, POST /validate) show a real gap. Fastify handles 2.5× more requests per second than NestJS when there is nothing else to wait on. That number is accurate and worth knowing.

It is also largely irrelevant to the decision.

The moment you add a database - even a fast indexed query at 10ms - every framework converges to the same throughput. The bottleneck becomes I/O wait time, and the 2-4ms of framework overhead NestJS adds per request disappears into the noise. In production, behind a real database, NestJS and Fastify deliver the same throughput.

NestJS at 17,000 req/s (pure CPU) is already handling 1.5 billion requests per day on a single server. With a real database in the picture, all four frameworks land around the same number, and that number is determined entirely by your database latency and connection pool, not by your choice of Node.js framework.

What you are actually trading by choosing NestJS: some CPU-bound throughput headroom that your server will almost certainly never fully use, in exchange for DI, testability, module boundaries, composable guards, global validation, automatic Swagger generation, and a first-party ecosystem for queues, crons, microservices, and everything else a real backend eventually needs.

The cold start story is different. NestJS's ~570ms startup is the DI container initialising, decorators resolving, and modules wiring. For a long-running API server it is paid once at deploy. For serverless or short-lived containers where cold start affects every request, it is a genuine cost. Fastify at 137ms and Express at 83ms are significantly better in those environments.

Switching to the Fastify adapter inside NestJS gives you around 20% better throughput on CPU-bound routes. With I/O in the picture, that 20% gap is barely measurable. The Fastify adapter is still worth using on greenfield projects but "for performance" is the wrong reason. The right reason is that Fastify is a better underlying HTTP engine.

On benchmarks you will find elsewhere: One widely cited comparison claims NestJS outperforms Express on throughput. Our numbers - and the architectural reality - do not support that. NestJS's Express adapter runs on top of Express; it cannot be faster. If you see NestJS above raw Express in a benchmark, look closely at what is being measured.

NestJS project structure

A production NestJS project follows a consistent, predictable shape that any NestJS developer can navigate immediately:

src/
  main.ts                       # bootstrap - global pipes, guards, filters, interceptors
  app.module.ts                 # root module
  common/
    filters/                    # AllExceptionsFilter
    guards/                     # JwtGuard, RolesGuard
    interceptors/               # LoggingInterceptor, TransformInterceptor
    decorators/                 # @CurrentUser(), @Public(), @Roles()
  modules/
    users/
      users.module.ts
      users.controller.ts
      users.service.ts
      dto/
        create-user.dto.ts
        update-user.dto.ts
    auth/
      auth.module.ts
      auth.service.ts
      strategies/               # JWT strategy
  prisma/
    prisma.service.ts           # extends PrismaClient, implements OnModuleInit
    prisma.module.ts

A new developer joining the project knows exactly where to look for any piece of logic. common/guards/ has the auth guards. modules/users/ has the users domain. The structure is the documentation.

DATABASE: PRISMA (RECOMMENDED) VS TYPEORM

In 2026 most new NestJS projects reach for Prisma:

// prisma/prisma.service.ts
import { Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }
}

TypeORM remains common in established codebases and still works well with NestJS. The main 2026 consideration: TypeORM's synchronize: true setting auto-migrates schema at startup and should never be enabled in production.

GLOBAL EXCEPTION FILTER

// common/filters/all-exceptions.filter.ts
import { ExceptionFilter, Catch, ArgumentsHost, HttpException, HttpStatus } from '@nestjs/common';

@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    const ctx    = host.switchToHttp();
    const res    = ctx.getResponse();
    const status = exception instanceof HttpException
      ? exception.getStatus()
      : HttpStatus.INTERNAL_SERVER_ERROR;
    const message = exception instanceof HttpException
      ? exception.getResponse()
      : 'Internal server error';
    res.status(status).json({ statusCode: status, message });
  }
}
// Register once in main.ts: app.useGlobalFilters(new AllExceptionsFilter());

Every unhandled exception in the application now returns a consistent JSON shape. No try/catch in individual route handlers, no risk of raw error objects leaking to the client.

NestJS patterns worth knowing

These are not gotchas - they are architectural decisions NestJS makes explicit that other frameworks leave implicit.

Circular module dependencies surface at startup, not runtime

If UsersModule imports AuthModule and AuthModule imports UsersModule, NestJS throws at bootstrap:

Error: Nest can't resolve dependencies of UserService (?)

This is NestJS catching a circular dependency before your application takes a single request. The fix is forwardRef(), or - better - rethinking whether the two modules should be split differently. Express would silently handle this until something breaks at runtime.

class-validator and the validation performance trade-off

class-validator uses TypeScript reflection metadata, which has runtime cost. Our benchmarks show it reduces throughput on a three-field POST from ~28k to ~17k req/s compared to Express with manual validation. What you gain is automatic, consistent, globally applied validation across every endpoint - no per-route Zod schema, no forgotten validation on a new route, no inconsistent error shapes. For most APIs the trade-off is straightforwardly worth it.

If you hit a specific endpoint where validation is genuinely a throughput bottleneck, you can bypass ValidationPipe on that route and use a custom pipe backed by Zod or raw AJV instead. The framework supports this without requiring architectural changes.

RequestScoped providers: a deliberate choice, not a default

@Injectable({ scope: Scope.REQUEST })
export class RequestContextService {}

Request-scoped providers recreate the injection subtree on every request, which is expensive. The default is singleton scope (the right choice for almost everything). Request scope exists for cases where you genuinely need per-request context - distributed tracing with request-scoped loggers, per-request tenancy in multi-tenant systems. Use it intentionally.

Lifecycle hooks have a defined order

OnModuleInit fires per-module during initialisation. OnApplicationBootstrap fires once after all modules are ready. If your Prisma service connects in OnModuleInit and another service depends on it during initialisation, use OnApplicationBootstrap in the dependent service to guarantee the connection is established first.

The adapter choice: Express vs Fastify under NestJS

Workload	NestJS + Express	NestJS + Fastify	Gain
GET /	33,344 req/s	41,159 req/s	+23%
POST /validate	17,432 req/s	19,693 req/s	+13%
Cold start	570 ms	550 ms	negligible
Idle RSS	95 MB	95 MB	same

The Fastify adapter consistently delivers 15-23% more throughput. The catch: some Express-specific middleware does not work under the Fastify adapter. Older Passport strategies, certain session packages, and any middleware that directly modifies the Express req/res objects will need Fastify equivalents (@fastify/passport, @fastify/session).

For a new greenfield project with no Express dependencies: use the Fastify adapter, accept the marginal tradeoff in ecosystem breadth, and get the performance headroom. For an existing project with established middleware dependencies: stay on Express adapter and save the migration effort for something with more impact.

Picking your framework

NestJS is the right default for backend work in Node.js when:

You are building a real application - auth, modules, services, repositories, business logic
More than one developer will touch the codebase
You need unit-testable services
You want consistent patterns across every module, not just the ones the original author wrote
You are thinking beyond HTTP: queues, scheduled jobs, microservices, event-driven architecture - the NestJS ecosystem covers all of it with the same mental model

Fastify is the right choice when:

Throughput is a primary constraint - IoT ingestion, high-frequency trading, event processing at scale
You are writing a single-purpose HTTP service with a small surface area
Cold start time matters (serverless, edge functions)
You want schema-validated endpoints with near-zero validation overhead

Express is the right choice when:

You are prototyping or scoping
You are maintaining an existing Express codebase where the migration cost outweighs the benefit
You need deep compatibility with a specific Express-only library
The service is genuinely small enough that framework structure adds noise, not clarity

What's next: NestJS v12 (planned Q3 2026)

NestJS v12 is expected in Q3 2026 with three changes worth tracking:

Native ESM - CommonJS workarounds in monorepos become unnecessary
Vitest as the default test runner - replacing Jest in the scaffolded template
Standard Schema / Zod in decorators - class-validator may no longer be the only first-class DTO validation option. If this lands, the validation performance story changes: Zod's runtime cost is lower and its TypeScript inference is tighter

If you are designing an application today that will be in production in 12 months, keep DTO validation encapsulated. The ValidationPipe pattern is stable; the underlying validator may swap.

Agency take

NestJS is our default for client backend work. Not because it is the most performant, but because it is the one that holds up when the project gets handed to a new developer six months later, when the team grows from two to five, when you need to write tests for a feature built by someone else. The structure NestJS enforces is the kind you would build yourself in Express eventually - it just starts from day one instead of after the first painful refactor.

We reach for Fastify when a service has an explicit throughput requirement or when serverless cold start matters. We reach for Express when scope is tight and structure would be overhead rather than investment.

The throughput gap in the synthetic benchmarks is real. Once you add a real database - even a fast one - all four frameworks in these benchmarks land within a few percent of each other. The bottleneck is I/O, not the framework. We measured it: at 10ms simulated query time, Fastify, Express, NestJS on Express, and NestJS on Fastify all hit ~8,700–8,900 req/s. The 2.5× synthetic gap becomes noise.

Pick the framework your team can build on confidently. That is NestJS for most teams doing serious backend work in 2026.

Need help with this in your product? Our senior team builds NestJS and Node.js back ends, and you can hire our Node.js developers to join your own team. See how we helped Speeki grow to 100+ enterprise clients, or book a free 15-minute call.

Next.js 16.3 benchmarked on two production apps

Piotr Żarów — Fri, 16 Oct 2026 15:12:17 +0000

Originally published on devanddeliver.com.

Introduction

Part 1 of 2. Part 2 covers what the Cache Components migration actually costs

Next.js 16.3 promises less dev server memory, faster builds, faster server rendering, and a new opt-in suite called Instant Navigations. Vercel published their own numbers: up to 90% less RAM in dev, up to 5.5x faster builds on CI, up to 22% more requests under load.

We upgraded two projects we maintain, measured them before and after, and then, later than we should have, read the documentation.

Two projects, because one was not enough. The first is a small static marketing site, and it turned out to be too small to test half of what 16.3 claims. So we ran the same harness against a Medusa e-commerce storefront: 223 source files, a cart, a checkout, and almost every route server-rendered per request. Where the two agree, we believe the number.

The documentation is what changed our conclusions. The headline build improvement is real and large, and on the first project's deployment pipeline it would have delivered zero, because the pipeline throws away the one directory the feature depends on. Nobody would have noticed either: the build would have stayed the same speed and the upgrade would have looked like a dud.

This part covers the numbers: builds, type checking, dev memory, and throughput. Part 2 covers Instant Navigations, which is a migration rather than a benchmark.

Everything we measured, in one table

Two production codebases, every number interleaved A/B on the same machine, in September 2026 against Next.js 16.3.4:

What	Marketing site (50 files, static)	Storefront (223 files, SSR)
Warm build compile, 16.1.6 to 16.3.4	2.9 s to 0.19 s (15.3x)	4.4 s to 0.32 s (13.8x)
Cold build, 16.1.6 to 16.3.4	unchanged	unchanged
Requests per second under load	+7%	+52%
Dev server memory	no measurable change	no measurable change
Code changes to get a green build	zero	zero

The build cache is the one result that held across both codebases. Server rendering throughput ranged from 7% to 52% depending entirely on how much the app renders per request, so a single headline number for it is meaningless. Dev memory we could not measure at either size. And on a container pipeline the build cache delivers nothing at all until you carry .next/cache into the build yourself.

What we tested it on

A bilingual (Polish and English) B2B marketing site we build and maintain. Roughly 20 routes plus an API route, around 50 TypeScript and TSX source files, React 19, Turbopack, React Compiler enabled, deployed as a standalone build in Docker.

One characteristic dominates everything below: the site is almost entirely static. 22 of its 23 build outputs are prerendered at build time. There is no cookies(), no headers(), no searchParams, and no server-side fetch anywhere in the source. The only data request in the whole app is client-side, from a contact form.

We went from Next 16.1.6 to 16.3.4 on Node 24, with Yarn 4. The upgrade itself needed zero code changes.

The second project is a Medusa v2 e-commerce storefront: 223 TypeScript source files, 4.5x the first, with a cart, checkout, customer accounts and Stripe. It reads cookies() for cart id, JWT and cache id, and almost every route is ƒ (Dynamic), rendered per request. It is the opposite profile in every way that matters here, and it started two versions back on Next 15.3.9, which let us measure the real 15 to 16 migration as well.

Its build and dev numbers were taken with the commerce backend switched off, which is fine because those measure bundling 223 files. For the load test and the Cache Components work in part 2 we started the backend locally and rebuilt against real product data, because neither means anything against dead upstreams.

Method, and why it changed our conclusions

Our first pass was the obvious one: measure everything on 16.1.6, upgrade, measure again. That pass told us dev memory improved 5%, cold builds got 27% slower, and throughput improved 8%.

Two of those three findings were wrong.

Build times on this project are measured in seconds, and a laptop is a noisy place to measure seconds. So we re-ran everything as an interleaved A/B: 16.1.6, then 16.3.4, then 16.1.6 again, then 16.3.4 again, alternating in one session, with a discarded warm-up build at the start of each round. Where possible we used the compile time Next reports itself rather than wall clock, because it excludes yarn startup and type checking.

Under that method the "27% slower cold builds" vanished completely, and so did the memory improvement. Only the throughput gain survived.

If you are benchmarking your own upgrade, interleave your runs. A single before-then-after pass on a laptop will confidently tell you things that are not true.

Build times: cold unchanged, warm transformed

Cold builds, deleting .next before each run, nine runs per version:

	16.1.6	16.3.4
Compile step (median)	3.1 s	3.0 s
Full build, wall clock (median)	6.68 s	6.58 s

Unchanged. The ranges overlap almost entirely.

Warm builds, no source changes, .next kept, seven runs per version:

	16.1.6	16.3.4
Compile step (median)	2.9 s	187 ms
Full build, wall clock (median)	6.37 s	3.48 s

On 16.1.6 there is effectively no build cache: rebuilding with zero changes costs the same 2.9 seconds of compilation as a cold build. On 16.3.4 the same rebuild compiles in about 0.19 seconds, roughly 15 times faster, and the whole next build drops 45%.

The Turbopack FileSystem cache is a build cache that Turbopack writes to .next/cache and restores on the next run, so unchanged modules are not compiled again. It became enabled by default for next build in Next.js 16.3, and you do not have to turn it on.

The same test on the bigger project, and what it separates

The storefront started on 15.3.9, so the jump to 16.3.4 crosses a major version. That conflates two different changes, and measuring 16.1.6 in the middle pulls them apart. Three cold runs and two warm runs per version, medians:

	15.3.9 (webpack)	16.1.6 (Turbopack)	16.3.4 (Turbopack + cache)
Cold compile	12.0 s	4.4 s	4.7 s
Warm compile	3.0 s	4.4 s	0.32 s
Warm build, wall clock	13.7 s	7.0 s	3.2 s

Two things fall out of that middle column.

The cold build win belongs to the bundler. Cold compile drops 12.0 s to 4.4 s, 2.7x, and every bit of it lands between 15.3.9 and 16.1.6, where Next 16 made Turbopack the default build bundler in place of webpack. From 16.1.6 to 16.3.4 the cold build does not move, which is exactly what we saw on the marketing site.

16.1 was a warm-build regression, and 16.3 is the fix. On webpack a warm rebuild compiled in 3.0 s. On Turbopack in 16.1.6 the same rebuild took 4.4 s, slower than the webpack it replaced, because Turbopack had no build cache yet. 16.3 takes it to 0.32 s. A team that upgraded to 16.1 and judged Turbopack on repeat builds would have concluded it was a downgrade, and at the time they would have been right.

Where the two projects agree

The directly comparable number is the 16.1.6 to 16.3.4 warm compile, measured with the same harness on both:

Project	16.1.6	16.3.4	Speedup
Marketing site (50 files, static)	2.9 s	0.19 s	15.3x
Medusa storefront (223 files, SSR)	4.4 s	0.32 s	13.8x

Two codebases with nothing in common in size or rendering model, and the build cache lands within about 10% of the same ratio on both. Of everything we measured, this is the result we would bet on holding for your project too, provided your pipeline keeps the cache around.

The part the upgrade guide buries

The docs on Turbopack FileSystem caching are blunt about it:

The build cache lives in .next/cache. Builds only get faster when that directory is restored before each build. Containerized builds start from a clean layer and do not carry .next/cache over unless you cache or mount it explicitly.

On our project .next/cache is 52 MB. We deleted just that one directory and rebuilt:

Scenario	Wall clock	Compile step
Warm build, cache intact	4.87 s	200 ms
Same build, only .next/cache deleted	8.20 s	3.5 s

The compile step goes straight back to being 17x slower. The whole headline feature works only if that directory survives between builds.

Then we looked at our own pipeline:

The Dockerfile has a clean builder stage that does COPY . . followed by RUN yarn build. Every image build starts with no .next/cache.
The CI config had no cache: block at all.

So every production build on this project is a cold build. We would have upgraded Next, watched our CI times not move, and reasonably concluded that Vercel's build numbers were marketing, when in fact we were discarding the cache on every run.

We fixed it and checked the fix in the pipeline itself rather than only on a laptop. Our CI builds inside Docker, so a CI-level cache directory would not have helped: the build does not run in the job's workspace. Instead the Dockerfile now restores .next/cache from a small cache image, and exposes a stage that exports the warmed cache so CI can publish it for the next pipeline.

With that in place we changed a source file, so the build genuinely had to re-run, and built the image both ways:

Container build, identical source change	Turbopack compile
With the restored cache	308 ms
Without it (control)	3.1 s

Roughly 10x, inside the actual container build. The exported cache image is 53 MB, and re-exporting it after a build takes about 3 seconds because it reuses the builder layers.

If you build outside Docker, this is simpler: on GitLab CI, GitHub Actions, CircleCI and the rest it is just a cache entry for .next/cache, and Next's own CI build caching guide has a snippet per provider. If your pipeline builds images, as ours does, you need to carry the directory into the build yourself.

And if your pipeline genuinely cannot persist it, the docs suggest setting turbopackFileSystemCacheForBuild: false so the build stops writing 52 MB of cache that nothing will ever read.

Put this on the upgrade ticket. Bumping the version is the easy half; if nobody wires up cache persistence, the largest improvement in 16.3 never reaches your team.

Once the cache lands, type checking is the build

Compilation drops to about 0.19 seconds and the whole build still takes 3.5 seconds, so compilation stops being the bottleneck. We looked at what was left. TypeScript was costing 747 to 870 ms of every build, which made it the biggest measurable step.

16.3 anticipates this. next build now runs your project-local tsc CLI by default, specifically so it can use TypeScript 7, the native port Microsoft released with roughly a 10x speedup. TypeScript 7.0.2 is out and is latest on npm. Our project, like most, was pinned to ^5.

We measured tsc --noEmit against the project's own tsconfig.json, interleaved:

Round	TypeScript 5.9.3	TypeScript 7.0.2
1	1.143 s	0.139 s
2	0.963 s	0.139 s
3	0.960 s	0.135 s
Median	0.96 s	0.139 s

About 7x faster, with zero new type errors. Both runs exited clean.

Inside next build that is roughly 0.7 seconds off every single build, about 18% of our warm build time, stacked on top of what the Turbopack cache already gave us.

Two caveats, because we could not ship it on this project.

First, Yarn 4.12 cannot install TypeScript 7. Yarn applies a builtin compatibility patch to the typescript package, and that patch expects a file layout TS 7 no longer has:

Error: typescript@patch:...#optional!builtin<compat/typescript>:
ENOENT: no such file or directory, lstat '.../typescript/lib/_tsc.js'

Forcing a plain resolution through resolutions did not help, Yarn re-applies the patch. Second, typescript-eslint (pulled in by eslint-config-next) still declares a peer range of >=4.8.4 <6.0.0.

So the 7x is real and measured, but on a Yarn 4 stack it is currently blocked by the toolchain rather than by Next. On npm or pnpm you should hit only the eslint peer warning. Worth checking before you promise it to anyone.

Dev server memory: we could not measure it, and now we know why

We cleared .next, started the dev server, requested all 21 routes so every one compiled, then summed RSS across the entire next dev process tree. Five samples per version.

Run	16.1.6	16.3.4
1	1500 MB	1423 MB
2	1665 MB	1989 MB
3	1763 MB	1700 MB
4	962 MB	1802 MB
5	1598 MB	1746 MB
Median	1598 MB	1746 MB

The spread inside a single version is about 800 MB, which swamps any difference between them, so we measured nothing. The docs explain why, and the explanation is worth more than the non-result.

The 90% figure comes from two features: disk caching for dev, and memory eviction. Disk caching for dev shipped in 16.1. Our baseline was 16.1.6, so it already had half the improvement. Only eviction was genuinely new in our comparison.

So we tested eviction directly, on 16.3.4, over a longer session:

'turbopackMemoryEviction'	Sample 1	Sample 2
false (never evict)	1547 MB	1031 MB
'auto' (default)	2056 MB	1478 MB
'full' (aggressive)	1040 MB	1757 MB

Still nothing. And the reason is scale. Vercel's before numbers are 21.5 GB for the Vercel dashboard and 4.6 GB for nextjs.org. Our dev server peaks around 1.5 to 2 GB, an order of magnitude below where their baseline even begins. Eviction reclaims memory after cache snapshots under sustained pressure, in long sessions. A 21-route site driven for a minute never creates that pressure.

The storefront told the same story, across three versions:

Version	Sample 1	Sample 2
15.3.9	525 MB	547 MB
16.1.6	835 MB	646 MB
16.3.4	696 MB	524 MB

Overlapping again, and this project peaks around 0.5 to 0.8 GB. Even our 4.5x bigger codebase is an order of magnitude below where Vercel's 4.6 GB and 21.5 GB baselines start.

The claim may well hold. We are reporting that it is untestable at this size, and that if dev memory is a daily annoyance on your app, you are the case we could not represent. Two things follow for you: check whether you are already on 16.1 or later, since you may have banked half the win a while ago, and measure a long session rather than a cold start.

Handling load: 7% on one app, 52% on the other

We ran next start and pointed autocannon at the homepage with 20 connections, three interleaved pairs.

Pair	16.1.6	16.3.4	Delta
1	1905 req/s	2064 req/s	+8.3%
2	2128 req/s	2281 req/s	+7.2%
3	2160 req/s	2304 req/s	+6.6%

A consistent ~7% improvement, reproducible across every pair. Average latency improved by about a millisecond.

Vercel claims up to 22%. We got about a third of that, and the docs say why: the change replaces web streams with native Node.js streams in the App Router rendering layer. Our site prerenders 22 of 23 routes, so under load it is mostly handing back finished HTML and barely exercising the rendering path that got faster. Getting a third of the benefit while doing almost none of the work the optimization targets is a reasonable outcome.

Treat our 7% as a floor. An app doing genuine per-request rendering has far more to gain here than we did.

So we went and measured it on the storefront, which is the app this claim is actually about. We started its backend locally, rebuilt against real data, and ran the same interleaved A/B against two routes that render per request.

Route	16.1.6	16.3.4	Change
Home	327.5 req/s	497.4 req/s	+51.9%
Product list	392.1 req/s	571.7 req/s	+45.8%

Between 46% and 52% more requests per second, with latency down about 25%. On an app that actually exercises the rendering path we measured more than double Vercel's 22%, and both interleaved pairs agree to within 4%.

One check worth stating, because it is the obvious objection: was the backend the bottleneck? No. If it had been, both Next versions would have converged on the same figure. They shared the same backend, the same data and the same cookie, and differ by 50%. What moved was the rendering.

So the same release gives one app 7% and another 52%, and the mechanism explains both. Native Node streams replace web streams in the App Router rendering layer. Serve prerendered HTML and you barely touch it. Render every route per request and you get the whole thing. Whether 16.3 is worth 22% to you depends entirely on how much rendering your app does.

What a real 15 to 16 migration cost us

The storefront crossed a major version, so it is the better test of migration pain.

The build passed on the first attempt with zero code changes, on a real e-commerce storefront with a cart, a checkout and Stripe. No codemod needed for a green build. That genuinely surprised us.

Then we looked underneath it, and the green build proved less than it looked. This project sets typescript.ignoreBuildErrors: true, as plenty of projects do. Running tsc --noEmit separately, with an identical tsconfig.json in both runs:

Version	Type errors
15.3.9	17 (pre-existing, unrelated)
16.3.4	49

All 32 new ones are the same breaking change. revalidateTag(tag) now takes a second argument:

const cartCacheTag = await getCacheTag("carts")
revalidateTag(cartCacheTag)   // TS2554: Expected 2 arguments, but got 1

The docs are precise about what one argument now means: it still works, but it is deprecated and behaves like { expire: 0 }. Stale content is never served, so the next request blocks on a full revalidation instead of getting stale-while-revalidate. Nothing breaks. The app takes the slow path on every cart mutation, and a pipeline that ignores type errors will never report it. The fix is revalidateTag(tag, "max"), or updateTag in a Server Action.

Next 16 also rewrote tsconfig.json on its own, and two of the changes are semantic rather than cosmetic:

- "moduleResolution": "node",
+ "moduleResolution": "bundler",
- "jsx": "preserve",
+ "jsx": "react-jsx",

It reformatted every array in the file at the same time, so the real changes arrive buried in a noisy diff. next-env.d.ts picked up a new import too. Both files are committed in most repos, so this lands in somebody's review whether they asked for it or not.

So the upgrade is genuinely cheap, and "the build is green" is not the same as "the migration is done". Run tsc yourself, especially if your config ignores build errors.

One thing that did nothing

Our project runs the React Compiler through Babel, which is exactly the case experimental.turbopackRustReactCompiler targets. Vercel reports 34% faster cold and 46% faster warm time-to-ready-page on v0.

	Cold compile	Warm compile
Babel (default)	2.6 s, 2.4 s	227 ms, 235 ms
Rust compiler	2.5 s, 2.7 s	227 ms, 244 ms

No measurable difference at 50 source files. Vercel's numbers come from v0, a very large app, and they note the gains assume you have moved off Babel entirely. Filed under "revisit on a bigger codebase".

Should you upgrade?

Yes. Both upgrades produced a green build with zero code changes, including the major version jump from 15.3.9 on a real e-commerce storefront. No codemods required. That is about as cheap as a framework upgrade gets.

It is also not the whole job. On the marketing site the upgrade needed no code, but the biggest improvement in the release stayed invisible until we changed the deployment pipeline. On the storefront a green build hid 32 deprecated calls. In both cases the improvements everyone quotes only arrived once we went and collected them.

The checklist we wish the benchmark plan had started with:

Persist .next/cache between builds. Cache mount in Docker, cache entry in CI. Without this the biggest win in 16.3 is precisely zero, and it fails silently. Highest value, lowest effort, do it first.
Move to TypeScript 7. Roughly 7x faster type checking, and once the build cache lands, type checking is what your build time actually consists of. Check your package manager first, Yarn 4 currently cannot install it.
Check which version you are coming from. It changes which win you get. Coming from 15, the big one is cold builds, and that is the webpack to Turbopack switch rather than anything in 16.3. Coming from 16.1 or 16.2, cold builds will not move and the warm build cache is the whole story. Half the dev memory work also shipped back in 16.1.
Run tsc --noEmit yourself after upgrading. A green next build is not proof, and if your config sets ignoreBuildErrors it is barely evidence. That is how we found 32 deprecated revalidateTag calls that nothing else reported.

Instant Navigations is a separate decision with its own timeline, and part 2 is about what it costs.

And calibrate against your own app. Warm builds were the biggest win on both projects, and the one number that held steady across them: 15.3x on 50 files, 13.8x on 223. Dev memory was unmeasurable on both, because even the larger one runs an order of magnitude below where Vercel's benchmark starts. And SSR throughput turned out to depend so completely on your rendering profile that a single headline number for it is close to meaningless: 7% on one of our apps, 52% on the other.

Measure your own, interleave the runs, and read the docs before you write the benchmark rather than after. We did it in the wrong order and it cost us two false conclusions and a rewrite.

One small housekeeping note: installing 16.3.4 writes AGENTS.md and a CLAUDE.md into your repo root, containing version-matched instructions for AI coding agents. They appear without being asked for, and the docs are clear that you should commit them, since next dev re-creates the block anyway.

Questions we were asked while writing this

Is Next.js 16.3 worth upgrading to?

Yes. On both codebases the upgrade produced a green build with zero code changes, including a major version jump from 15.3.9 on the e-commerce storefront. The improvements are a separate piece of work from the version bump: the build cache needs your pipeline to persist .next/cache, and Cache Components is a migration rather than a flag.

How much faster are Next.js 16.3 builds?

Cold builds do not change at all between 16.1.6 and 16.3.4. Repeat builds do: the compile step went from 2.9 s to 0.19 s on a 50-file site and from 4.4 s to 0.32 s on a 223-file storefront, 15.3x and 13.8x. If you are coming from Next 15 you also get a 2.7x faster cold build, but that is Turbopack replacing webpack in 16.0, not anything in 16.3.

Why did my Next.js 16.3 build times not improve?

Most likely your pipeline is discarding the cache. The Turbopack FileSystem cache lives in .next/cache, and a container build starts from a clean layer. On our project, deleting only that directory took the compile step from 200 ms back to 3.5 s. Add a BuildKit cache mount or a CI cache entry for it.

Does Next.js 16.3 really serve 22% more requests?

It depends entirely on how much your app renders per request. The change swaps web streams for native Node streams in the App Router rendering layer. Our mostly prerendered marketing site gained 7%. Our storefront, which renders nearly every route per request, gained 46% to 52%.

About the author

Piotr Zarow is CEO at Dev and Deliver, a Krakow-based software house working with senior React, Next.js, Node and NestJS engineers. He ran these benchmarks himself, on two client codebases the company builds and maintains, in September 2026 on Node 24 with Yarn 4. The method is described in full above so you can reproduce it against your own app rather than take the numbers on trust.

Planning a Next.js upgrade, or trying to work out whether a release is worth the migration effort on your codebase? We are a Krakow-based software house working with senior React, Next.js, Node and NestJS engineers, and this kind of measure-first assessment is how we approach it. Get in touch and tell us what you are building.

Read more about our Next.js development company in Poland.