Every question in Next.js reduces to one: where does this code run, and when? A component runs on the server or in the browser. A page renders at build time or on every request. A value comes from a cache or the source. Get those three axes right and the framework is small; get them wrong and you meet its whole error surface — a hook that refuses to run, a secret in a bundle, a stale page. This guide takes them in order, naming the mistake at each. Everything below was executed against Next.js 16.2.12; caching changed shape in version 16, so versions are stamped.
Each chapter opens with the short version. Tap one to read the detail.
The folder tree is the router
~2 min
Creating a folder does not create a route — a segment goes live only when it holds a page file, which is why everything else in that folder is safe from the router. And a layout does not re-render when you navigate inside it, so work you put there runs once for the whole section.
Where the code runs: the 'use client' boundary
~2 min
Layouts and pages are Server Components by default. 'use client' does not mark one component as interactive — it marks where the browser bundle begins, and every module that file imports is pulled across with it. Props crossing the line must be serializable, and anything you pass is published.
Static and dynamic are a spectrum, not a switch
~2 min
Prerendering happens at build time or during revalidation and its result is cached; dynamic rendering happens per request. Next.js draws that line per component, not per route, so one page can serve a static shell instantly and stream the request-dependent parts behind Suspense.
Fetching on the server, and the waterfall you wrote by accident
~2 min
A Server Component can be async and await data directly — no client round trip, no loading state, credentials never leaving the server. The usual defect is sequencing: two awaits in one component run one after the other even when neither needs the other's result.
Caching: find out which model you are on first
~2 min
The stale page is rarely the cache you configured — it is a layer you did not know was on, and development never shows it. Version 16 added Cache Components (use cache) beside the older fetch-options model, so undated advice often describes the other one.
Mutations: a Server Action is a public endpoint
~2 min
'use server' does not hide a function: it replaces the body in the browser bundle with an identifier that posts back, so anyone able to send that request reaches it. Rendering a form only for signed-in users protects the form, not the action behind it.
Route Handlers and Proxy: the request layer
~2 min
route.ts exports one function per HTTP verb and works in Web Request and Response objects. proxy.ts — renamed from middleware in version 16 — runs before routing and belongs to rewrites, redirects and headers, not to deciding who is allowed to do something.
Navigation: what a link prefetches, and why a click still feels slow
~2 min
<Link> prefetches when it is hovered or enters the viewport, but how much arrives depends on the target: a static route is fetched whole, a dynamic one is skipped — unless it has a loading file, which makes its shell and skeleton prefetchable.
Errors: what a boundary catches, and what it never sees
~2 min
An error file is a client-side React error boundary for the segment below it. It catches what its children throw while rendering, and nothing else — a failure inside a click handler passes straight through and the interface carries on as though nothing happened.
The output layer: metadata, images and CSS
~2 min
metadata and generateMetadata are Server Component exports only. The image component wants each image's intrinsic width and height so the browser can reserve space before the bytes arrive — an aspect ratio, not a rendered size, which stays with CSS.
Build, environment, and what only breaks in production
~2 min
A NEXT_PUBLIC_ variable is inlined into the browser bundle at build time, so one artifact cannot carry different public values per environment. Server-side variables read during dynamic rendering really are read per request — a distinction that decides what one build can be promoted through.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.