Why we ditched Next.js and never looked back

At Northflank, we obsess over performance, reliability, and developer experience.

We help companies deploy and scale applications that handle tens of billions of requests. We’ve built and optimized everything from marketing sites to complex, real-time web applications, so we know what it takes to scale both. Our core platform runs on hundreds of routes, real-time RPC methods, and WebSocket subscriptions, all managing intricate real-time state.

We’ve successfully scaled SSR-based marketing and documentation sites as well as high-performance, real-time applications.

When we first chose Next.js, we understood the trade-offs—SSR frameworks work well for marketing and docs, while SPAs are better for real-time, data-heavy apps. We made that decision with years of hands-on experience in both.

But even for our marketing site—where Next.js should have been the ideal choice—we hit significant challenges that ultimately led us to look for alternatives.

When we started running into issues with Next.js, we did what any sane team would do: we tried to fix them. Then we tried again. Then we realized the problem was Next.js itself. So we pulled the plug.

Server-side rendering (SSR) isn’t hard if you know what you’re doing. Next.js and Vercel have boxed developers into an unnecessarily complex ecosystem.

If you’re struggling with Next.js, this might be useful.

The promise vs. the reality of Next.js

Next.js sells itself as an all-in-one solution: great performance, built-in static site generation (SSG), server-side rendering (SSR), seamless SEO, and a smooth developer experience.

In theory, it’s perfect. In practice, not so much.

A framework without conviction

Next.js’s performance issues are one thing, but the constant shifts in its philosophy are even worse.

The same company that built its entire identity around Jamstack and static site generation pivoted to serverless, then became the cheerleaders of SSR—the complete opposite of what they originally pushed.

Now, they’re moving away from serverless again in favor of microVMs—who’d have thought? (We did).

At this point, it’s become a pattern. Roll out a new paradigm, sell it hard, ignore the warning signs, then drop it and move on when the problems become too obvious to hide. Every time, developers are left scrambling to keep up, and companies are stuck cleaning up the mess.

At Northflank, we’ve felt the pull of trends, just like everyone else. But from the start, we’ve stayed clear on what we’re building and why. Our product has changed a lot (it’s grown, improved, and adapted), but the mission has never wavered.

We’ve never chased whatever was trending just for the sake of it. You don’t have to build that way.

Now back to what made us switch.

1. Poor performance

Next.js loves to talk about how fast it is. Yet it’s painfully slow at scale. Here’s what we saw:

• Basic page renders were taking 200-400ms.
• Large pages, especially ones with dynamic content, could spike well beyond 700ms.
• If a Google crawler or our Ahrefs SEO monitoring tool hit multiple pages at once, the site would start crashing multiple times per week.
• Next.js’s built-in caching was unpredictable and inefficient across multiple replicas.

Performance isn’t just a "nice to have." Or at least, not for us. It’s everything.

In a world where milliseconds determine conversion rates, Next.js forces businesses into a suboptimal reality where every interaction carries unnecessary latency.

Google doesn’t wait. Users don’t wait. Next.js makes them wait.

At Northflank, we’ve always had a culture of building things ourselves when existing solutions don’t cut it. Ironically, many of our customers come to us after realizing that DIY infrastructure is harder than expected—but in this case, the choice was obvious.

The alternatives weren’t just bad; they actively got in our way. And because building a high-performance SSR setup isn’t actually difficult when done right, we knew we could fix this faster than continuing to fight Next.js.

To illustrate the problem, we ran tests comparing Next.js against our custom-built solution under the same conditions (same browser, same system resources, no CDN).

After switching from Next.js to our custom-built React SSR solution, we saw massive performance improvements:

Landing page performance:

• First Contentful Paint: Improved from 2.1s → 0.5s (4x faster)
• Largest Contentful Paint: Improved from 5.1s → 0.8s (6x faster)
• Speed Index: Improved from 8.4s → 1.7s (5x faster)

Even if you have a CDN in front, it doesn’t solve Next.js's deeper inefficiencies. Performance bottlenecks persisted regardless of CDN usage.

Cloud Provider Page (Data-Heavy Page):

• First Contentful Paint: Improved from 2.0s → 0.5s (4x faster)
• Largest Contentful Paint: Improved from 3.6s → 0.8s (4.5x faster)
• Total Blocking Time: Improved from 2,810ms → 870ms (3x improvement)
• Speed Index: Improved from 11.0s → 1.9s (6x faster)

2. SEO took a hit

Next.js is supposed to be good for SEO because of SSR and SSG.

Except when your page takes forever to render, search engines don’t care how "static" it is.

We saw this firsthand:

• Our SEO performance halved in December.
• We lost valuable rankings because of slow server-side rendering and JSON bloat.
• Google was actively penalizing us for slow speeds.
• Customers noticed and reported issues with our slow-loading documentation pages.

The irony is that companies buy into Next.js because they think it’s good for SEO, only to find that under real-world scale, it actually works against them.

It’s a textbook example of marketing hype masking systemic inefficiencies.

3. It was a black box

• When Next.js crashed, we didn’t get useful errors.
• When things slowed down, we couldn’t pinpoint why.
• Instead of control, we got a black box with unpredictable performance issues.

There were no good ways to debug slow renders.

At some point, we stopped asking, "How do we fix this?" and started asking, "Why are we using this?"

When enough was enough

We first felt the pain with our documentation platform. Our docs were incredibly slow—customers noticed, we noticed, and our SEO rankings noticed.

Then our marketing site started experiencing the same problems.

At this point, we had two choices:

1. Fight Next.js for another few months.
2. Rip it out and build something better.

We ripped it out.

We didn’t move to Astro or another framework. We built our own server-side rendering system using plain React and Express.

Why?

• We already knew how to build SSR—it’s not hard.
• It took us 3 days to replace Next.js for docs.
• It took us a couple of days to replace it for our marketing site.
• The result? Pages that render in 20ms instead of 700ms.

The real cost of Next.js and Vercel

One of the biggest issues with Next.js is how tightly it’s coupled with Vercel.

• Next.js features often work best (or only) on Vercel.
• Vercel locks you in with expensive hosting.
• Scaling Next.js is a headache because of bad cache invalidation across replicas.

Next.js makes it easy to start, but harder to grow.

The results of our DIY

Since the switch, here’s what we’ve seen:

• SEO rankings bounced back (faster site = happier Google).
• Pages load 50x faster (20ms vs. 700ms).
• No more crashes when a crawler visits.
• Deployments don’t cause massive slowdowns.
• We don’t have to babysit our website anymore.

Should you do it?

If you have a tiny site, Next.js is fine.

But if you care about performance, SEO, scalability, or having control over your tech stack, you might want to reconsider.

Next.js is bloated, slow, and unnecessarily complex.

With Northflank handling our deployments and infrastructure, we built something that scales seamlessly, deploys effortlessly, and actually performs under real-world conditions.

If you're tired of sluggish builds, bloated frameworks, and arbitrary limitations, there are better ways to ship software.