Skip to content
APAnil PandeySoftware Developer
All writing

Notes on picking a rendering strategy

Static, dynamic, or streamed? A practical way to decide, using the only question that actually matters.

performancenext.js

Most rendering debates dissolve once you ask one question:

How stale is this page allowed to be?

Everything else follows from the answer.

The decision, in three cases

  1. Stale is fine for hours. Render it statically. A CDN hit is the fastest thing you can serve and the cheapest thing you can run.
  2. Stale is fine for seconds. Render statically and revalidate. You keep the CDN hit and pay for freshness in the background instead of on the request path.
  3. Stale is never fine. Render per request — but stream it, so the shell arrives while the personalised part is still resolving.

Where people go wrong

The common mistake isn't picking the wrong option. It's making one slow, personalised widget dictate the strategy for an entire page. Push the dynamic part behind its own boundary and let the rest of the page go static:

export default function Page() {
  return (
    <>
      <StaticArticle />
      <Suspense fallback={<CommentsSkeleton />}>
        <Comments />
      </Suspense>
    </>
  );
}

The page becomes as fast as its static parts, and the slow part stops being everyone's problem.

Have an idea? Let's build it.

Tell me the problem you're trying to solve and I'll tell you honestly whether I'm the right person to build it.