Static Rendering. Doing the Work Before Anyone Asks For It - Pt 2

When I started using static rendering in WonderBook, it clicked that some pages don’t need to think, they just need to exist. Instant load speed was the bonus; permanence was the real win.

Static rendering works by doing the heavy lifting before a single user arrives. The HTML is generated during the build process, deployed to the CDN, and served instantly without touching a database or runtime.

That one decision removes time, cost and risk from every future request.

What static rendering actually does

Instead of rendering the page one user at a time, static rendering does it once at build time:

Build phase → Next.js generates HTML → CDN caches result → User requests page → CDN returns file instantly (no compute required)

No function, query and revalidation needed. The server isn't even in the path anymore.

When static rendering makes sense

✅ Use it when	❌ Avoid it when
Content rarely changes	Data must be personalised
SEO matters	Page is session-dependent
Instant load matters	Data changes frequently
There’s no user logic	Real-time data is essential

Static is a promise: “This page can stay as-is until I explicitly rebuild.” That promise is where most mistakes happen, the mistake is making things static that shouldn’t be.

Static rendering in WonderBook

Static rendering made immediate sense for pages like Privacy Policy, Terms and the About section. They contain fixed text, don’t depend on any user, and should load immediately with zero client-side work.

Before I converted them, they were incorrectly using "use client". That caused 500ms+ before meaningful content showed, plus unnecessary hydration.

After switching them to static server components rendered at build time, they consistently displayed in ~50ms. That was a 10x improvement, without touching design or layout.

Why static speed feels different

Static pages remove:

Cost	Where it disappeared from
TTFB latency	No server processing
JavaScript hydration	Page loads as plain HTML
Database load	No query per request
Cold server boot	Served from CDN edge
Rendering CPU time	Done once, not every time

This is why static rendering often feels instant, because from the browser’s perspective, it’s just reading a document that already exists.

What would have gone wrong if I misused it

Static rendering fails when content cannot be frozen. For example:

• A dashboard tied to a logged-in user
• A public page with constantly updating ranking data
• Anything with current session context
• Real-time AI outputs or notifications
• Pages that would need constant redeploys just to stay correct

Using static for these pages would have forced me to rebuild the entire app just to update content, or worse, served outdated or misleading data.

The mindset change it triggered

Static rendering introduced a new rule for me:

If a page doesn't need per-user logic or frequent updates, it shouldn't be recomputed per visitor.

That became my first rendering principle: Static-first, unless proven otherwise.

It forced me to justify dynamic rendering instead of defaulting to it.

Why static alone wasn’t enough

Some public-facing pages did change, but not constantly. For example, WonderBook’s Explore page needed to show public stories and total likes. I didn’t want users waiting on a live query every time, but I also couldn’t permanently freeze the page at build time.

That’s where static rendering hit its limits, and where I needed something more flexible, something that let me cache content but still refresh it without redeploying the whole app.

Which led me to ISR.