Performance with output: 'standalone' mode

[jonathanhefner]

Link to the code that reproduces this issue

https://github.com/jonathanhefner/next-techempower-benchmarks

To Reproduce

I recently submitted Next.js to be included in the upcoming round of TechEmpower Web Framework Benchmarks (see TechEmpower/FrameworkBenchmarks#9506). The results have not been publicly released yet, but you can preview them.

Compared to other frameworks, Next.js performance is unexpectedly poor. For example, here are the results for all Node-based frameworks for a simple API endpoint benchmark:

The code for that endpoint is just

export async function GET() {
  return Response.json({ message: "Hello, World!" })
}

So I believe the poor performance is due to Next.js overhead.

Current vs. Expected behavior

Currently, Next.js performance is much worse than other frameworks across multiple types of synthetic benchmarks. For example, see also the "Plaintext" benchmark results and "Single query" benchmark results.

Synthetic benchmarks aren't necessarily representative of real-world performance, but I expect Next.js to at least be competitive with other web frameworks.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64

Binaries:
  Node: 22.13.0

Relevant Packages:
  next: 15.1.3
  react: 19.0.0
  react-dom: 19.0.0

Which area(s) are affected? (Select all that apply)

Performance

Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

Additional context

In case it is relevant, this is the Dockerfile for the app.

See https://www.techempower.com/benchmarks/#section=environment for benchmark environment details.

[jonathanhefner]

@samcx I see you converted issue #75920 into this discussion. I originally considered making it a discussion, but the benchmark results were so extreme (> 100x slower!) that it seemed worthy of being considered a bug. Or are all performance-related problems handled as discussions instead of issues?

[samcx]

Could you explain how static assets are related? The code in the benchmark only returns stringified JSON. Based on my understanding, it should merely be exercising the Next.js (server-side) routing system. Perhaps there are some concepts I am missing?

Not saying they're related to your benchmark—just sharing that the way the majority of Next.js are built and how a CDN serves your application is different.

build: Route (app)                              Size     First Load JS
build: ┌ ◐ /                                    147 B           113 kB
build: ├ ○ /_not-found                          978 B           114 kB
build: ├ ƒ /api/geo                             147 B           113 kB
build: ├ ƒ /api/graphql                         147 B           113 kB
build: ├ ○ /api/hello                           147 B           113 kB
build: ├ ƒ /api/rest                            147 B           113 kB
build: + First Load JS shared by all            113 kB
build:   ├ chunks/255-226c0c76ea232b00.js       54.6 kB
build:   ├ chunks/c47379a2-824f3c36d71e89ca.js  56.9 kB
build:   └ other shared chunks (total)          1.89 kB
build:
build:
build: ƒ Middleware                             34 kB
build:
build: ○  (Static)             prerendered as static content
build: ◐  (Partial Prerender)  prerendered as static HTML with dynamic server-streamed content
build: ƒ  (Dynamic)            server-rendered on demand

On a CDN like Vercel, a single Next.js server doesn't serve these static, partially prerendered/static, or dynamic paths. Our CDN serves the static paths or partially static ones, and a Serverless Function(s) separately serves the dynamic ones. I believe this is different from most of the other framework's shown (other frameworks are following suit though!).

Next.js has previously received criticism for being difficult to self-host. I think some of that criticism has been unfair, and, additionally, Next.js has made recent strides to further improve things.

Fair criticism! I'm happy we've made strides to improving self-hosting, but as your benchmark showed, there are likely performance improvements that can be made to output: 'standalone'. Although this is not our current priority, we are definitely open to looking at PRs that will improve this!

[samcx]

Another thing I noticed—I noticed there is a Middleware file in the benchmark. This runs before each API request. Are the other framework benchmarks doing something similarly? 👀

[feedthejim]

👋 Just wanted to add some context on those results.

Next.js tends to show lower throughput in synthetic benchmarks like TechEmpower because it’s designed as a hybrid full-stack framework, not a highly optimized backend server. Unlike lightweight API frameworks or monolithic backend solutions, Next.js provides server-side rendering, static generation, routing, middleware, and caching layers—all of which add some overhead but offer significant advantages for modern web applications.

A few key reasons for this:

• Optimized for web applications, not just APIs – Next.js is built to support full-stack React applications with dynamic rendering capabilities, not just to serve raw HTTP responses as quickly as possible. Even when handling API requests, it allows users to leverage built-in caching and edge functions, which introduce some trade-offs for flexibility.
• Higher-level abstractions – Every request goes through Next.js’s routing layer, middleware system, and request pipeline, enabling features like internationalization, per-request configurations, and incremental adoption of edge runtimes. While this adds some processing time, it simplifies complex application needs that would otherwise require custom infrastructure.
• Runtime considerations – Next.js runs in a standard Node.js request-response model, unlike PHP-based or Ruby-based frameworks that leverage multi-threaded architectures. Compared to lower-level frameworks like Fastify, which optimize directly for raw API throughput, Next.js prioritizes DX and web performance trade-offs over pure RPS.

If raw throughput is the primary goal, a dedicated API solution (e.g., Fastify, Express, or a Go-based server) would be a better fit. However, most Next.js users prioritize a unified framework that seamlessly integrates frontend and backend logic, allowing for SSR, static generation, and API handling within the same system.

Synthetic benchmarks aren't necessarily representative of real-world performance, but I expect Next.js to at least be competitive with other web frameworks.

I would rather compare Next.js to other frameworks that do more similar things, like Astro, Remix, or Nuxt.js. It will still do worse, but it's not non-competitive like comparing it to Fastify would make it out to be.

One quick note: In your test, disabling middleware increased throughput by 50%. If you only need custom headers, you might see better performance by using the headers option in next.config.js instead of middleware.

[jonathanhefner]

Thank you both for the replies! 😃

Another thing I noticed—I noticed there is a Middleware file in the benchmark. This runs before each API request. Are the other framework benchmarks doing something similarly?

Setting the HTTP Server header is a requirement for all benchmark tests, including some tests which render a full page (i.e. not API routes). The spirit of the benchmark is that code should be written as naturally possible per the idioms of the framework. Some frameworks use middleware (for example, HyperExpress), while other frameworks may use dedicated features (for example, Rails).

One quick note: In your test, disabling middleware increased throughput by 50%. If you only need custom headers, you might see better performance by using the headers option in next.config.js instead of middleware.

👍 I've made this change to my copy of the benchmark app, and I will submit a PR to the TechEmpower repo. If you have other suggestions for improvements, I can include them as well.

Not saying they're related to your benchmark—just sharing that the way the majority of Next.js are built and how a CDN serves your application is different.

Every request goes through Next.js’s routing layer, middleware system, and request pipeline, enabling features like internationalization, per-request configurations, and incremental adoption of edge runtimes. While this adds some processing time, it simplifies complex application needs that would otherwise require custom infrastructure.

So, putting it all together, it sounds like the performance issue isn't specific output: 'standalone'. Or am I misunderstanding?

Next.js runs in a standard Node.js request-response model, unlike PHP-based or Ruby-based frameworks that leverage multi-threaded architectures. Compared to lower-level frameworks like Fastify, which optimize directly for raw API throughput, Next.js prioritizes DX and web performance trade-offs over pure RPS.

I agree that Next.js provides great DX. I think it nails the fundamental abstractions with RSC, server functions, and file-based routing. And that's why I really want Next.js to succeed. But other frameworks also provide many features that improve DX (Rails being an excellent example). So I am concerned that Next.js performs so poorly compared to those frameworks.

If raw throughput is the primary goal, a dedicated API solution (e.g., Fastify, Express, or a Go-based server) would be a better fit. However, most Next.js users prioritize a unified framework that seamlessly integrates frontend and backend logic, allowing for SSR, static generation, and API handling within the same system.

I also agree that being a unified framework is big point in Next.js's favor. But it seems self-defeating to say that Next.js will not be competitive with those dedicated solutions. It is a matter of degrees. If Next.js's throughput was, say, 50% less than those dedicated solutions, then I think many people would consider that a reasonable trade-off. But the difference appears to be much, much more.

[jonathanhefner]

Following up:

One quick note: In your test, disabling middleware increased throughput by 50%. If you only need custom headers, you might see better performance by using the headers option in next.config.js instead of middleware.

I submitted a PR to the TechEmpower repo to use next.config.js instead of middleware (TechEmpower/FrameworkBenchmarks#9621). Here are the preliminary results compared to other Node.js-based frameworks:

And compared to other popular frameworks:

Also, in the original round of benchmarks, I had to exclude the HTML-generation benchmark due to a combination of strict HTML checking by the benchmark itself, and Next.js / React's lack of flexibility in generating HTML. I submitted a PR to relax the HTML checking (TechEmpower/FrameworkBenchmarks#9505), and here are the preliminary benchmark results:

I wanted to highlight this case, not just because of performance, but because of the inability to meet strict requirements. Such cases might seem minor, but they can disproportionately affect developer confidence.