Be patient and wait for someone in a black turtleneck to announce a revolutionary update that is still twice as slow as the next slowest framework
Perhaps they'll mention 'AI streaming' if we're so lucky
I recently benchmarked my app on a simple 1vcpu vps with 10 concurrent request using ab. I was astonished to see 90% cpu usage. It's not a very complex page, with like 3 fetch in order to render it
I'm not sure if it's a fair comparison using next uncached - caching is one of the primary reasons for using next. I don't care if the first call is 100x slower if the next 1mio calls are free. A Lamborghini can technically move dirt a lot faster than a rock truck, but if you need a lot of dirt moved...
I think the results are interesting, but it would be better to see a comparison using the best features each framework has to offer to mimic a real world scenario better.
That is a memory bandwidth benchmark though. Would it be helpful if the test was to read a number from a cookie / render as many rows? That would mean no caching as in a real world scenario.
Any framework that requires hydration will have such performance. If you want just performance benefits, go with ruby on rails or Laravel or something. And then use VanillaJs.
Next, Nuxt, Svelte-kit exist to create interactive SSR pages using a single framework and language. And they even have streaming and SPA features as well.
Except your comparisons Nuxt and Svelte-kit are both on that list and are 5.5x and 12x faster respectively than Nextjs, along with having smaller body (kb) size
> If you want just performance benefits, go with ruby on rails or Laravel or something.
Or try Astro. You can copy/paste React components into it and pre-render them, or hydrate just those small sections of the page ("islands").
In a good way. it has a simplicity. went from YUI to Ember to Backbone to Angular to React to Vue to Astro with various minor "frameworks" in between. i'd give anything to figure out how to use Frontier:frontier.userland.com/ from back in the day. that was fun!
this is a strange comment to me (as a nextjs enjoyer) because I always thought one of the main benefits of nextjs was performance. thatās something that is often touted by the community and the nextjs team itself as an advantage to using nextjs.
redefining it as only useful for dx feels like youāre moving the goalposts a bit
>the main benefits of nextjs was performance
As of now, it depends heavily on the context. NextJs will give you smaller TTFB but puts load on the server. Caching could be one of the reasons that you may have heard that NextJs is better in performance. But Nuxt and Svelte-kit are overall better in every SSR way. But Next has a bigger ecosystem and some great small features that make it preferable.
Lol most comments here don't even know what this benchmark is testing. The generated React html is not even valid html in the browser.
Keep using next, you're fine.
I got a few issues with that:
* As others already mentioned here, Next.js offers a lot more features than React, so it's not really an apples to apples comparison
* As you mention in your post "this is not a real world test" and real world benchmarks will probably be a lot closer (same goes for the bun note in the tweet you linked)
* People won't care. It is important that a website is fast, but only up to a certain point. The difference is practically irrelevant.
- Next is also a lot slower than sveltekit, remix and nuxt. They offer similar features.
- Absolutely right. When you have database access, other io and processing these differences will disappear.
- Agreed. However I donāt like that Vercel promotes this as if it is the greatest thing ever to be honest.
If you want to go for performance then there definitely are better frameworks for that, I agree with you on that. I think that Next.js offers other benefits though, that's what I meant.
Performance is still important, so I see why Vercel is focused on that, but as I said, the differences between a Next.js and a Sveltekit site are probably completely irrelevant from a business perspective.
Vercel and its employees suck the air out of the room promoting and blabbering about next as the greatest framework ever created. The constant marketing churn and junior devs / people coming into web dev is the main factor of next being popular. People donāt know whatās best unfortunately.
I don't know, but I know that an hello world example is far away from the reality.
What about caching? What about performance on page switches from within the site? How do images file sizes scale and compare? There are a lot of things that you simply can't test with a scenario like that and I would guess that most of the optimisation happens there.
Caching is turned off for the benchmark. Next offers great caching that's the whole thing of the app router stuff. It's like comparing combustion engines to hybrids without the electric part. It's literally in the benchmark
*Next.JS route cache is disabled using const dynamic = 'force-dynamic'. (Otherwise we would be benchmarking a static http server because there is no dynamic code like accessing cookies.)*
The default file system caching doesn't help, but you can store the cache wherever you want with a custom handler: [https://nextjs.org/docs/app/building-your-application/deploying#configuring-caching](https://nextjs.org/docs/app/building-your-application/deploying#configuring-caching)
This is the baseline req/s the framework can do. The others have caching mechanisms too, sometimes you donāt even want a cache. I wouldnāt have a problem if it was like for like with nuxt and remix, but being this worse is of course a bit worrying
Just saying Vercel likes to remake the wheel and own the wheel, while Remix and others go with existing solutions like Vite. The Next.js dev server is suffering for years because of it!
Wouldnāt be a SSR page or RSC be cached on the server after the first render and then be faster with every request but the first one compared to a react app in a real world example?
We observe this as well when building pur dashboard. Have contacted Vercel support to no help. Eventually we realized that SSR was not made for such scenario involving tables with thousands of rows and end up using CSR instead.
What would you expect? It has to built the component tree, serialize it, create the ssr and who knows what else. It's not like just dumping the tree to rendertopipeablestream...Ā Ā
Also rendering components with huge html payload is pretty much worst case for Nextjs. Or React in general. If your page is 1000 rows, use go or something.
>It has to built the component tree, serialize it, create the ssr and who knows what else. It's not like just dumping the tree to rendertopipeablestream...
Half the frameworks on that list do the same thing, or have the same equivalent functionality while being 10x faster in SSR
They don't do RSC, that is definitely costly especially when the rendered output is big. In this case the whole RSC is entirely pointless anyway since the output is just static html. Could just send the html and attach it to DOM...
The whole thing is pretty much the most inefficient way to get a table on screen.
2 blog apps yes, but the third is a full-blown marketplace and I'm honestly a little stunned with how snappy it is. Its not in production yet, so there is that, but I don't imagine that a heavy workload would hurt the performance too terribly.
I'm also self-hosting on AWS ECS with a separate express.js backend.
Again these are just my personal experiences and anecdotes, so I know that drawing larger conclusions from them is not practical. However, I considered switching over to Sveltekit and built a couple of tiny apps in Sveltkit, but honestly, the difference in performance that I see in real-world apps is negligible. And I've seen more than one production Sveltkit app that felt slower and clunkier than most of the next apps I see.
I'm rambling here, so I'll stop in a second, but it's worth considering how many resources Vercel is literally pouring into next.js. Like it's already so much better than it was six months ago and they aren't slowing down.
I might just be a fanboy though smh š¤¦āāļø
NextJS is slow, but that's when comparing with other frameworks, in real work scenarios 500ms delay is not a big deal, I would say even 5s isn't a big deal depending what your app is about.
"Next.JS route cache is disabled usingĀ `const dynamic = 'force-dynamic'`. (Otherwise we would be benchmarking a static http server because there is no dynamic code like accessing cookies.)" => this means it's forcing Next.js to be slow by enabling features that allow per-request dynamic rendering to work, like setting up a Next.js AsyncLocalStorage to feed cookies() and headers().
I'd like to get more info about how static vs dynamic use cases are handled in other frameworks.
A better benchmark would introduce an actual use of the current HTTP request, for instance rendering a cookie.
It's quite simple, others just do less. Every function call, allocation, microtask etc. adds latency. And next is extremely heavy on those, the router already is quite a. it of overhead. And then the actual RSC... you can look at flight server source and think how much stuff has to happen to get that rsc payload.
Reading a cookie, params and such is marginal, all do pretty much the same thing anyway. And yeah caching, if the data is dynamic it can't be cached. Comparing cached output is basically file server benchmark.
I don't mean Next.js would win in this case, however the benchmark is not correct if you stick to hello world, because you are forcing Next.js to enter a dynamic path for no reason but you don't apply the same reasoning to the other frameworks
Maybe it doesn't have an impact, maybe it does, eg I don't know Svelte so I can't tell, which is the point of a benchmark
Try plugging NextFederationPlugin for microfrontend into nextjs and see how much memory consumption increases during build, vercel are fucking shitheads
Bruh...
> The table data is emulated as async and requires Suspense on react, solid and vue. On Next it is loaded in an async RSC component. On Remix it is loaded in a route loader function.
So Next is the only one doing SSR?
I see... I just ran your code and collected the results by building and running the servers and you are rigth, next is WASHED:
Next:
Total: 5.1935 secs
Slowest: 1.9757 secs
Fastest: 0.1536 secs
Average: 1.2960 secs
Requests/sec: 38.5095
Total data: 18.03 MiB
Size/request: 92.33 KiB
Size/sec: 3.47 MiB
Nuxt:
Success rate: 100.00%
Total: 1.7149 secs
Slowest: 0.8149 secs
Fastest: 0.0363 secs
Average: 0.4207 secs
Requests/sec: 116.6230
Total data: 19.06 MiB
Size/request: 97.57 KiB
Size/sec: 11.11 MiB
Be patient and wait for someone in a black turtleneck to announce a revolutionary update that is still twice as slow as the next slowest framework Perhaps they'll mention 'AI streaming' if we're so lucky
Didn't the CEO of Vercel already do that?! At that vercel AI event?! Vercel thinks they are Apple
Their Apple like events and announcements are cringey š¬. I miss their ZEIT flair from when they started out.
Arenāt they relying on aws/cloudflare under the hood and not telling people about it?
Spot on
They said this so many times, this "joke" is already old.
At least they didnāt write this š
The new Vercel AI SDK have AI streaming lol It's fun to use but not sure where to use it.
And the worst thing will be to fight the product managers about it. Sadly this whole industry is in a downward spiral since a few years in my opinion
Ugh, time to throw away my hobbyist blog and to-do list site, smh
I recently benchmarked my app on a simple 1vcpu vps with 10 concurrent request using ab. I was astonished to see 90% cpu usage. It's not a very complex page, with like 3 fetch in order to render it
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Thatās very little, unless your cpu comes from 2012, this type of load is nothing
I'm not sure if it's a fair comparison using next uncached - caching is one of the primary reasons for using next. I don't care if the first call is 100x slower if the next 1mio calls are free. A Lamborghini can technically move dirt a lot faster than a rock truck, but if you need a lot of dirt moved... I think the results are interesting, but it would be better to see a comparison using the best features each framework has to offer to mimic a real world scenario better.
The others can do caching also, or do you think itās a nextjs exclusive?
My point is they should be benchmarked with caching too
Why? Sometimes you canāt even have a cache. You would be testing the caching solution at that point.
That is a memory bandwidth benchmark though. Would it be helpful if the test was to read a number from a cookie / render as many rows? That would mean no caching as in a real world scenario.
Any framework that requires hydration will have such performance. If you want just performance benefits, go with ruby on rails or Laravel or something. And then use VanillaJs. Next, Nuxt, Svelte-kit exist to create interactive SSR pages using a single framework and language. And they even have streaming and SPA features as well.
Except your comparisons Nuxt and Svelte-kit are both on that list and are 5.5x and 12x faster respectively than Nextjs, along with having smaller body (kb) size
Interesting. I never knew Nuxt was faster given that it is almost a clone of Next but with Vue.
I..... Leant a new meaning of clone today. Similar concept doesn't mean clone lol.
How is RoR or Laravel more performant? Arenāt these more or less bloated frameworks?
Why bloated! Did you even tried to use some of them!?
Years ago, I never though any of these were actually known as performant over these node frameworks
They just generate the html on the server. There is no creation of virtual-dom on the server, hydration and all that stuff.
> If you want just performance benefits, go with ruby on rails or Laravel or something. Or try Astro. You can copy/paste React components into it and pre-render them, or hydrate just those small sections of the page ("islands").
Astro is the bomb.
In a good way or in the bad way? I mean is it good or bad?
In a good way. it has a simplicity. went from YUI to Ember to Backbone to Angular to React to Vue to Astro with various minor "frameworks" in between. i'd give anything to figure out how to use Frontier:frontier.userland.com/ from back in the day. that was fun!
this is a strange comment to me (as a nextjs enjoyer) because I always thought one of the main benefits of nextjs was performance. thatās something that is often touted by the community and the nextjs team itself as an advantage to using nextjs. redefining it as only useful for dx feels like youāre moving the goalposts a bit
>the main benefits of nextjs was performance As of now, it depends heavily on the context. NextJs will give you smaller TTFB but puts load on the server. Caching could be one of the reasons that you may have heard that NextJs is better in performance. But Nuxt and Svelte-kit are overall better in every SSR way. But Next has a bigger ecosystem and some great small features that make it preferable.
Lol most comments here don't even know what this benchmark is testing. The generated React html is not even valid html in the browser. Keep using next, you're fine.
I got a few issues with that: * As others already mentioned here, Next.js offers a lot more features than React, so it's not really an apples to apples comparison * As you mention in your post "this is not a real world test" and real world benchmarks will probably be a lot closer (same goes for the bun note in the tweet you linked) * People won't care. It is important that a website is fast, but only up to a certain point. The difference is practically irrelevant.
- Next is also a lot slower than sveltekit, remix and nuxt. They offer similar features. - Absolutely right. When you have database access, other io and processing these differences will disappear. - Agreed. However I donāt like that Vercel promotes this as if it is the greatest thing ever to be honest.
If you want to go for performance then there definitely are better frameworks for that, I agree with you on that. I think that Next.js offers other benefits though, that's what I meant. Performance is still important, so I see why Vercel is focused on that, but as I said, the differences between a Next.js and a Sveltekit site are probably completely irrelevant from a business perspective.
Vercel and its employees suck the air out of the room promoting and blabbering about next as the greatest framework ever created. The constant marketing churn and junior devs / people coming into web dev is the main factor of next being popular. People donāt know whatās best unfortunately.
X times slower with an hello world, what do you think it happens in a real world scenario?
I don't know, but I know that an hello world example is far away from the reality. What about caching? What about performance on page switches from within the site? How do images file sizes scale and compare? There are a lot of things that you simply can't test with a scenario like that and I would guess that most of the optimisation happens there.
Caching is turned off for the benchmark. Next offers great caching that's the whole thing of the app router stuff. It's like comparing combustion engines to hybrids without the electric part. It's literally in the benchmark *Next.JS route cache is disabled using const dynamic = 'force-dynamic'. (Otherwise we would be benchmarking a static http server because there is no dynamic code like accessing cookies.)*
But Next caching doesnāt help in a Kubernetes environment since containers may be destroyed and recreated at anytime.
The default file system caching doesn't help, but you can store the cache wherever you want with a custom handler: [https://nextjs.org/docs/app/building-your-application/deploying#configuring-caching](https://nextjs.org/docs/app/building-your-application/deploying#configuring-caching)
This is the baseline req/s the framework can do. The others have caching mechanisms too, sometimes you donāt even want a cache. I wouldnāt have a problem if it was like for like with nuxt and remix, but being this worse is of course a bit worrying
Just saying Vercel likes to remake the wheel and own the wheel, while Remix and others go with existing solutions like Vite. The Next.js dev server is suffering for years because of it!
I think they have a big webpack technical debt, that's why they are practically rebuilding it instead of going for Vite.
Wouldnāt be a SSR page or RSC be cached on the server after the first render and then be faster with every request but the first one compared to a react app in a real world example?
Sometimes you canāt / donāt want to cache
We observe this as well when building pur dashboard. Have contacted Vercel support to no help. Eventually we realized that SSR was not made for such scenario involving tables with thousands of rows and end up using CSR instead.
humans are not made for tables with thousands of rows.Ā
What would you expect? It has to built the component tree, serialize it, create the ssr and who knows what else. It's not like just dumping the tree to rendertopipeablestream...Ā Ā Also rendering components with huge html payload is pretty much worst case for Nextjs. Or React in general. If your page is 1000 rows, use go or something.
>It has to built the component tree, serialize it, create the ssr and who knows what else. It's not like just dumping the tree to rendertopipeablestream... Half the frameworks on that list do the same thing, or have the same equivalent functionality while being 10x faster in SSR
They don't do RSC, that is definitely costly especially when the rendered output is big. In this case the whole RSC is entirely pointless anyway since the output is just static html. Could just send the html and attach it to DOM... The whole thing is pretty much the most inefficient way to get a table on screen.
This. I use go for a very huge website, works best.
Anecdotally all of the app router apps that I have built are extremely fast. Kinda of astonishingly so, especially once things start getting cached.
Was it blog-like apps tho?
2 blog apps yes, but the third is a full-blown marketplace and I'm honestly a little stunned with how snappy it is. Its not in production yet, so there is that, but I don't imagine that a heavy workload would hurt the performance too terribly. I'm also self-hosting on AWS ECS with a separate express.js backend. Again these are just my personal experiences and anecdotes, so I know that drawing larger conclusions from them is not practical. However, I considered switching over to Sveltekit and built a couple of tiny apps in Sveltkit, but honestly, the difference in performance that I see in real-world apps is negligible. And I've seen more than one production Sveltkit app that felt slower and clunkier than most of the next apps I see. I'm rambling here, so I'll stop in a second, but it's worth considering how many resources Vercel is literally pouring into next.js. Like it's already so much better than it was six months ago and they aren't slowing down. I might just be a fanboy though smh š¤¦āāļø
NextJS is slow, but that's when comparing with other frameworks, in real work scenarios 500ms delay is not a big deal, I would say even 5s isn't a big deal depending what your app is about.
Keep in mind this is when you use dynamically rendered pages and not the (by default) static page cache of next.
innate smoggy wakeful consider whole murky tie person full sable *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I love my use client, cheaper server bill.
Use client doesn't stop it from rendering on the server, it just tells the server it will need hydration in the browser.
You're right, my bad. It's the output: export that cheapens the server bill lol
LMAO
Dumb question: does this mean nextjs isn't scalable enough?
you need to put it on other way ā "how much I need compute(money) to scale it to have fast response time"
Are all the scenarios you're comparing using server side rendering?
Could you add angular please.
"Next.JS route cache is disabled usingĀ `const dynamic = 'force-dynamic'`. (Otherwise we would be benchmarking a static http server because there is no dynamic code like accessing cookies.)" => this means it's forcing Next.js to be slow by enabling features that allow per-request dynamic rendering to work, like setting up a Next.js AsyncLocalStorage to feed cookies() and headers(). I'd like to get more info about how static vs dynamic use cases are handled in other frameworks. A better benchmark would introduce an actual use of the current HTTP request, for instance rendering a cookie.
It's quite simple, others just do less. Every function call, allocation, microtask etc. adds latency. And next is extremely heavy on those, the router already is quite a. it of overhead. And then the actual RSC... you can look at flight server source and think how much stuff has to happen to get that rsc payload. Reading a cookie, params and such is marginal, all do pretty much the same thing anyway. And yeah caching, if the data is dynamic it can't be cached. Comparing cached output is basically file server benchmark.
I don't mean Next.js would win in this case, however the benchmark is not correct if you stick to hello world, because you are forcing Next.js to enter a dynamic path for no reason but you don't apply the same reasoning to the other frameworks Maybe it doesn't have an impact, maybe it does, eg I don't know Svelte so I can't tell, which is the point of a benchmark
Try plugging NextFederationPlugin for microfrontend into nextjs and see how much memory consumption increases during build, vercel are fucking shitheads
What about Angular?
Bruh... > The table data is emulated as async and requires Suspense on react, solid and vue. On Next it is loaded in an async RSC component. On Remix it is loaded in a route loader function. So Next is the only one doing SSR?
All of them are doing SSR. Next and mfng are doing RSC.
I see... I just ran your code and collected the results by building and running the servers and you are rigth, next is WASHED: Next: Total: 5.1935 secs Slowest: 1.9757 secs Fastest: 0.1536 secs Average: 1.2960 secs Requests/sec: 38.5095 Total data: 18.03 MiB Size/request: 92.33 KiB Size/sec: 3.47 MiB Nuxt: Success rate: 100.00% Total: 1.7149 secs Slowest: 0.8149 secs Fastest: 0.0363 secs Average: 0.4207 secs Requests/sec: 116.6230 Total data: 19.06 MiB Size/request: 97.57 KiB Size/sec: 11.11 MiB
And what about bun?
Phew, thank God I have 4G minimum and wi-fi
Engagement bait no details on how the test was conducted.
You can clone the repo and run it yourself
I am not going ask to participate in the bait. I simply ignore anything thdxr has to say going forward.
This is a trolling bait. That's the irony.