AI AI Tools Guidebook
Indie Dev & Website Building

When Next.js Is the Right Pick (and When It Is Not)

Next.js 16 is the default React framework in 2026 — but reaching for it on a content site costs you speed, Vercel bills, and weekends. Here is the decision, with real limits and numbers.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

People reach for Next.js the moment someone says “React.” But the real question is almost never “do I need React?” It is “do I need a hybrid framework that mixes server rendering, client interactivity, and a runtime on the edge?” If the honest answer is no, you have just signed up for complexity you will not use. This guide gives you the decision and the numbers behind it, current as of June 2026.

TL;DR

  • Pick Next.js 16 when the site behaves like an app: per-user state, auth-gated pages, streaming/real-time UI, or request-time server logic on most pages.
  • Pick Astro 5 (or Hugo/Eleventy) when the site behaves like a magazine: blog, docs, marketing pages that are 90%+ prerenderable HTML.
  • The cost of guessing wrong is real: Next.js on Vercel Hobby is non-commercial and capped at 100 GB bandwidth + 1M function invocations/month, with no overage — it pauses when you hit the wall.
  • Run the one-afternoon prototype test below before you commit. The framework that feels less fiddly for your page types is the right one.

What Next.js 16 actually is in 2026

As of June 2026 the stable line is Next.js 16.2, and it is a meaningfully different beast from the Next.js most blog posts describe:

  • Turbopack is the default for next dev and next build — Vercel reports roughly 400% faster dev startup and ~50% faster rendering versus the old webpack path.
  • It ships on React 19.2 (View Transitions, useEffectEvent, the <Activity> component) with the React Compiler promoted to stable for automatic memoization.
  • Cache Components (the use cache directive built on Partial Prerendering) are the new caching model — powerful, and another concept to learn.
  • The App Router is the primary paradigm; Pages Router is in maintenance — still supported, but new features land in App Router only.

All of that is genuinely capable. It also rewards an interactive product surface, not a folder of Markdown. Almost every indie “I picked Next.js” post-mortem ends the same way: “my site was 99% static and I spent three weekends fighting Server Components and the cache.”

Shape comparison in 30 lines

A dashboard page where Next.js earns its complexity — per-request data, server-only auth, streamed to the client:

// app/dashboard/page.tsx — RSC + per-request data, streamed
import { Suspense } from 'react';
import { getUser } from '@/lib/auth';
import { getOrders } from '@/lib/db';

export default async function Dashboard() {
  const user = await getUser();          // request-scoped, server-only
  const orders = await getOrders(user.id);
  return (
    <>
      <h1>Hi {user.firstName}</h1>
      <Suspense fallback={<p>Loading recent orders…</p>}>
        <OrderList orders={orders} />
      </Suspense>
    </>
  );
}

A content page where Astro wins — built once, served as static HTML, zero JS shipped by default:

---
// src/pages/blog/[slug].astro — built once, served as HTML
import { getEntry, render } from 'astro:content';
const post = await getEntry('blog', Astro.params.slug);
const { Content } = await render(post);
---
<h1>{post.data.title}</h1>
<Content />

If your core pages look like the first example, you need Next.js. If most pages look like the second, you do not.

The decision table

SignalLean Next.js 16Lean Astro 5 / Hugo
Page mixMostly per-user / interactive90%+ static, prerenderable
Auth-gated pagesMost of the siteA login form, maybe an account page
Real-time / streaming UIChat, live data, partial responsesNone or rare
Request-time logicPersonalized SSR, A/B tests, geoBuild-time is enough
JS shipped to the browserAcceptable for app valueMinimize for LCP/INP
Your daily stackYou write React alreadyYou want one HTML-first model
Hosting realityFunction execution is the productStatic CDN, near-zero cost

If you tick the left column on the majority of rows, Next.js pays for itself. If you tick the right column, Next.js is overhead you will spend weekends maintaining.

Why hosting cost decides more than people expect

The Next.js choice is also a hosting choice, because SSR and serverless functions are billed by execution. The numbers below are current as of June 2026; verify the live tiers before you rely on them.

PlanCostBandwidth incl.Functions / CPUCatch
Vercel HobbyFree100 GB1M invocations, 4 hrs Active CPUNon-commercial; no overage, deployment pauses at the cap
Vercel Pro$20 / seat / mo1 TB~1,000 GB-hrs incl.Overage $0.15/GB bandwidth, $0.128/Active-CPU-hr
Firebase Hosting (Spark)Free10 GB/mo + 360 MB/dayCloud Functions on Blaze onlyCommercial use is fine; static-first

A static Astro/Hugo site is almost all CDN bytes, so it sits comfortably in a free tier even when a post hits the front page of Hacker News. A Next.js SSR site bills every request that renders on the server. The same traffic spike that costs an Astro site nothing can pause a Hobby deployment or run up a Pro bill. If your content rarely changes per request, you are paying for a runtime you do not need.

Two practical notes: Vercel’s Hobby tier forbids commercial use, so a side project that earns money already needs Pro or another host. And next start runs fine on a cheap VPS or container if you would rather not be on Vercel at all — you just take on the ops yourself.

Run the one-afternoon prototype test

Hype is a bad way to pick a framework; friction is a good one. Spend one afternoon and decide from the prototype, not the blog post.

  1. Inventory page types. Write down every page on the site and tag each as static, per-user dynamic, or interactive app.
  2. Apply the 90% rule. If 90%+ are static, stop and try Astro or a static generator first. Revisit Next.js only when you actually hit a wall.
  3. Map the dynamic pages. For each one, list its data source and whether it needs request-time rendering or build-time is enough.
  4. Estimate execution cost. Per-request SSR on a free tier can throttle or pause under modest traffic. Check your worst page against Vercel’s function and bandwidth limits above.
  5. Build the same page twice. Prototype one representative page in both Next.js 16 and Astro 5 in an afternoon. The friction tells you which model fits your taste.
  6. Re-evaluate at scale. Decide from the prototype, then re-check at 50 and 500 pages — content sites most often regret an SSR-first choice later, not on day one.

Common pitfalls

  • Treating Next.js as a static-site generator. It can do output: 'export', but you lose SSR, ISR, image optimization, and middleware — at which point Astro is the cleaner, faster fit.
  • Underestimating the App Router curve. Server vs client boundaries, the use client rule, and the new Cache Components model trip up developers who learned the Pages Router.
  • Assuming Vercel is free forever. The Hobby tier is non-commercial and uncapped only until you hit 100 GB or 1M invocations — then it pauses.
  • Picking it because “everyone uses it.” Popularity is not a substitute for matching the tool to the workload. Most indie regret traces back to this one line of reasoning.

Who this is for, and who should skip it

Build with Next.js 16 if you are an indie dev shipping a product-shaped site — a SaaS dashboard, an AI chat tool, a marketplace — where React plus per-request server logic plus streaming actually earn their keep.

Skip it for pure content sites: blogs, docs, and landing pages that update via Markdown and rarely need request-time work. Reach for Astro, Hugo, or Eleventy and keep your hosting bill near zero.

FAQ

  • Is Next.js overkill for a blog?: Usually yes. A blog is 99% static HTML. Astro 5 ships less JavaScript, builds Markdown roughly 5x faster than its legacy pipeline, and deploys cheaper. Use Next.js for a blog only when it is bolted onto a real app.
  • Can Next.js do pure static output?: Yes, via output: 'export' — but you give up SSR, ISR, image optimization, and middleware. If that is all you need, ask why you are using Next.js at all instead of a static generator.
  • Will Next.js hurt my Core Web Vitals?: Not inherently. But large client bundles and unmemoized components can. Astro tends to ship near-zero JS by default, which is a head start on LCP and INP; Next.js 16’s React Compiler and Cache Components narrow the gap if you use them well.
  • Is the Pages Router dead?: No. It is supported and stable in 2026 but in maintenance mode — new features land in the App Router. Start new projects on the App Router unless you have a specific migration reason.
  • Do I have to host Next.js on Vercel?: No. next start runs on any Node host (a VPS, a container, or platforms like Netlify and Cloudflare). Vercel is the smoothest path for App Router features, but you can self-host and take on the ops yourself.

Tags: #Indie dev #Next.js #Website planning #Comparison #Getting started

Related Articles