> excellent developer experience (DX)

My experience with next.js has been it’s like working with struts or enterprise java beans or something. It’s a giant, batteries included framework whose primary purpose is to lock you in to the Vercel ecosystem. There are some bright spots - next-auth is decent - but all this SSR spaghetti with leaky abstractions dripping out (try rendering emails in the backend of a next app) make it really not worth it.

Also compile times when working on it locally can get astronomical with relatively modest applications for no obvious reasons. Like Scala but less predictable.

I suspect the % of apps built with next.js that actually genuinely get a lot out of SSR is tiny, it’s mostly the darling of B2B SaaS companies.

I have also found that Next.js is shockingly slow.

I recently added some benchmarks to the TechEmpower Web Framework Benchmarks suite, and Next.js ranked near dead last, even for simple JSON API endpoint (i.e. no React SSR involved): https://www.techempower.com/benchmarks/#section=data-r23&hw=...

I discussed it with a couple of Next.js maintainers (https://github.com/vercel/next.js/discussions/75930), and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel). However, I'm not entirely convinced that is true. I wonder if there are major optimizations that could be made to, for example, the routing system.

Next has been a nightmare to use every step of the way. Endless undocumented ways to shoot yourself in the foot, especially if you’re trying to deploy somewhere other than Vercel. I can’t imagine anyone using it for anything other than the most basic CRUD app. And even then I’d recommend not using it.

I did expect SSR to be generally quite slow, but ~34 rps on the VPS is below my expectations. If I understand the blog post correctly, this tests an essentially static site with no DB requests. That would be pretty abysmal performance for something like that.

I'd be really concerned to have to work around a performance limitation like that in a more complex app.

Ditch next, build a static site, put it in your object storage of choice, cache/cdn in front… solved problem?

> Then again, I don't think <500 kB is too much traffic for a modern website, especially since the page is already usable after the first 100 kB.

I could not disagree more. Why does a "modern" website that just has simple static text and images need to be tens of times larger/slower to load than a simple static website with plain old HTML and CSS?

What kind of "developer experience" do you need for a static website? Just write HTML or markup and run it on a local server with hot reload -- what more do you want/need? Specifically what use cases is NextJS satisfying here?

I don't know if I entirely buy the argument here. CSS/JS/Images should be at the very least cached by your reverse proxy if not on a CDN(I'm a strong believer you should never be serving Images/Videos from your own VPS, even if you don't like Cloudflare there are many CDN providers).

So at most it is the actual dynamic content being served, ie API calls.

Now whether next.js bad deployment experience on your own hardware is to blame for the complexity of doing that easily is up for debate.

As much as I dislike the accidental complexity of React and it's "frameworks"(react-router/next), I can deploy a good looking site with good accessibility very quickly using it and evey JS bootcamp dev won't be completely lost if they happened to need to work on the project.

Sometimes the technically best decision is decided by non-technical factors.

I like this article and it directly relates to some things I'm working on at present; but I wish it had gone a bit deeper into server-side rendering.

In an earlier section, there was a statement about how there's something like 60 individual requests in a webpage load, so the "90% less" (1/10th speed) could actually be faster overall.

Also worth investigating is how many concurrent requests can exist. If it's a little slower; but a single server can handle 5x the number of concurrent requests, because most of the interaction is busy-waiting for something else, that could be worthwhile.

Given how many job openings seem to be interested in Next.js and/or anything 100% Javascript, it seems like some parts of the industry are pushing all JS all the time; but it seems like maybe that's not the right route to go, and that _also_ is interesting.

Just interesting things all around :)

I’ve never used next.js. Wouldn’t pre-rendering a site remove dependence on any framework? It should just be html js and css right?

Let me guess: Significantly less than the same site as an SPA on a CDN. All with significantly more cost, complexity, and a whole additional domain of security concerns. The only up side is rapid search engine indexing, about a week faster - if that even matters to you. Performance improvement is questionable. Debugging is very difficult. It's difficult to imagine why you would want your team to ensure anything server side for your web front end in 2025.

Even aside from Next.js specifically - when did it become okay that visiting a website fires off dozens of HTTP requests? Back in the day the server would just render the site and return it in one request. It seems nowadays we are causing both the client and server to do a lot more work. And it's not like development has gotten easier, it's mostly gotten harder. So it's simply the worst of all worlds?

Next.js is basically designed to run on servers that process one event at a time and in which there are many parallel deployments (ie. 'serverless'). Still, it's shocking just how bad its performance actually is - virtually unusable for anything serious hosted off of Vercel or analogous providers.

Interesting. My hunch is that Next.js is not optimized for the dockerized Node server deployment. I would say that you could get much greater prerendering performance from Next.js by just fronting the assets directly using Caddy/Nginx.

For things like this (public facing static sites) I’ve often gone for a pretty naive approach using Redis (more lately KeyDB as a drop-in alternative) to cache any static pages that SSR would be handling otherwise for a minute or so. If I needed any more performance I’d also use node:cluster to run the server on multiple threads. This significantly improved RPS while keeping CPU usage lower because I had found that my bottleneck for most of these problems was database lookups (Postgres mostly, specifically rerequsting the same data).

The big convenience that SSR brings for most of my use cases is querying the CMS for changes and getting instant updates on the frontend without having to statically rebuild the HTML anytime content is updated. That approach allowed me to run SSR without all the performance issues it would bring otherwise.

I don’t have exact numbers but I can provide them if anyone’s interested.

Using Next.js for a blog/home website (not PWA) is overengineering. Why not just put a static website made in Publii, hugo or similar and just sparkle it with a bit of vanilla JS where it is appropriate? This is how it should be - progressive enhancement. Requesting hundreds of KB of JS code just to show a static content is bad practice. KISS!

That is why Request per seconds has been a meaningless measurement for the past 20 years. A page view would be a better metric. Whether that is 1 request or 100 request.

That is especially true when comparing a site done with Rails + Hotwire vs Others + React / Client Side Rendering.

> One key thing to underline: each request in the test is just a single call to the pre-rendered Next.js page. No assets are requested. A real visitor would need 60+ additional requests. That means as few as three simultaneous visitors could push the server dangerously close to its limit.

Ok but remember browsers will reuse HTTP connections, HTTP2 introduces multiplexing, and browsers have tight mode. So you can't just take the figures for 1 request and divide by 60 to get the real world performance.

I just don't understand how this can be this slow. What on earth is it doing to get 193 requests per second on static, cached content?

The article doesn't dig too deep into this sadly, rather just accepts that it's slow and uses a different tool.

But seriously, this is responding to a request with the content of a file. How can it be 100,000x slower than the naive solution. What can it possibly be doing, and why is it maxxing out the CPU?

If no-one else looks into this, I might get around to it.

No mention of https://nodejs.org/api/cluster.html#cluster? Not sure if NextJS supports it even, but if you are only using one core of your webserver for node, you are leaving stuff on the table.

Maybe hn could periodically hide ddosed sites on the front page.

I ran a script once that would show an archived copy for links that stopped working. Then ended up hosting/stealing most of someone website which moved to a different domain. The concept was nice tho.

I've been down the same path with next.js. When seeing terrible performance after testing with k6, I pushed all static files (js, css, images etc) to a cdn.

This way only the first request hits your actual server, the rest is handled for you.

I think these stats are for running with the built in next.js server?

For shits and giggles, you should try compiling to completely static files, then host them with nginx.

have you considered using remix?