I default to Next.js for a reason that has almost nothing to do with performance

Framework choice is usually developer preference dressed up as strategy, and I say that as someone whose default has been Next.js for years. The reasons I would give another developer are not the reasons that matter to the person paying for the project, and the gap between those two lists is worth writing down, because the second list is the one that survives contact with a budget.

The problem it solves is a rendering problem, not a framework problem

A plain React application renders in the browser. The visitor downloads a JavaScript bundle, the bundle runs, and only then does content appear. Behind a login that is completely fine and often the right architecture. For anything that needs to be found, it is bad, because the first thing a crawler or a three-year-old phone receives is an empty document with a script tag in it.

The standard answer is to bolt server rendering onto React by hand. That is not a weekend. It is a genuine engineering project with its own maintenance bill, its own subtle hydration bugs and its own bus factor, and it competes for time with the actual product.

Next.js ships that as the default posture rather than as an achievement. Pages render on the server, the browser receives real HTML immediately, and JavaScript takes over only for the parts that genuinely need it. You get app-grade interactivity where you want it and document-grade indexability everywhere else, and you are not the one maintaining the seam between them.

The features that pay for themselves are the boring ones

Images are the largest thing on most pages, and they are handled properly without a plugin: modern formats, correct sizes per device, lazy loading below the fold, and reserved space so nothing jumps while loading. On a typical marketing site that single feature is worth more to a Core Web Vitals score than anything else on the optimisation list, and it arrives for free.

Alongside it, route-level code splitting so a visitor to the contact page does not download the checkout logic. Font subsetting so text renders without a flash. Metadata handled as data rather than as tags somebody remembers to update when a page gets duplicated.

None of that is exotic. Every one of those is something a competent team does by hand when there is time and skips when there is not, and there is never time in month four. The argument for the framework is not that it can do these things. It is that they are the path of least resistance rather than the path of most discipline.

SEO controls as code, which matters more now than it did

Per-page titles, canonical URLs, hreflang across multiple language deployments, structured data, sitemaps generated from real content, redirects when a slug changes. All of it is code, versioned alongside everything else, reviewable in the same place as the rest of the application. On a hosted platform, several of those are whatever the vendor decided to expose this year, and that list changes without asking you.

This got more consequential rather than less when answer engines started reading the same signals. Clean server-rendered HTML with correct schema is what a classic crawler needs and what a retrieval system needs, for the same underlying reason: both have to work out what the page says and decide whether to trust it. The technical work behind ranking and the technical work behind being cited are, at the level where you actually do them, the same work.

Being on the mainstream path is a hiring decision

Here is the part that is genuinely commercial, and that developers tend to skip because it feels unambitious.

Stack Overflow's 2025 developer survey puts Next.js at the top of the web frameworks and technologies section across respondent segments, at roughly 21 to 24 per cent, consistently ahead of Express and ASP.NET Core. That number is not a quality claim and I am not presenting it as one. It is a supply claim. It means the documentation is thorough, security patches are frequent, most problems have already been solved publicly by somebody else, and when the client eventually replaces me they will not struggle to find a person who recognises the conventions in the codebase.

A niche framework can be technically lovely and still hand the client a hiring problem three years after the people who chose it have moved on. I would rather build on something with a large maintained ecosystem than on the most elegant option with four contributors and a Discord.

Where I talk people out of it

If a marketing team needs to edit content daily without a developer in the loop, WordPress and its editor ecosystem is frequently the better answer, and saying so has never cost me a project I wanted.

If the site is a handful of static pages that will barely change, Next.js is more machinery than the job needs. Hand-written HTML or a static generator is cheaper to build, cheaper to host, and will still work untouched in five years.

If the hosting is locked to shared PHP with no Node runtime, that is a real constraint and not one to argue with from a slide.

And if an in-house team maintains everything and knows a different stack well, that settles it. Handing a team a framework nobody there can maintain is a worse outcome than a technically inferior stack they can. That failure is not loud. It shows up as a slow accumulation of things nobody wants to touch.

The lock-in question, which clients ask and developers dismiss

"Will we be tied to you if you build it in this?" is a reasonable question and it deserves a better answer than a reassuring noise.

The honest version has three parts. It is an open-source framework with a very large developer pool, so the supply argument above cuts in the client's favour rather than mine. The code is theirs. And it runs on any host with a Node runtime, which is most hosts — it does not require a specific platform-as-a-service, whatever the deployment tutorials imply by only ever demonstrating one.

That last part is worth saying out loud because the ecosystem's documentation creates a strong impression otherwise. This site runs on ordinary shared hosting with Node support. That is not a clever trick; it is the default capability, obscured by the fact that nobody writes tutorials about boring hosting.

Where genuine lock-in does creep in is one level up from the framework: platform-specific middleware behaviour, image optimisation that assumes a particular CDN, storage and auth SDKs that only exist on one vendor. Those are choices made inside the project rather than consequences of the framework, and they are worth being deliberate about at the start, when avoiding them is free.

The thing that actually goes wrong on these projects

Not performance. Not SEO. The bundle.

Server Components ship no JavaScript to the client, which is the entire mechanism behind the payload difference, and it is easy to lose without noticing. One "use client" at the wrong level of the tree pulls everything beneath it into the client bundle, and nothing in the development experience tells you that happened. The page still works. It is just heavier than it was last month, and then heavier again, and six months later somebody runs an audit and finds the marketing site shipping half a megabyte of JavaScript for three interactive elements.

The discipline is unglamorous and it is the whole game: push client boundaries as far down the tree as they will go, check what the build actually emitted rather than what you assumed, and treat a growing first-load figure as a bug rather than as weather.

A framework that makes the right thing the default still lets you opt out of it accidentally, and on a long-lived project that is where the performance goes.

The one question that decides it

Does the thing need to be both discoverable and interactive?

Product configurators, multilingual catalogues, portals, booking flows, anything with a real front end that also has to rank. That is where server rendering plus a real component model earns its cost, and where doing it by hand costs more than the framework does.

A brochure that needs to exist, load fast and be found does not need any of it, and I would rather say so than sell the harder build. The uncomfortable version of the framework argument is that a lot of sites are the second thing, which means the honest default for an agency is not one framework but a short list with a written rule for choosing between them.

Read the full version

This is the condensed version. The full article covers the WordPress comparison in more detail, what happens to portability and lock-in, the hosting requirements in practice, and where the line falls in package terms.

Why We Build with Next.js, and When We Don't

This copy is a snapshot from the day it was posted, and it will not be updated here. The original on our site is the version we keep current: when a study publishes new figures, a price changes or a tool is renamed, that is where the correction lands. If you want the up-to-date version, follow the link above.

Sources

The framework capabilities described above are documented in the Next.js documentation, and the rendering model underneath the App Router is the React team's own Server Components reference. The adoption figure is from the Stack Overflow 2025 Developer Survey, technology section. The metrics that the image handling, code splitting and font work are optimising for are defined on web.dev. Which projects it suits, and which it does not, is my own judgement.

If you have moved a content-editing team from WordPress onto a headless Next.js front end, I would like to know how the editing experience landed six months later, because that is the part I find hardest to predict in advance.