Your pages are rendered once at build time. The resulting HTML files are stored and served directly from a CDN. No server work happens per request — you're just serving files.

Build time → Server renders HTML once → Files stored on CDN → Requests served instantly

Where this works well: Content that doesn't change often — marketing pages, blog posts, documentation, product landing pages. A CDN can serve a static HTML file to millions of users simultaneously with near-zero latency.

Where this breaks: If you have 500,000 product pages, rebuilding every one of them on every deploy becomes a 40-minute build. And if a product's price changes, users see stale data until the next build.

Point 4: Incremental Static Regeneration (ISR)

The hybrid solution. Pages start as statically generated files. After a configurable time window (say, 60 seconds), the next request triggers a background regeneration. The user still gets the cached version immediately, but behind the scenes Next.js re-renders the page and stores a fresh copy for future requests.

First request → Cached HTML (instant) → Background: re-render if stale → Next request: fresh HTML

Where this works well: Large catalogs where you need near-real-time accuracy but can't afford full SSR costs. E-commerce product pages, news articles, sports scores — content that changes but can tolerate being a few seconds (or minutes) stale.

Point 5: Partial Prerendering (PPR)

The newest point on the spectrum, introduced in Next.js 14 and stabilising in Next.js 15. A single page has a static shell — the nav, the layout, the surrounding structure — served instantly from a CDN, and dynamic holes — the personalised content, the live inventory count, the user-specific data — streamed in from the server immediately after.

Request → Static shell from CDN (instant) → Dynamic slots stream in (milliseconds later)

Where this works well: E-commerce product pages where the product description, images, and reviews are static, but the price, stock status, and "Add to Cart" button are dynamic and personalised.

This is not a course on rendering theory — but every decision you make in Next.js traces back to this spectrum. When you're deciding whether to put 'use client' on a component, or whether to add cache: 'no-store' to a fetch call, or whether to wrap something in <Suspense> — you are making a rendering spectrum decision.

---

App Router vs Pages Router: The Definitive Answer

If you have looked at any Next.js tutorials or job postings in the past two years, you have probably encountered the "App Router vs Pages Router" question. Here is the answer you need before starting this course:

This course covers the App Router exclusively. The Pages Router is legacy infrastructure.

That is not a dismissive statement — the Pages Router powers millions of production applications and will continue to receive security patches and bug fixes for years. If you are working on an existing Pages Router codebase, understanding it is important. But for new development, the question has been settled.

Here is why the App Router exists and why it matters:

The Pages Router was built for a world where SSR meant "run a function on the server before rendering." This worked well for simple cases, but it had a fundamental limitation: data fetching was colocated at the page level, not the component level. If your <ProductDetail> component needed product data and your <RelatedProducts> component needed separate recommendations data, both had to be fetched in a single getServerSideProps function at the top of the page. Every intermediate component had to receive everything as props. The components themselves were stateless recipients.

React Server Components — the foundation of the App Router — inverted this model. Components themselves can now be async and fetch their own data directly. A <ProductDetail> component can query the database. A <RelatedProducts> component can call a recommendations API. They do this on the server, in parallel, with no props drilling and no shared state required.

This is not just a developer experience improvement. It changes the entire architecture of how data flows through your application. It is why modules F-3 through F-5 of this course spend substantial time on the Server Component mental model before touching anything else.

---

The Vercel Relationship

Vercel is the company that created and primarily develops Next.js. The framework is open source (MIT license) and has hundreds of contributors outside Vercel. You can run Next.js on any platform that supports Node.js.

But it is worth being honest about the relationship: some Next.js features — particularly around edge computing, ISR, and certain caching primitives — work best (or, in some cases, exclusively) when deployed to Vercel's infrastructure. The framework is not secretly a vendor lock-in tool, but the deeper you go into the Architect phase of this course, the more you will encounter features where self-hosting requires additional work that Vercel handles automatically.

This course will always tell you when something is Vercel-specific and what the self-hosting equivalent looks like. Module A-14 is dedicated entirely to the deployment matrix and long-lived connections.

For now: you can build and run everything in this course locally, deploy to Vercel for free on their hobby tier, or deploy to any other host. The concepts transfer everywhere.

---

Installing Next.js

You need Node.js 18.17 or later. If you're not sure which version you have:

Create a new Next.js application:

The CLI will ask you several questions. Here is what to answer for this course:

---

Project Structure Walkthrough

After create-next-app completes, your project looks like this:

Open src/app/page.tsx. This is the most important file in the project:

This is a React Server Component. It runs on the server. It can be async. It can fetch data directly. It never runs in the browser.

That last sentence — it never runs in the browser — is the mental model shift that the entire App Router is built on. We will spend all of F-3 unpacking exactly what that means and why it changes how you structure applications.

Open src/app/layout.tsx:

This layout wraps every page in your application. The metadata export handles your <title> and <meta> tags automatically — no next/head, no manual <title> tags. The children prop is where each page gets inserted.

---

The Four npm Scripts

• npm run dev — starts the development server on http://localhost:3000 with hot module replacement. The --turbopack flag uses the new Rust bundler for significantly faster startup and rebuild times.
• npm run build — compiles your application for production. This is where Next.js decides which pages to statically generate and which to render dynamically. Read the build output carefully — it tells you exactly what each route will do in production.
• npm run start — starts a production server from the compiled output. Run build first.
• npm run lint — runs ESLint with Next.js-specific rules that catch common mistakes (missing alt tags on images, incorrect usage of <Link>, etc.).

---

Reading the Build Output

After running npm run build, Next.js prints a summary that looks like this:

Learn to read this output. It tells you — before you deploy a single byte — exactly which rendering strategy each route is using. A ƒ on a page that should be ○ means you accidentally made it dynamic somewhere. An ○ on a page that should be ƒ means you might be serving stale content. This output will become one of your most-used diagnostic tools.

---

What Next.js Is Not

Before we go further, it is worth setting three expectations clearly.

Next.js is not a backend framework. It can handle API routes and server-side logic, but it is not Express, Fastify, or NestJS. If you need a dedicated API layer with complex business logic, background job processing, or a sophisticated database access layer, Next.js route handlers are often not the right tool — or they coexist alongside a dedicated backend service.

Next.js is not opinionated about your database. It has no built-in ORM, no preferred database, and no migration system. You bring those yourself (Prisma, Drizzle, raw SQL — your choice). This is a feature, not a gap.

Next.js is not magic. The framework makes a lot of things automatic — routing, code splitting, image optimisation, font loading — but every one of those automations has mechanics you can understand and, when needed, override. This course is fundamentally about understanding those mechanics so you can work with them deliberately rather than accidentally.

---

Where We Go From Here

This module established the why of Next.js. The remaining Foundation modules build the mental model and practical skills you need to ship real applications.

The single most important thing to carry forward: Next.js is a spectrum, not a switch. Every feature — caching, rendering modes, data fetching strategies, edge compute — lives somewhere on a continuum between "runs once at build time, served forever" and "runs on every request, always fresh." Your job as a Next.js developer is not to learn which button to press for each scenario. It is to build the judgment to know where on that spectrum each piece of your application belongs.

That judgment is what the next 36 modules build.

---