Static vs dynamic rendering is the choice of when and where your page’s HTML is built. Static site generation (SSG) builds pages once at deploy time and serves pre-made files from a CDN; server-side rendering (SSR) builds each page fresh per request; hybrid rendering mixes both per route in one site. For B2B marketing sites the default should be static, and you earn your way out of it route by route only when a page genuinely needs per-request logic.
Your marketing site is slow, your developers blame the CMS, and your pipeline review keeps surfacing the same complaint: pages feel sluggish on mobile. Before anyone reaches for a new platform, the real decision is usually about rendering. The static vs dynamic rendering question determines how fast your pages load, how fresh your content stays, and how much infrastructure you have to babysit. Get it right and most of your performance and maintenance headaches disappear quietly. Get it wrong and you pay for it on every campaign.
This is not a purely technical call. The rendering strategy you choose shapes how fast marketing can ship, how reliably personalization works, and what your hosting bill looks like at scale. Here is how to think about it like an operator, not a framework enthusiast.
What do static and dynamic rendering actually mean?
Every page your visitor sees is HTML. The only question is when that HTML gets built and where. That timing is the whole game.
- Static Site Generation (SSG): Pages are built once, at deploy time, into plain HTML files. A request just hands back a pre-made file from a CDN. Nothing runs per visitor.
- Server-Side Rendering (SSR): Pages are built fresh on the server for each request. The server runs code, fetches data, and assembles HTML on the fly before responding.
- Hybrid rendering: Different routes use different strategies in the same site. Your blog is static, your pricing calculator is server-rendered, your account dashboard is rendered in the browser. You pick per page, not per project.
There are nuances inside each bucket: incremental static regeneration (ISR) that rebuilds individual static pages on a schedule, edge rendering that runs SSR closer to the user, and client-side hydration that adds interactivity after the HTML arrives. But the three categories above cover the decisions that matter for a marketing site.
The default for marketing content should be static. You earn your way out of static, route by route, only when a page genuinely needs per-request logic.
The Case for Static by Default
For most B2B marketing pages, static rendering is the right answer and the cheapest one. Your homepage, services pages, case studies, and blog posts do not change between one visitor and the next. Building them once and serving them from a CDN gives you the fastest possible response, because there is no server work happening at request time.
The benefits compound:
- Speed. A pre-built file served from an edge node is about as fast as the web gets. This directly helps your Largest Contentful Paint and the rest of your Core Web Vitals, which Google uses as a ranking input and which correlate with bounce on paid traffic.
- Reliability. Static files do not crash under load. A surge from a launch or a press hit serves the same way as a quiet Tuesday. There is no origin server to fall over.
- Security. No server-side code running per request means a dramatically smaller attack surface. There is no database connection to exploit on a marketing page.
- Cost. Serving files from a CDN is inexpensive and predictable. You are not paying for compute on every pageview.
In our engagements, the majority of marketing pages can and should be static. The teams that struggle are usually the ones that adopted a server-rendered framework for a site that is, functionally, a brochure with a contact form.
When Static Starts to Hurt
Static has one real cost: content freshness depends on rebuilds. If your content team publishes constantly and a full rebuild takes several minutes, that lag becomes annoying. This is what incremental static regeneration solves. Pages rebuild individually in the background, so a 2,000-page resource library does not force a full-site rebuild every time someone fixes a typo. If your team publishes daily, ISR or on-demand revalidation is the feature to look for in your framework.
When You Actually Need Dynamic Rendering
Dynamic rendering earns its place when the HTML genuinely must differ per request. The honest test: would two different visitors, at the same moment, need to see different content on this exact page? If yes, you likely need SSR or client-side rendering. If no, it should be static.
Real cases where dynamic rendering is justified:
- Authenticated experiences. Customer portals, account settings, and gated dashboards show user-specific data that cannot be pre-built.
- Real-time data. Inventory counts, live pricing, seat availability, or anything that would be wrong if it were even a few minutes stale.
- Server-side personalization. Showing different content based on account, geography, or campaign source, computed on the server before the page renders.
- Search and filtering at scale. A resource hub with thousands of items and faceted search is often better served by querying on request than by pre-building every filter combination.
Notice that none of these are typical for the top of your funnel. Your highest-traffic, highest-stakes acquisition pages rarely need per-request logic. The dynamic needs cluster downstream, in the product and the logged-in experience.
The Hidden Cost of Defaulting to Dynamic
Teams reach for SSR because it feels flexible. The flexibility is real, but so is the bill. Every server-rendered request runs code, which means compute cost, cold-start latency, and a server that has to stay healthy. You also reintroduce the failure modes static rendering avoids: traffic spikes can overwheln an origin, a slow database query drags down every visitor, and a deploy bug can take the whole site offline. If a page does not need dynamic behavior, paying these costs buys you nothing.
Static vs dynamic rendering: which should you choose?
For most B2B marketing pages the answer is static, with dynamic rendering reserved for the routes that genuinely need per-request logic and hybrid as the practical default across a whole site. The table below contrasts the three approaches across the dimensions this article covers.
| Dimension | Static (SSG) | Dynamic (SSR) | Hybrid |
|---|---|---|---|
| Page speed / TTFB | Fastest; pre-built file served from a CDN edge, no per-request work | Slower; server runs code and fetches data on each request | Fast by default (static), slower only on dynamic routes |
| Content freshness | Updates on rebuild; ISR refreshes individual pages in the background | Fresh on every request; suits real-time data | Fresh where it matters, rebuilt where it does not |
| Infrastructure cost | Low and predictable; no per-pageview compute | Higher; compute, cold starts, and an origin to keep healthy | Pay for compute only on the dynamic routes |
| Scalability | Static files do not crash under load; traffic spikes serve the same | Traffic spikes can overwhelm the origin or a slow query | Scales like static for marketing, isolates dynamic load |
| Best-fit use case | Homepage, services, case studies, docs, blog posts | Authenticated portals, real-time data, server-side personalization | A full B2B site: static marketing plus a few dynamic routes |
A Decision Framework You Can Run in a Meeting
You do not need to render the entire site one way. Walk your page types through this sequence and assign each one a strategy.
- Does the page require login? If yes, it is dynamic (SSR or client-rendered behind auth). Stop here.
- Does the content differ per visitor at the same moment? If yes, lean dynamic or use edge personalization. If no, continue.
- Does the content need to be fresh within seconds? If yes, SSR or ISR with short revalidation. If minutes-to-hours is fine, static with ISR.
- Does it change rarely (marketing pages, docs, posts)? Static, full stop.
- Is there heavy per-request interactivity but stable initial content? Static HTML plus client-side hydration for the interactive parts. Ship a fast first paint, then enhance.
Run every page type through these questions and you will usually land on a hybrid architecture: static for the bulk of marketing, SSR for a handful of dynamic routes, client rendering for the app. That is the normal, healthy outcome. The mistake is forcing one strategy across all of it.
Hybrid Rendering Is the Practical Answer
Modern frameworks let you mix strategies in a single codebase, which is why the “static vs dynamic rendering” debate is mostly a false binary for real sites. You set the default to static and opt specific routes into server rendering where the framework lets you flag it per page.
A typical B2B marketing site we build looks like this:
- Homepage, services, about, case studies, blog: static, served from the CDN.
- Resource library with faceted search: static shell with client-side filtering, or SSR if the catalog is large.
- Pricing page with a regional or account-based variant: edge SSR for the variant logic only.
- Contact and demo forms: static page, with submission handled by an API endpoint or serverless function.
- Customer portal: SSR or client-rendered behind authentication, often a separate app entirely.
This is the same thinking behind the B2B website architecture that converts and why we tend to reach for tools that make static the default while keeping dynamic routes available when needed. If you want the reasoning behind our framework choice specifically, we wrote it up in why we build B2B sites on Astro.
The key principle: choose rendering per route, based on what that route actually does, not based on a sitewide preference or what the framework happens to do by default.
Getting the Decision Right
The rendering strategy is one of the few early architecture choices that quietly governs performance, cost, and how fast your team can ship for years. Reverse it later and you are usually rebuilding, not tweaking. So spend the hour up front: list your page types, run them through the framework above, and write down the strategy for each. Most of your site should land on static. A few routes will earn their way into dynamic. That distribution is the sign of a well-architected marketing site.
If your current site feels slow, expensive to run, or painful to update, the rendering model is one of the first things worth auditing. We help B2B teams make these calls and build the infrastructure that follows from them across our web and performance work. If you want a second set of eyes on your architecture, tell us what you are working with and we will walk you through the trade-offs for your specific pages.
