Why Companies Are Moving Away from Next.js

Several companies have announced troubles with Next.js lately, and this has come as a surprise to most developers working in web development. As a result, some are reconsidering its use or even moving away from the framework entirely. As per a recent report, hackers are exploiting critical points and have found vulnerabilities in the framework.

This, however, is just one of the factors at play. For years, Next.js has been the preferred framework for React developers, promising performance, SEO benefits, and a streamlined developer experience. Yet, lately, more companies are ditching it and not considering a return. 

Promise vs Reality

Next.js markets itself as an all-in-one solution, offering static site generation (SSG), server-side rendering (SSR), and built-in optimisations. In theory, it is perfect. In practice, however, not so much.

Companies like Northflank, which handle tens of billions of requests, initially bought into the promise of Next.js. However, even for something as straightforward as their marketing site, where Next.js should have been the ideal choice, it encountered significant performance bottlenecks. 

“When we started running into issues, we did what any sane team would do: we tried to fix them. Then we tried again. Then we realised the problem was Next.js itself,” Northflank wrote in a recent blog.

Northflank ran tests comparing Next.js to a custom-built React SSR solution and saw massive improvements. Not only the first contentful paint got four times faster, the speed index reduced from 8.4 seconds to 1.7 seconds.

Next.js’s inefficiencies persisted even with a content delivery network (CDN) in place. “Google doesn’t wait. Users don’t wait. Next.js makes them wait,” Northflank added.

Basic page renders took anywhere from 200 to 400 milliseconds, while more complex, dynamic pages could spike beyond 700 milliseconds. When Google crawlers or SEO monitoring tools hit multiple pages simultaneously, the site would crash several times a week. 

SEO, which was expected to be a major strength of Next.js, also became a pain point instead. While server-side rendering is theoretically beneficial for search rankings, slow render times negated any advantage. 

In December, Northflank saw its SEO performance drop significantly. Google penalised its slow-loading pages, resulting in the loss of valuable rankings. Users complained about sluggish documentation pages, and the anticipated benefits of Next.js for SEO proved to be a marketing illusion.

Industry Wide Phenomenon

One of the main reasons companies are moving away from Next.js is its sluggish performance at scale. Despite its claims of speed, many developers have experienced the opposite.

Eduardo Bouças, web design and development blogger and principal engineer and technical advisor to the CTO at Netlify, recently posted a lengthy blog on the problems he faced with Next.js lately. He raised concerns about Next.js governance, claiming Vercel tightly controls the framework, which limits portability and competition. 

He highlighted security mismanagement and proprietary dependencies that make it hard for other providers to support Next.js fully. While not discouraging its use, he urged developers to make informed choices.

A major selling point of Next.js is its SEO capabilities. However, when users’ pages take forever to render, search engines don’t care how ‘static’ it is.

The constant changes in Next.js’s philosophy have left developers feeling like they’re chasing a moving target. Initially, the framework built its identity around Jamstack and static site generation, before pivoting to serverless and back to server-side rendering. 

Now, with the latest updates, it’s once again shifting towards microVMs. Each shift leaves developers scrambling to refactor their applications, only to watch the framework abandon its previous direction yet again. This pattern of rolling out new paradigms, pushing them aggressively, and then dropping them when flaws become apparent has left companies exhausted.

On platforms like Reddit and Hacker News, developers have expressed their frustration with Next.js’s ever-evolving structure. Many compare it to the chaotic history of React Router, which underwent major breaking changes every few versions, forcing developers to constantly refactor their code with little tangible benefit. 

The introduction of the App Router in Next.js only reinforced this sentiment. One developer noted that Next.js seems to be reinventing itself unnecessarily, complicating what should be a straightforward tool for rendering React applications.

Echoing the frustration, a user on Hacker News said, “I switched from Next.js because it was taking me six to seven seconds on a small project to see changes in the browser during development on an M1 Max MacBook Pro with 64GB of RAM.”

Beyond Technical Issues

There’s growing skepticism around Next.js’s relationship with Vercel. Some developers believe the framework has been subtly engineered to push users toward Vercel’s hosting services. Those attempting to self-host Next.js often encounter unexpected hurdles, making it feel like a vendor lock-in strategy. 

A user on Hacker News, while replying to Bouças’s blog, mentioned how Vercel’s handling of security vulnerabilities raised concerns about conflicts of interest—by rolling out fixes to their platform before public disclosure, they positioned Vercel-hosted applications as safer, leaving self-hosted users vulnerable in the meantime.

The developer experience has also taken a hit. Many have noted that Next.js’s hot module reloading has become painfully slow, with some experiencing delays of about six to seven seconds when updating code. Even on powerful machines, small changes require recompilation, making development frustratingly slow. 

Summing it up, one developer said that Next.js and React have “jumped the shark” by prioritising server-side rendering at the cost of client-side efficiency. Many have turned to alternatives like Vite, Remix, or even rolling their own SSR solutions to regain control over performance and developer experience.

Despite these criticisms, Next.js still has its defenders. Some appreciate its conventions around routing, built-in API routes, and TypeScript support. Others argue that, despite the complexity, it streamlines full-stack development by keeping frontend and backend logic in the same project. 

Next.js still has its place, particularly for teams deeply invested in the React ecosystem who don’t want to consider deployment. However, for companies that prioritise performance, stability, and long-term maintainability, Next.js is becoming harder to justify.

As one user highlighted, “Funny how everything goes through a cycle of ‘it’s amazing, it’s terrible, it’s boring’. Next.js is well into the ‘terrible’ phase.”