AI AI Tools Guidebook
Indie Dev & Website Building

When Next.js Is the Right Pick for Your Website

Next.js is the default React framework in 2026 — but defaulting to it for a content site can cost you speed, hosting bills, and weekends. Here is when it is the right call.

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

Next.js gets reached for the moment someone says “React” — but the real question is rarely “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 do not need. This guide walks through the real signals.

Background

Next.js 15 + App Router is genuinely capable: React Server Components, partial prerendering, streaming, edge runtime, and a deep Vercel integration. But almost every indie “I picked Next.js” post-mortem ends the same way — “I should have used Astro / Hugo / WordPress, my site is 99% static and I spent three weekends fighting RSC”. The framework rewards interactive product surface, not blog posts.

Shape comparison in 30 lines

A representative dashboard page where Next.js earns its complexity:

// app/dashboard/page.tsx — RSC + per-request data, edge-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 representative content page where Astro wins:

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

If your dashboard page would look like that Next.js example, you need Next.js. If most pages would look like that Astro example, you don’t.

How to tell

  • You have authenticated user state that drives most pages (dashboards, saved items, per-user feeds).
  • You need real-time or streaming UI (chat, partial responses, live data).
  • You already write React for a living and want one mental model across product and marketing.
  • You will run server-side logic per request (personalized SSR, A/B tests, geo content).
  • You expect to integrate a serverless API surface tightly with the frontend.

Quick verdict

Pick Next.js when the site is closer to an app than a magazine. If most pages could be prerendered HTML and the dynamic parts are limited to a contact form and search, Astro will ship faster and cheaper. If you really do need user state, RSC, or streaming, Next.js earns its complexity.

Step by step

  1. Write down every page type on the site and tag each as static, per-user dynamic, or interactive app.
  2. If 90%+ are static, stop here — try Astro or a static generator first; revisit Next.js only if you hit a wall.
  3. For the dynamic pages, list the data sources and whether they need request-time rendering vs build-time.
  4. Estimate function execution — per-request SSR on a free tier may throttle under modest traffic. Check Vercel function and edge limits against your traffic plan.
  5. Prototype a single page in both Next.js and Astro in one afternoon — the friction tells you which framework matches your taste.
  6. Decide based on the prototype, not blog hype. Re-evaluate at 50 pages and again at 500 — content sites often regret SSR-first choices later.

Common pitfalls

  • Treating Next.js as a static-site generator. It can do output: 'export', but you lose half the framework — at that point Astro is a cleaner fit.
  • Underestimating App Router’s learning curve — RSC, client/server boundaries, caching layers, and use client rules trip up people who learned Pages Router.
  • Assuming Vercel is free forever. Hobby tier has bandwidth and function-execution ceilings that bite when a post hits the front page of Hacker News.
  • Picking Next.js because “everyone uses it” — popularity is not a substitute for matching the tool to the workload.

Who this is for

Indie devs building product-shaped sites — SaaS dashboards, AI chat tools, marketplaces — where React + server logic + streaming actually pay off.

When to skip this

Pure content sites (blog, docs, landing pages) that update via Markdown and rarely need request-time work. Pick Astro, Hugo, or Eleventy.

FAQ

  • Is Next.js overkill for a blog?: Usually yes. A blog is 99% static HTML. Astro produces less JS, builds faster, and deploys cheaper. Use Next.js only if the blog 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. At that point ask why you are using Next.js at all.
  • Will Next.js hurt my Core Web Vitals?: Not inherently — but RSC and large client bundles can. Astro tends to ship less JS by default, which is a head start for LCP and INP.
  • Is Pages Router dead?: No, still supported in 2026, but App Router is where new features land. New projects should start with App Router unless you have a specific reason.

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

Related Articles