Static Generation vs. Server Rendering: Picking the Right Default
Date Published
Static generation and server rendering get framed as a single choice, made once, at the start of a project. In practice the better question is per-route: does this page's content change per request, or does it change on a schedule you control? A marketing page and a personalized dashboard have almost nothing in common, and forcing them through the same rendering strategy is usually where the regret shows up six months in.
The industry-practice version of this isn't "prefer static" or "prefer server" — it's defaulting to static for anything that can tolerate being slightly stale, and reaching for server rendering only where request-specific data genuinely can't be avoided. Most pages, it turns out, can tolerate being slightly stale.
The mistake that's easy to make going the other direction — reaching for server rendering by default because it feels safer or more flexible — is that it quietly opts every page into paying a runtime cost that static generation would have avoided for free.