#Performance benchmark test

This page shows performance benchmark data comparing VextJS with other popular Node.js web frameworks. The reproducible benchmark of the current version is subject to test/benchmark/run-benchmark.mjs in the warehouse; the historical benchmark warehouse data on the page is only for trend reference.

#Comparative caliber description (please read first)

The current repo-local benchmark measures the throughput comparison under the same scenario, the same stress test parameters, and the same functional load as possible, rather than a direct comparison of the "default out-of-box full-featured configuration".

• Raw (naked running): directly use the native API of the underlying framework to implement the same test scenario
• Vext: The same scene is launched through Vext, but in order to make a fair comparison with Raw, non-essential default capabilities will be turned off, and only the adapter/routing layer core overhead will be retained.
• chain: historical compatibility scenario, indicating handler inline business logic chain
• middleware-chain: the real route-level middleware chain, which will enter the adapter's middleware chain executor

In the current benchmark, the Vext side will close or tighten the following non-core default capabilities:

• accessLog
• requestId
• cors
• rateLimit
• response.wrap
• bodyParser
• requestContext
• Changed log level to silent

⚠️ This means: The data on this page is closer to the comparison result of "framework core path/adapter layer", rather than the final throughput commitment when all built-in capabilities are turned on in the default production configuration.

If you want to evaluate real business scenarios, please re-stress test based on your own middleware, logs, authentication, response packaging, database access and deployment environment.

#Test environment

⚠️ Note: Performance benchmark test results are greatly affected by the test environment, load mode and code implementation. It is recommended to run the benchmark on your own hardware for the most accurate results.

#Hello World Benchmark

The simplest routing scenario: return a fixed string response, without any business logic, and test the original throughput of the framework.

#Test code

::: code-tabs @tab VextJS

// src/routes/index.ts
import { defineRoutes } from "vextjs";

export default defineRoutes((app) => {
  app.get("/", {}, async (req, res) => {
    res.json({ message: "Hello, World!" });
  });
});

@tab Fastify

const fastify = require("fastify")();

fastify.get("/", async () => {
  return { message: "Hello, World!" };
});

fastify.listen({ port: 3000 });

@tab Express

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.json({ message: "Hello, World!" });
});

app.listen(3000);

@tab Hono (Node)

import { Hono } from "hono";
import { serve } from "@hono/node-server";

const app = new Hono();

app.get("/", (c) => c.json({ message: "Hello, World!" }));

serve({ fetch: app.fetch, port: 3000 });

:::

#Results

#JSON Serialization Baseline

Test the performance of returning JSON responses containing nested objects, close to real API scenarios.

#Response structure

{
  "id": 1,
  "name": "John Doe",
  "email": "john@example.com",
  "createdAt": "2026-01-15T08:00:00.000Z",
  "profile": {
    "avatar": "https://example.com/avatar.png",
    "bio": "Software Engineer",
    "location": "Shanghai, China"
  },
  "roles": ["user", "admin"],
  "metadata": {
    "loginCount": 42,
    "lastLogin": "2026-01-14T20:30:00.000Z"
  }
}

#Results

#Parameter verification benchmark

Test the performance overhead of request parameter verification during route processing. VextJS uses the built-in schema-dsl verification, and other frameworks use zod or joi.

#Test scenario

POST request, Body contains 10 fields, including strings, numbers, enumerations and nested objects.

VextJS's schema-dsl is compiled based on ajv and has verification performance close to native ajv while providing a more concise DSL syntax.

#Middleware chain benchmark

Test the final routing processing performance after five layers of middleware, and simulate middleware overlay scenarios such as authentication, logging, and current limiting in real applications.

#Middleware configuration

5 layers of middleware:

1. Request ID injection
2. Request logging (memory buffer, do not write to disk)
3. JWT verification (skip signature verification, only parse)
4. Current limit check (memory counter)
5. Response header injection

#Adapter comparison

VextJS supports a variety of underlying HTTP Adapters. The performance difference mainly comes from the underlying HTTP implementation:| Adapter | Requests/second (Hello World, history) | Features | Applicable scenarios | |----------------| :---------------------------------: | -------------------------------------------------- | ---------------------------------- | | native (default) | ~98,000 | Zero external HTTP framework dependencies, Node native http + route-core | Recommended, highest performance | | fastify | ~87,000 | High performance + rich ecosystem | Requires Fastify plug-in ecosystem | | hono | ~72,000 | Web Standards API, ultra-lightweight | Full stack / edge runtime | | express | ~18,000 | The largest middleware ecosystem | Migrate existing Express projects | | koa | ~24,000 | Lightweight and elegant | Small and medium-sized projects | | node-cluster | ~340,000* | Multi-process, linear scaling | Multi-core CPU server |

* Cluster data is the aggregate throughput of 8-core workers (single process × 8 near linear expansion). Note: The uWS (uWebSockets.js) adapter is not yet built-in and is listed as a future plan (roadmap).

#Adapter performance visualization

98,421 req/s
87,653 req/s
Hono 72,841 req/s
Koa ██████████ 24,716 req/s
Express ████████ 18,934 req/s

#Cluster mode baseline

Test the throughput comparison between VextJS Cluster mode and single-process mode in a multi-core environment:

Above 8 cores, affected by CPU scheduling overhead, the expansion efficiency decreases slightly, but it is still close to linear expansion.

#Memory benchmark

Memory usage when the framework is unloaded (only HTTP server is started, no request processing):

#Startup time

Time from process startup to when the first request can be responded to (cold start):

VextJS hot reload time includes the complete process of esbuild incremental compilation + worker replacement. The actual hot reload perceived delay is about 200 ms.

#How to run the benchmark yourself

#Run the benchmark in the current warehouse

npm install
npm run test:bench -- --scenario all --rounds 5

#Run a single framework

# Only tests VextJS (Native)
npm run test:bench -- --framework native --scenario all --rounds 5

# Only test VextJS (Fastify)
npm run test:bench -- --framework fastify --scenario all --rounds 5

# Only test the real route-level middleware chain
npm run test:bench -- --scenario middleware-chain --rounds 5

#Manual testing using autocannon

The benchmark runner of the current warehouse will automatically start/stop the test server and call autocannon through npm exec --package=autocannon@8.0.0. There is usually no need to start the server manually.

If you need to perform a separate stress test on a started local service, you can directly run:

# run autocannon
npx --yes --package=autocannon@8.0.0 autocannon -c 100 -d 30 -p 10 http://localhost:3000/

#Configuration instructions

The current benchmark is configured through CLI parameters, and bench.config.ts does not exist:

#Conclusion

• Highest throughput in history: VextJS + Native Adapter, reaching about 98,000 req/s in the historical Hello World scenario on 2026-01-15, turning on Cluster mode can break through 700,000 req/s (8 cores)
• Minimum memory: VextJS + Native Adapter, only 18 MB when empty, suitable for resource-constrained environments
• Fastest startup: VextJS + Native Adapter, cold startup about 42 ms, hot reload about 180 ms
• Verification performance: The built-in schema-dsl is compiled based on ajv, the verification overhead is extremely low, and it is close to the native ajv performance
• Scalability: Close to linear expansion in Cluster mode, 8 cores can achieve approximately 7.6× throughput improvement

#Performance recommendations

#Related links

• benchmarks repository — complete test code and historical data
• Adapter Architecture — Understand the technical implementation of each Adapter
• Cluster multi-process — How to configure and use Cluster mode
• Configuration Item — adapter configuration field details