Next.js vs React — the differences that show up in your bill and in Google

The question usually shows up in this form: React or Next.js? — and it is the wrong question, because these are not two competing technologies to choose between.

Next.js is React with a server layer bolted on. Choosing it does not mean giving up React — you add a server that assembles the page first. The whole decision comes down to one question: does any of your pages need to be visible in Google and fast on first load.

This is for you if a proposal on the table names one or the other and you want to know what actually stands behind it — in your bill, your visibility, and who you will need to hire in two years. It also covers where Next.js loses, a question that never comes up in a sales pitch.

What actually separates React from Next.js — one sentence the rest of this text returns to

React is a library that builds the interface in the user's browser. The server sends a nearly empty HTML file plus a JavaScript bundle; only that JavaScript then draws what appears on screen.

Next.js is the same React, but with a layer that does that work earlier — on the server, or already at build time. The browser receives finished HTML with content in it, and the JavaScript arrives afterwards to bring interactive parts to life. On top of that come things you assemble yourself from separate libraries in plain React — routing, image and font optimisation, code splitting, server-side data fetching. In Next.js they are there from day one.

This distinction is not academic — everything below follows from it, and it is today's default market choice: according to State of React 2025 (3,760 responses, November 2025–January 2026), 78 percent of new React applications are built on Next.js, React's most widely chosen meta-framework — which translates directly into developer availability.

One thing needs spelling out, a common source of confusion once a project is delivered: in Next.js not everything happens on the server. Pages split into pieces the server assembles ready-made, and pieces that have to run in the browser because they react to a person.

What naturally lands server-side is anything meant to be read: service descriptions, product cards, articles, listings, navigation. What stays in the browser is anything that reacts to a click: forms, calculators, maps, filters, the basket, chat. The practical conclusion is that choosing Next.js does not mean the page suddenly "has no JavaScript" — it means JavaScript stops being a condition for seeing the content and becomes a condition for using the features.

Four differences you can see in your bill and in Google

Visibility: Google has two queues, and your site lands in one of them

This is the difference that decides the choice most often — and also the one sales pitches describe in the vaguest terms ("Next.js is better for SEO").

Here is the mechanism. Googlebot fetches the HTML file first. If it is a browser-rendered application — plain React with no server layer — that file is empty: a page skeleton and a script reference, no content. Seeing the content means running that JavaScript, which takes separate resources, so the page moves to a second, rendering queue and waits its turn. According to Google, a page may stay in this queue for a few seconds, but it can take longer (Google Search Central); in a 2024 measurement by Vercel and MERJ (more than 37,000 renders) the median was 10 seconds, the 90th percentile about 3 hours and the 99th about 18 hours. What matters more than the wait itself is that the content and links of a purely browser-rendered page depend on rendering succeeding — and links that exist only in JavaScript are discovered only after it.

With server-side rendering or static generation, the first response already contains the content and the links. Google still queues the page for rendering, but the content does not depend on when — or whether — that happens, and crawlers that do not run JavaScript at all, such as GPTBot or ClaudeBot, only ever see this version (Vercel, 2024). This is not an industry interpretation — Google itself describes the split between fetching and a separate rendering stage in its documentation on JavaScript in search, with the caveat that rendering is deferred until resources are available for it.

Google's queues are real and can be long even at the fetching stage: in our own corpus, reviewing indexing on our Polish site, forty of seventy-five rejected addresses had their last fetch five to six months before the measurement. Not the rendering queue, but it says the same thing: crawler time is not free.

This stops mattering when a page is only meant to be visible after login. A customer panel, an internal application, a dashboard — Google has nothing to index there, and the server layer buys nothing.

How to check what your site actually sends today

This is a two-minute check that needs no developer, and it settles an argument where the contractor claims one thing and a competitor's offer implies another.

Step one: look at the raw file, not what you see on screen. In the browser, choose "View Page Source" (not "Inspect", which shows the state after scripts have run — exactly what the crawler does not see right away). Search the file for any sentence from your page. If you find it, the content is in the first response; if the file is a dozen lines of script references, the content is only built in the browser.

Step two: check what Google sees. Search Console's URL Inspection tool shows a preview of the rendered code and a screenshot of what the crawler actually saw — not just whether content is there, but whether anything blocked it. Worth running on a competitor's site too, before accepting that "everyone in your industry does it this way".

Time to build: what comes in the box

In Next.js, routing, server-side rendering, image and font optimisation and code splitting are configured by default; in plain React you add and maintain each yourself. How much time that saves depends on what you are building, and we do not know of a study that has measured it, so we will not quote a percentage. The practical consequence is simple: the more of that list your project actually needs, the more a ready configuration pays for itself. Needing one item out of four means buying the whole set for one.

Cost: the difference is a proportion, not a figure

Building in Next.js usually starts more expensive than a simple plain-React application — the server layer is extra infrastructure, extra architectural decisions, and one more place something can break. You recover the difference in upkeep: less custom configuration to keep updated, less gluing libraries together, less work on every additional page — but only if the project actually uses the server layer. On a panel behind a login, you pay for it and never use it.

We deliberately do not quote a rate range here. What you hear in conversations — including from us — is a market observation, not a study with a methodology. If you need numbers you can budget against, use published salary reports broken down by technology and experience level; they update yearly, and an out-of-date rate in a quote is worse than none. We break down everything in the ongoing bill for running a site separately in the article on recurring costs.

Team availability: plain React is becoming a niche today

The instinct says a simpler technology means easier hiring. Here it is the opposite: since 78 percent of new React apps are built on Next.js, a React developer today is by default a Next.js developer, and a team working exclusively in plain React is doing something increasingly rare. Choosing Next.js does not narrow the candidate pool — insisting on your own bespoke React setup, explained from scratch to every new hire, does.

When React is enough, and when Next.js pays for itself

One threshold, checkable in a minute: if you cannot name a page that has to be visible in search, the server layer is a cost with no return.

Choosing between whole platforms rather than frameworks — WordPress, Webflow, headless, a bespoke build — is a different decision, covered in our platform comparison.

Moving from React to Next.js — what it actually means

The most common worry is: "so we have to rewrite everything from scratch". You do not, and that is the practical advantage of this pair over switching to an entirely different technology.

Components stay. Because Next.js is React, your interface code — buttons, forms, layouts, the whole component library you already have — keeps working. What changes is where and when it runs, plus how page addresses are described and how data is fetched. This is rewriting a layer, not the product.

Migration can be staged, and usually should be. New work happens in the new stack, the old site runs alongside it, and you move sections one at a time — starting with whatever needs to be visible in search, since that is where the server layer pays off immediately: offer pages, blog, product cards. A panel behind login moves last, or never.

What to watch. Addresses must stay the same; any that change need a 308 redirect before the old one disappears. This is the most common place a migration costs visibility — not the technology failing, but an incomplete address list. We cover checking this in the article on website testing, and the wider arithmetic of modernisation in the audit.

What it means for your team. A React developer is not learning a new language, only new conventions of the same framework. Our own experience is that the first two weeks go on the conventions, and the real friction shows up not in learning but in deciding what should run on the server and what in the browser — a design decision, not a technical one.

Vue, Angular and Astro — the same arithmetic in other frameworks

React is not the only way to build an interface, and Next.js is not the only server layer on the market. Google's two-queue mechanism works identically in every one of these worlds — only the tool's name changes.

Vue and Nuxt

Nuxt is to Vue what Next.js is to React: server-side rendering, static generation, routing and optimisations added on top. If someone proposes Vue, the server-layer question is the same, and the answer is Nuxt.

Two differences matter to a client. Entry can be gentler — Vue's syntax is closer to plain HTML, so a developer knowing HTML, CSS and basic JavaScript starts working faster than in React. The candidate pool is smaller, though, which usually tips the scale for a project meant to live for years: not whether you find a contractor today, but whether you find the next one in three years.

Angular

Angular is a full framework with enforced conventions, not a library you assemble the rest around — fewer decisions at the start, more predictable code between teams, at the cost of a steeper entry.

The question of React versus Angular comes up often enough in practice to deserve a straight answer, even without a measured search volume behind the phrase for this market. The answer is dull: if you have a team that works in Angular, you do the arithmetic in Angular. Rewriting a working application in React just to add server-side rendering is the most expensive route to an outcome your own framework can also reach.

Astro — when the whole layer is overkill

If you are building a content site — no login, no basket, no server-side logic, but a lot of text to show — Astro does exactly that one job, and does it more simply. This is not a choice against Next.js, it is matching the tool to the scope: in the State of React 2025 survey, Astro leads Next.js by 31 percentage points in developer satisfaction (92% versus 61% positive ratings among users; two years earlier it was 94% versus 85%), and the most common complaint about Next.js is precisely its growing complexity.

What this comparison deliberately leaves out: numbers claiming a project gets built X percent faster in one ecosystem than another. We do not know of a study that has measured this on comparable projects, and every such number circulating online is somebody's impression dressed up as a measurement. The only comparison that means anything happens on your own project, with your own team.

How it looks for us — Next.js 16, Payload and PPR

This site runs on Next.js with Payload CMS, so there are things we can say first-hand rather than from somebody else's documentation.

Next.js 16 (21 October 2025) introduced Cache Components — a model built on Partial Pre-Rendering and the use cache directive. The current stable release is 16.3 (3 August 2026); details in the release notes. What PPR means for the bill, not the architecture:

• Speed. The static shell of a page — header, layout, content that does not change — ships from the CDN in milliseconds, because it is ready before anyone arrives. Dynamic fragments — stock levels, per-customer prices, basket contents — stream in afterwards onto the page that is already visible.
• Cost. The server fills in only what it has to, instead of rebuilding the whole page on every visit. Under classic server-side rendering, every visit costs a full unit of CPU work; here it costs a fraction — which shows up directly on the infrastructure bill, covered in more depth when choosing hosting.

And now the wall we hit that is not in the documentation. Turning on Cache Components requires the global cacheComponents flag. Payload 3.x does not work with that flag on: the admin panel uses Date.now() internally and dynamic data access, which conflicts with pre-rendering's assumptions — and Next.js will not let you enable the flag for just a selected group of routes. It is global or nothing.

The conclusion worth knowing before picking a stack: build on Payload and want PPR, and the admin panel and the frontend have to be two separate deployments. Doable, but plan it at the start — rebuilding a working site into two deployments later costs far more than setting it up that way from day one. More in our article on Payload CMS.

Smaller, but felt daily: since version 16, Turbopack is the default bundler for both dev and production builds, and the 16.2 notes report next dev starting four times faster and rendering roughly twice as fast.

Where Next.js loses. In fairness, its dominance is about adoption, not satisfaction — the same 78 percent describes what people choose, not what they are happy with. The recurring complaint is growing complexity, and for a purely content-driven site Astro is often the better fit, covered above. That is not an argument worth leaving out of a proposal.

What this choice will not fix

A framework decides how fast and in what form content reaches the browser and the crawler. It decides nothing about whether anyone gets in touch with you.

It will not fix an offer that is not on the page, or text that does not answer the customer's question, or build visibility for a site nobody links to — server-side rendering speeds up indexing content, but it does not create a reason to show it.

If a technology decision is the first decision on your project, it is probably being made too early. The five decisions that come before it are covered in our website strategy guide. And if a site is already live and you want to know what is actually slowing it down before anyone proposes rewriting it from scratch — start with measurement, not the framework.

Numbers from our own site

The best evidence for what a framework does not fix sits on our own network. This site runs on Next.js with server-side rendering, content in the first response exactly as described above — and yet in September 2026 we reviewed 124 addresses on digitalvantage.pl, our Polish-market site, that Google does not show in results, split into four states:

Seventy-five were crawled and rejected — a quality judgement, not a technical problem. Twenty-five Google does not know about at all, because nothing links to them. Twenty-two it knows about but never got around to fetching. Two we excluded ourselves with a noindex tag and forgot about it for months.

None of these four states changes with a choice between React and Next.js. The server layer buys one thing: once the crawler shows up, it has something to index straight away. Whether it shows up at all, and whether it decides the content is worth surfacing, is settled elsewhere.

Five questions that show whether your contractor is counting the same thing you are

Not technical, and no framework knowledge required. Each one checks whether there is a decision behind the answer, or just a habit.

1. Which pages have to be visible in Google, and which sit behind a login? "All of them" means nobody has actually worked this out — and it is the one question that decides the server layer.
2. What exactly will run on the server, and what in the browser? "The framework handles that" is not an answer.
3. What does the list of addresses look like before and after the change, and who issues the redirects? Asked before deployment, this costs one sentence; asked after, it costs rankings.
4. What will we measure the effect with, and what is the value before the change? Without a before-figure there is no way to show an improvement. A useful, checkable threshold: Largest Contentful Paint should sit within 2.5 seconds, and above 4 seconds is rated poor.
5. What happens when the framework ships its next major version? The answer shows whether maintenance is in the contract, or a separate conversation next year.

Where these numbers come from

• 78 percent of new React apps on Next.js — State of React 2025, 3,760 responses, November 2025–January 2026. Checked at source on 11 September 2026.
• Astro's 31-point lead in developer satisfaction — the same survey. Satisfaction is the share of positive ratings among users who gave an opinion, in the meta-frameworks section: Astro 94%, 94% and 92%, Next.js 85%, 75% and 61% in the 2023, 2024 and 2025 editions. Read at the publisher on 5 October 2026.
• Rendering queue timings — Google Search Central, JavaScript SEO basics and the Vercel and MERJ study (2024); AI crawlers not rendering JavaScript — Vercel, December 2024. Read on 5 October 2026.
• Dates and changes in Next.js 16 — the project's own release notes: the 16 release of 21 October 2025, stable 16.3 of 3 August 2026, Turbopack default since version 16, figures from the 16.2 notes.
• The Payload 3.x / `cacheComponents` incompatibility — our own deployment, not any project's documentation.
• 124 invisible addresses in four states, 40 of 75 rejected with a last crawl five to six months earlier — our own Search Console review on digitalvantage.pl, 8 September 2026.
• Rate ranges — deliberately omitted. What we say in conversation is a market observation, not a study; numbers with a methodology come from published salary reports.