Choosing a Rendering Strategy: SSR, SSG, and Static Export
By Mykhailo Boichuk · Co-founder & Vice-President
In short
Server-side rendering, static site generation, and full static export trade freshness against cost and operational complexity. SSR renders per request and suits highly dynamic or personalized pages. SSG renders at build time and serves cached HTML, ideal for content that changes occasionally. Static export removes the server entirely for content that rarely changes. Most sites are best served by mixing strategies per route.
Three points on a spectrum
The three strategies differ in when HTML is produced. Server-side rendering produces it per request, so every visitor can see fresh, personalized content at the cost of running a server for each page view. Static site generation produces HTML at build time and serves the same cached file to everyone until the next build. Full static export takes this further, emitting plain files that any static host can serve with no application server at all.
Framing them as a spectrum from per-request to per-build to never clarifies the choice. The question for each route is how fresh the content must be and who is allowed to see what, weighed against how much server infrastructure you want to run.
Match the strategy to the content
Highly dynamic or personalized pages, such as a dashboard reflecting a specific user’s data, need per-request rendering or client-side data fetching because their content cannot be known at build time. Content that changes occasionally and looks the same for everyone, such as a marketing page or a blog post, is a natural fit for static generation. Content that almost never changes can be exported statically and served from a content delivery network.
- Use SSR for personalized or rapidly changing pages.
- Use SSG for shared content that updates on a known cadence.
- Use static export for stable content where no server logic is needed.
Cost, scale, and failure modes
Static files scale almost trivially and fail rarely because a content delivery network serves them with no application logic. Server rendering scales with traffic and introduces a process that can be slow or fail under load. The operational burden of SSR is real: caching, cold starts, and capacity planning all become your problem in a way they are not for static files.
Mix per route rather than choosing globally
The most common mistake is treating the decision as site-wide. Modern frameworks let each route pick its own strategy, so a marketing page can be statically generated while an account page is server-rendered and a documentation set is statically exported. The right architecture is usually a blend, chosen route by route according to the freshness and personalization each one actually requires.
Key takeaways
- Rendering strategies differ in when HTML is produced: per request, per build, or never.
- SSR suits personalized or rapidly changing pages but requires running a server.
- SSG fits shared content on a known update cadence and scales cheaply.
- Static export removes the server entirely for stable content.
- Choose per route rather than picking one strategy for the whole site.
Frequently asked questions
- When should I use server-side rendering?
- For pages whose content is personalized or changes rapidly and therefore cannot be known at build time, accepting the cost of running a server per request.
- What is the difference between static generation and static export?
- Static generation builds cached HTML that an app server still coordinates, while static export emits plain files any static host can serve with no application server.
- Do I have to pick one strategy for my whole site?
- No. Modern frameworks let each route choose its own strategy, and most sites are best served by mixing them according to each route’s needs.
References
About the author
Mykhailo Boichuk
Co-founder & Vice-President
Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.