Common mistakes
Most App Router problems are not caused by obscure APIs. They come from using a familiar pattern in the wrong boundary.
Mistake: making the whole page a Client Component
One interactive control does not mean the whole page needs 'use client'. Move the interaction down to the smallest sensible component and leave the rest on the server.
Mistake: fetching your own Route Handler from a Server Component
If both pieces run on your server, share the underlying function. Add HTTP when HTTP is part of the requirement, not as ceremony.
Mistake: assuming fetch is cached because an old tutorial said so
Caching defaults and APIs have changed across Next.js releases. Check the version and the Cache Components configuration before copying old examples.
Mistake: treating a layout redirect as authorisation
Redirecting unauthenticated users is useful UX. Protected operations still need permission checks at the server boundary that reads or writes the data.
Mistake: serialising independent data requests
If two reads do not depend on each other, start them together. Accidental waterfalls are one of the easiest ways to make a server-rendered route feel slow.
Mistake: confusing static rendering with browser cache TTL
A page can be statically generated and still ask the browser to revalidate its HTML. Rendering strategy and HTTP cache policy answer different questions.
Mistake: putting a secret in NEXT_PUBLIC_
Anything intentionally exposed to client code should be treated as public. Rename the variable only after deciding the value is safe for every visitor to see.
Mistake: adding Suspense boundaries everywhere
A boundary controls reveal order. Use it where a region can load independently without making the page harder to follow.
Can you explain “Common mistakes” without reaching for the API reference?
Describe the main trade-off, one failure mode, and the decision you would make in a real project.