The image used as this article's cover is a visual summary of a Jeston.js vs Next.js comparison. It is not a substitute for measured evidence. The numbers below are from a fresh local run using the current Jeston 2.1.0 package and the current stable Next.js 16.3.4 release available at the time of testing.
Versions and test applications
- Jeston: 2.1.0, Node.js 22.13.0, official repository example
- Next.js: 16.3.4, Node.js 22.13.0, minimal Pages Router application
-
Routes: one minimal SSR page at
/and one JSON health endpoint at/api/health -
Harness: Jeston's
benchmarks/http-harness.mjs - Requests: 1,000 measured requests after 100 warmup requests per route
- Topology: loopback HTTP on the same machine, no TLS, proxy, database, CDN, compression, or external services
- Errors: zero in all four runs
The applications intentionally perform small, equivalent work. This is a runtime-overhead comparison, not a complete SaaS benchmark.
Fresh results
| Route | Framework | Throughput | P50 | P95 | P99 | Errors |
|---|---|---|---|---|---|---|
/ SSR |
Jeston 2.1.0 | 1,148.45 req/s | 0.749 ms | 1.382 ms | 3.659 ms | 0 |
/ SSR |
Next.js 16.3.4 | 581.65 req/s | 1.540 ms | 2.617 ms | 5.843 ms | 0 |
/api/health JSON |
Jeston 2.1.0 | 1,339.00 req/s | 0.694 ms | 0.991 ms | 2.005 ms | 0 |
/api/health JSON |
Next.js 16.3.4 | 957.89 req/s | 0.952 ms | 1.445 ms | 3.399 ms | 0 |
In this run, Jeston measured approximately 1.97x the SSR throughput and 1.40x the JSON throughput of the minimal Next.js application. Next.js measured about 2.06x the Jeston SSR p50 and 1.89x the Jeston SSR p95 in this setup. For the JSON route, Next.js measured about 1.37x the p50 and 1.46x the p95.
These ratios describe this exact machine, Node runtime, application shape, route implementation, build mode, and harness. They are not universal framework rankings.
Why the result should be treated carefully
The Jeston application used the official repository example and the Next.js application used a minimal Pages Router page. The frameworks have different defaults, internal pipelines, and feature sets. A benchmark is only fair within the workload it defines.
The run did not measure Next.js App Router, React Server Components, complex client components, hydration cost, Server Actions, data fetching, authentication, databases, images, uploads, cache components, streaming, CDN behavior, TLS, multiple instances, memory pressure, or Web Vitals. It also did not compare equivalent production deployments.
How to reproduce it
Jeston's repository includes the harness:
node benchmarks/http-harness.mjs http://127.0.0.1:3000/ 1000 100
Record the Node version, operating system, CPU, memory, route work, payload, concurrency, warmup, request count, and topology alongside every result. Repeat the run on clean machines and include p99, RSS/heap, error rate, queue behavior, and dependency latency for a production decision.
Conclusion
The current local test shows lower overhead for Jeston 2.1.0 on these minimal SSR and JSON routes than for Next.js 16.3.4. The responsible conclusion is narrower: Jeston has a reproducible baseline on this workload. Teams should benchmark their complete application before selecting a framework, especially when database, network, caching, authentication, client JavaScript, or provider behavior dominates the request.
Sources: Jeston benchmark harness and repository, Next.js 16.3.4 documentation.
Top comments (0)