Common Next.js performance pitfalls

Waterfalls

In a Server Component the fix is the same: start independent work before awaiting it. Better still, give each slow part its own component and Suspense boundary, so the page streams each part as it arrives instead of waiting for the slowest. When several components need the same data, wrap the loader in React's cache (one call per request) or use cache (shared across requests) rather than threading props through the tree.

Request data too high

1// Slow: the whole layout waits for the request, nothing below it is in the shell.2export default async function Layout({ children }: LayoutProps<"/shop">) {3  const theme = (await cookies()).get("theme")?.value4  return <div data-theme={theme}><Nav />{children}</div>5}

Move the cookie read into a small component wrapped in <Suspense>, or into a client component that reads it in the browser, and Nav and the pages return to the static shell. The same goes for params: pass the promise down and await it where it is used.

Too much on the client

A "use client" page imports its whole subtree into the bundle. Put the directive on interactive leaves, pass server content as children, and check for large libraries imported from client modules (date libraries, Markdown, charting). Props are serialised into the RSC Payload; sending big objects inflates every navigation and can leak fields.

Caches that don't cache

• Runtime use cache entries live in instance memory. On serverless they often miss; use use cache: remote for hot, expensive data.
• revalidatePath("/", "layout") after every mutation invalidates the whole site. Tag data narrowly and invalidate the tag.
• A seconds profile or revalidate: 0 is excluded from the shell and becomes a hole; make sure that is what you want.

Elsewhere

Keep Proxy fast and narrowly matched, because it runs before every matched request. Don't use Server Actions to read data; they run one at a time. Give the LCP image preload and correct sizes, and let next/font handle web fonts.