What is Next.js? The React Framework Explained

What is Next.js?

Next.js is a React framework for building full-stack web applications. You write the interface with React components, and Next.js adds routing, server rendering, data fetching, caching, image and font handling and a build tool, so you do not assemble them yourself. Vercel develops it, and you can host it on a Node.js server or in a Docker container.

Versions and routers

At the time of writing (October 2026) the latest release is Next.js 16.4, published on 6 October 2026. Next.js 16 made Turbopack the default bundler, replaced middleware.ts with proxy.ts and requires Node.js 20.9 or newer. The current docs describe two routers: the App Router, which supports newer React features such as Server Components, and the original Pages Router, which is still supported. New projects start on the App Router. Check the official docs for the version you run, because defaults have changed between releases.

How Next.js renders pages

Next.js lets you choose how each route is rendered, instead of one strategy for the whole app:

• Static rendering (prerendering): the page is built ahead of time and served as a file, which is the cheapest to serve and works well behind a CDN. See static site generation.
• Dynamic rendering: the page is rendered on the server for each request, which suits personalised pages. See server-side rendering.
• Incremental static regeneration (ISR): a static page is regenerated in the background after a set time or on demand. The next request after the interval still gets the cached page while the new one builds.
• Streaming: the server sends the page in parts as each one is ready, so slow data does not hold up the whole page.
• Cache Components: a newer model where you mark parts of a page with 'use cache' and the rest renders at request time. Next.js 16.4 recommends it for every app and enables it for new apps created with create-next-app, and the team says it becomes the default in Next.js 17.

Server and Client Components

In the App Router, layouts and pages are Server Components by default. They run on the server, can read databases and use secrets, and send no component code to the browser. Add the 'use client' directive to a file when it needs state, event handlers or browser APIs. The browser then receives HTML for a fast first view and JavaScript that hydrates the interactive parts. Keep 'use client' on small interactive components, not on whole page trees, so the JavaScript bundle stays small.

A small example

This App Router page is prerendered for each blog post and regenerated at most once an hour:

// app/blog/[slug]/page.tsx
export const revalidate = 3600 // regenerate at most once an hour

export async function generateStaticParams() {
  const posts = await fetch('https://example.com/api/posts').then((r) => r.json())
  return posts.map((p) => ({ slug: p.slug }))
}

export default async function Page({ params }) {
  const { slug } = await params
  // ...fetch the post and render it on the server
}

Common Next.js mistakes

• Marking everything 'use client'. It pulls the whole subtree into the browser bundle and cancels the benefit of Server Components.
• Assuming the caching rules of an older version. Defaults have shifted between releases, and Cache Components make caching opt-in. Read the guide for your version and test with a production build.
• Expecting ISR everywhere. ISR needs the Node.js runtime and is not supported in a static export. With several server instances, the default cache is per instance, so you need a shared cache handler.
• Skipping upgrades. The Next.js team publishes security releases regularly. Pin a patched version and watch the release notes.
• Using a plain image tag. The next/image component resizes and caches images for you, a raw img does not.

Next.js, performance and load testing

How a route is rendered decides where the cost lands. A static page is cheap per request, while a dynamically rendered one spends server CPU on every visit, so its time to first byte and capacity change under traffic. That is exactly what a load test shows: ramp up virtual users against your dynamic routes and API routes, then watch response time and errors. Compare a cached route with an uncached one to see what caching buys you.

On the user side, page speed monitoring tracks Core Web Vitals such as largest contentful paint after each deploy, and the free Core Web Vitals checker gives a quick reading for one URL. Our guide to performance budgets for web apps shows how to turn those numbers into limits. If you work in Vue instead, Nuxt is the counterpart, and React is the library underneath Next.js.

FAQ: Next.js

Is Next.js a framework or a library?

Next.js is a framework built on React. React is the library for building the interface, and Next.js adds routing, rendering, caching and tooling around it.

Who makes Next.js?

Vercel develops Next.js, and the code is open source on GitHub. You can deploy it on Vercel or on your own infrastructure.

What is the difference between the App Router and the Pages Router?

The App Router is the newer router. It supports React Server Components, nested layouts and streaming. The Pages Router is the original one and is still supported. Both can exist in one project during a migration.

Is Next.js good for SEO?

It can be, because pages can be rendered to HTML on the server or at build time, so crawlers receive content without running your JavaScript. Good results still depend on fast pages, clean metadata and useful content.

Do I need Vercel to host Next.js?

No. Next.js runs on a Node.js server or in a Docker container, and platforms can support it through adapters. Features like ISR then need the setup described in the self-hosting docs, for example a shared cache when you run more than one instance.