The short answer
If you’re building a side project or a prototype, don’t start with Next.js. It’s heavy to run, it asks a lot of the rest of your stack, and it solves problems you don’t have yet.
TanStack Start gives you React with far less server work. Hono does the job for APIs and server-rendered pages with a fraction of it.
We have a stake in this: Eurobase hosts Next.js, TanStack Start, Hono and other frameworks, and every plan includes a monthly CPU budget for Workers. The numbers below come from real deployments we published with their method.
The same shop, built twice
We built one shop in Next.js and in Hono, with the same pages and the same output, and deployed both. You pay the difference on every request.
| Measure | Next.js | Hono |
|---|---|---|
| CPU for the 400-product catalog | 128.7 ms | 9.0 ms |
| Worker size, compressed | 1,059 KB | 23 KB |
| JavaScript on a first visit | 145 KB | 0 KB |
| Catalog time to first byte, median | 168 ms | 77 ms |
| First request on a cold start, median | 1,800 ms | 975 ms |
The Hono shop sends no JavaScript because it has no interactive parts. Many prototypes barely have any.
The Eurobase Free plan allows 50 ms of CPU per request. A 129 ms page is over that limit, so every view draws on a small reserve, and an empty reserve means a 503. The same page in Hono stays inside the limit.
You can keep React
Hono’s JSX isn’t React. If you want React, routes and server functions, try TanStack Start. Same library, about a third of the server work on pages.
| Measure | Next.js | TanStack Start |
|---|---|---|
| CPU, small page | 26.0 ms | 8.5 ms |
| CPU, 400-row page | 102.6 ms | 36.3 ms |
| CPU, JSON report | 15.7 ms | 10.7 ms |
| JavaScript on a first visit | 141 KB | 115 KB |
This table comes from a smaller test app, so its numbers are lower than the shop’s. The win is on the server: in the browser, TanStack Start sends only 18% less JavaScript, because it’s still React.
It fights the rest of your stack
A web app runs on servers behind CDNs, proxies and load balancers. Next.js asks each of them to play along.
- Your CDN
- Next.js varies responses on several request headers, which its own guide says many CDNs can’t handle out of the box. So it adds an
_rscparameter your CDN has to keep in the cache key. Strip therscheader and the app gets HTML instead of the payload it asked for. - Your second server
- By default each instance keeps its own cache.
revalidateTagclears only the instance that received it, unless you implementrefreshTags(). The self-hosting guide points you to a cache handler on Redis or S3. - Your proxy
- Streaming needs buffering turned off in nginx or similar, and in every load balancer on the way. Your auth and redirects in
proxy.jsshould run before the CDN cache. - Your CPU
- On Eurobase, the same static page used 18 ms of CPU in Next.js and 0.04 ms in Hono.
It costs you time, too
use client, use server and several layers of cache APIs are a lot to hold in your head for something you may throw away next month.
Inngest moved off Next.js for this reason. First local page loads went from 10–12 seconds to 2–3. Moving the dashboard took one engineer a couple of weeks, and they had to give up conventions for more explicit routes.
Server Components also add a surface to defend. In December 2025, React disclosed an unauthenticated remote code execution bug rated CVSS 10, and apps could be vulnerable without a single Server Function. It wasn’t only a Next.js problem, and no framework is immune to security bugs. But a landing page never needed that surface.
When Next.js makes sense
In our view, Next.js only makes sense in two places: on dedicated resources you pay for and manage yourself, or directly on Vercel, which is built around it.
We still don’t think that’s efficient. With the same resources, you can run many more projects on other frameworks.
Keep Next.js if:
- your large React app really uses Server Components and Server Actions
- you depend on something built for it, like Payload CMS
- it already works and you can afford what it uses
Rewrites cost money too. This post is about what you start next.
Tell your coding agent
Agents love Next.js. In our experience they reach for it by default, even for a small site. That’s a habit, not a decision about your app, so name the framework you want. Try TanStack Start:
| You’re building | Try |
|---|---|
| An API or a webhook | Hono |
| A blog, docs or a marketing site | Astro |
| A React app or a prototype | TanStack Start |
| A large app built on Server Components | Next.js |
What these numbers don’t tell you
- They come from small apps with data in memory, one client at a time, on V8 isolates.
- Next.js runs here through its adapter, so it behaves differently on a Node.js server.
- Your database and your own code can matter more than the framework.
Method and every framework we tested are in JavaScript frameworks compared.
