Why Your Website Probably Doesn't Need Next.js

The Default Trap: Why Your Website Might Not Need Next.js

Over the past five years, a curious orthodoxy gripped web development: whatever the problem, the answer was Next.js. Whether building a real-time customer dashboard or an eight-page site for a family dental clinic, teams reached for the React framework that Vercel sponsors.

That was understandable. Next.js solved real friction for complicated applications, unifying frontend React code with backend API routes and giving a smooth deployment path.

But there is a simple fact underneath all of it: Next.js was engineered for applications, not for public business websites. For a brochure site or a small shop, your website probably doesn’t need it: it needs pages that open fast and a monthly bill you can predict.

When you put your website, product pages and articles on a full-stack server runtime, you add a layer of infrastructure that most small businesses have no use for:

• Unpredictable serverless compute invoices and platform lock-in.
• Cold-start latency that undermines the ads you pay for.
• Heavy client-side React bundles that drag down Google Core Web Vitals.
• Framework churn, such as the move from Pages Router to App Router.

For an ordinary business website, static generation via Astro is the fix.

┌─────────────────────────────────────┬────────────────────────────────────────┐
│                           THE ARCHITECTURAL SPLIT                            │
├─────────────────────────────────────┼────────────────────────────────────────┤
│ NEXT.JS SERVER RUNTIME              │ ASTRO STATIC BUILD                     │
├─────────────────────────────────────┼────────────────────────────────────────┤
│ Request -> edge routing             │ Request -> edge routing                │
│   -> spin up a server               │   -> instant cache hit                 │
│   -> run Node.js                    │   -> serve flat files                  │
│   -> ship React JS                  │   -> zero client runtime               │
│   -> 1.2s - 2.8s mobile LCP         │   -> 0.38s - 0.65s mobile LCP          │
│   -> a bill every month             │   -> $0 - $20/mo flat cost             │
├─────────────────────────────────────┼────────────────────────────────────────┤
│ YOU PAY TO RENDER A PAGE            │ NOTHING TO WAIT FOR                    │
└─────────────────────────────────────┴────────────────────────────────────────┘

A note on scale before the numbers. The ledger below is an illustrative model for a business website with 20,000 pageviews a month, not a client result. At that size the hosting gap is small in dollars, but it stretches with traffic, and the ads you pay for land on a page that waits for a server to wake up.

---

1. The Bill: Auditing the Serverless Markup

The first thing you notice is infrastructure cost volatility. Next.js on Vercel bills on usage metrics with real markups over raw cloud infrastructure.

Cost Ledger (illustrative model: 20,000 pageviews a month, one seat, 30 GB)

Cost Vector	Next.js on Vercel	Astro on Cloudflare Pages / AWS S3
Platform seat	$20/mo (Team plan, per seat)	$0/mo (free tier)
Bandwidth (30 GB/mo)	$0.15/GB overage = $4.50/mo	Included, $0
Serverless function invocations	Metered per request	$0.00, no runtime compute
Image optimisation	Billed per source image over quota	Compile-time AVIF/WebP, $0 at runtime
Monthly total	$24.50 and up	$0.00
Yearly total	$294 and up	$0

Paying for serverless cycles to render copy you updated two weeks ago is a waste of money, and it grows with your traffic.

---

2. The Cold-Start Penalty: How SSR Slows the First Visit

Every millisecond of latency costs you enquiries. When Google Ads, a social campaign or an organic search sends someone to a Next.js page, the infrastructure underneath decides what they see.

The SSR & ISR Fallacy

Next.js users are often advised to use Incremental Static Regeneration (ISR) to soften server rendering overhead. In practice, ISR introduces a fragile state machine:

1. When someone requests an expired cache item, the edge server sends a stale page while a serverless function rebuilds it in the background.
2. If traffic spikes, several functions spin up at once, triggering database connection pool exhaustion and cold starts over two seconds.
3. If an upstream API fails, the page errors with a 504 Gateway Timeout or a broken layout.

Next.js ISR Failure Mode:
User Request ──> Cache Miss / Revalidation ──> Lambda Spin (1.8s) ──> CMS Rate Limit ──> 504 Error / Layout Shift
Astro Static Build:
User Request ──> Cloudflare Edge Cache ──> Static Pre-Rendered HTML (22ms) ──> No Server Process To Fail

Astro does all data fetching, markdown parsing and asset optimisation at build time. The output is static HTML and immutable assets, served from edge locations worldwide. No Node.js process to crash, no cold start to wait for, no database query between a customer and the page.

---

3. The Hydration Tax: Interaction to Next Paint (INP)

In May 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as a Core Web Vitals ranking signal. The change landed hard on Next.js sites.

Why Next.js Struggles with INP

Next.js treats the browser as a virtual machine for React. Even a page of plain text, headings and images still ships the React runtime, router logic and component trees. The browser has to:

1. Download the JavaScript bundles (typically 200KB–450KB uncompressed).
2. Parse and compile the script on the device’s CPU.
3. Run the hydration step, walking the DOM tree and attaching React event listeners.

On a mid-tier phone this blocks the main thread for 300ms to 900ms. If a visitor taps a menu then, the page freezes and fails the INP threshold.

Main-Thread Execution Profile:
Next.js Hydration:
[ HTML Parse ] ─── [ React Bundle Download ] ─── [ Heavy Hydration: Main Thread Blocked 650ms ] ─── [ Idle ]
                                                              ▲ User Click Fails / Lags
Astro Islands:
[ HTML Parse ] ─── [ Micro-Island Only: Main Thread Free ] ─── [ Main Thread Completely Idle: INP < 30ms ]

The Astro Islands Architecture

Astro uses partial hydration. By default it generates pure, semantic HTML and CSS with zero JavaScript.

Where a page does need interaction, such as our Scope Estimator or a calculator, Astro isolates that piece into an independent “island” and you decide when it starts:

• client:load: hydrate immediately for critical elements.
• client:idle: hydrate after the first paint is done.
• client:visible: hydrate when the component scrolls into view.

The rest of the page stays as plain HTML, which is why the results are INP < 35ms and perfect Core Web Vitals scores on mobile and desktop.

---

4. Framework Churn and the App Router Quagmire

Beyond bills and latency, you have to account for maintenance. Over the past three years Next.js has churned hard:

• The move from the established pages/ directory to the app/ directory with React Server Components.
• Caching behaviour that flipped: fetch() was cached by default in Next.js 14 and reversed in Next.js 15 after pushback.
• Frequent breaking changes in bundlers (Webpack vs. Turbopack), peer dependencies and deployment adapters.

Your website should be a stable asset, not a testing ground for refactoring. Teams report spending 30% to 40% of their sprint capacity keeping dependencies current.

What Astro Gives You Instead

Astro was designed around the web platform itself:

• File-based content collections: content is authored in Markdown or MDX and validated at build time against strict schemas. If an article is missing a description, the build fails before anything goes live.
• Framework agnostic: you are not locked into React. An Astro site can run a React component, a Vue table and a Svelte animation, or none of them.
• No lock-in: the build outputs standard HTML and assets that run on Cloudflare Pages, AWS S3, GitHub Pages, Netlify, or your own server.

---

5. Moving an Existing Site to Astro

If your site is on a Next.js runtime today, the move is more predictable than most people expect:

┌─────────────────────────────────────────────────────────────────────────────┐
│                             THE FOUR-STEP MOVE                              │
├─────────────────────────────────────────────────────────────────────────────┤
│  STEP 1: CONTENT        Move the copy, articles and case studies into       │
│                         typed content files that build can validate.        │
│  STEP 2: ISLANDS        Turn layout components into static files.           │
│                         Keep only what is genuinely interactive.            │
│  STEP 3: DEPLOY         Point the build at Cloudflare Pages or S3 with      │
│                         immutable cache headers.                            │
│  STEP 4: SWITCH DNS     Move the domain over, check Search Console for      │
│                         two weeks, cancel the old hosting.                  │
└─────────────────────────────────────────────────────────────────────────────┘

1. Content into content collections

Move the copy into src/content/ and define schemas in src/content.config.ts, so every future article is checked for SEO and metadata at build time.

2. Convert components to plain .astro

Turn structural components (headers, footers, hero sections) from React .tsx into native .astro files. That removes a lot of client-side JavaScript. Keep only genuinely interactive pieces, such as an enquiry form, as islands.

3. Deploy and switch over

Deploy the build to Cloudflare Pages, point the domain at the new host, cancel the old compute tier, and check Core Web Vitals.

---

Summary: Match the Framework to the Job

• Use Next.js when building authenticated software, client dashboards and real-time workflows where per-user sessions and per-request computation are the whole point.
• Use Astro when building public business websites, portfolios, content libraries and online stores, where speed and a predictable monthly bill decide whether the site works for you.

A site built on flat files is faster, cheaper, and yours. The site belongs to you, not to a platform.

---

Planning a move off a heavier stack? Model your project scope with the Estimator or look through our Selected Work.

STRUCTURED PROTOCOL // FAQS

Frequently Addressed Technical Inquiries

When does a business actually need Next.js? [+]

Next.js is engineered for software applications where every visitor sees something different: customer dashboards, logged-in workspaces, real-time portals, and pages built from live data on every request. For a normal business website, where the content changes when you publish it, a static site is faster and far cheaper, because it ships as plain HTML with no server to wait on.

Why do marketing websites on Next.js suffer from cold-start latency? [+]

When a marketing site utilizes Server-Side Rendering (SSR) or Incremental Static Regeneration (ISR) on serverless platforms like AWS Lambda or Vercel Functions, uncached requests or revalidation cycles trigger a function cold start. Spinning up a Node.js micro-container requires 800ms to 2.4 seconds of compute initialization before the first byte of HTML can be dispatched, directly degrading Time to First Byte (TTFB) and Largest Contentful Paint (LCP).

What is the financial cost difference between Vercel/Next.js and Astro on Cloudflare Pages? [+]

Vercel charges a per-seat platform fee plus markups on bandwidth beyond the base quota ($0.15 to $0.40 per gigabyte) and on serverless function execution. A small business website with a few thousand visitors a month pays a modest bill, but it pays it every month for pages that were written once. The same site compiled statically with Astro and deployed to Cloudflare Pages or AWS S3/CloudFront runs on unmetered global edge bandwidth, so the hosting line drops to zero.

How does Next.js impact Core Web Vitals and Interaction to Next Paint (INP)? [+]

By default, Next.js ships substantial React runtime client bundles (often exceeding 150KB–300KB of gzipped JavaScript) to hydrate the DOM. During page load, the browser main thread is monopolized parsing and executing this hydration logic, resulting in poor Interaction to Next Paint (INP > 200ms) and Total Blocking Time (TBT). Astro ships zero client JavaScript by default, only hydrating isolated interactive islands when explicitly instructed.

Sources

1. [1] Regional Pricing | Vercel Docs Verifies the bandwidth markup claim: Vercel's published on-demand rates list Fast Data Transfer 1 GB for $0.15–$0.35 and Fast Origin Transfer 1 GB for $0.06–$0.43, depending on region.
2. [2] Next.js 15 | Next.js Verifies the framework-churn claim: the release post states that fetch requests, GET Route Handlers and client navigations are no longer cached by default, reversing the Next.js 14 behaviour.
3. [3] Web Vitals | web.dev Verifies that Google replaced FID with INP as a Core Web Vitals signal: web.dev states INP became a stable Core Web Vital metric in 2024 (the official launch post is dated 2024-03-12).
4. [4] Template directives reference | Astro Docs Verifies the Astro Islands claims: the reference documents client:load, client:idle and client:visible, which hydrates a component once it has entered the user's viewport.