SSR vs CSR vs SSG vs ISR: Web Rendering Types Explained

What Web Rendering Types Actually Are

Short answer: The four main web rendering types are Server-Side Rendering (SSR), Client-Side Rendering (CSR), Static Site Generation (SSG), and Incremental Static Regeneration (ISR). For B2B marketing websites, SSG and ISR deliver the fastest load times and best search visibility. CSR creates indexing risks and speed penalties that hurt conversion. SSR suits personalized or authenticated experiences.

The way your marketing website is built — specifically, where and when its HTML is assembled before reaching a visitor's browser — shapes how fast it loads, whether Google can index it correctly, and whether a senior buyer on a slow hotel connection bounces before your value proposition finishes rendering. This is not a developer-only concern. It is a decision with direct consequences for pipeline.

Most marketing sites are built with the rendering approach that was easiest for the team that built them, not the one that serves the business best. That gap is worth closing.

The Four Rendering Types, Explained Without Jargon

Every web page a visitor sees is HTML — a text document the browser reads and paints into what looks like a designed interface. The four rendering types differ in one thing: who assembles that HTML document, and when.

Server-Side Rendering (SSR) assembles the HTML on a server the moment a visitor makes a request. The server builds the page fresh, sends it to the browser fully formed, and the browser paints it. The visitor sees a complete page almost immediately, even before any JavaScript runs. SSR is the original web model — how most websites worked before JavaScript frameworks took over.

Client-Side Rendering (CSR) sends the browser an almost-empty HTML shell, then sends a large JavaScript bundle. The browser downloads that bundle, executes it, and the JavaScript builds the page content inside the browser itself. The visitor sees a blank or loading screen first, then content appears. This approach became popular with single-page application frameworks like React and Angular because it makes complex interactive apps easier to build.

Static Site Generation (SSG) assembles all HTML pages ahead of time — during a build process that runs before anyone visits the site. The finished pages sit on a content delivery network (a globally distributed network of servers) and are served instantly to any visitor anywhere. No server computation happens at request time. A visitor in Singapore gets the same pre-built page as one in San Francisco, delivered from the nearest edge node.

Incremental Static Regeneration (ISR) is SSG with a refresh mechanism. Pre-built pages are served from the CDN, but the system can rebuild individual pages in the background on a schedule — every 60 minutes, for example — without triggering a full site rebuild. ISR is what makes SSG practical for sites where content changes regularly.

Why This Decision Shows Up in Your Business Metrics

This choice is not invisible. It shows up in places that matter to a VP of Marketing or a founder reviewing pipeline quality.

Page speed directly affects conversion. Google's research on mobile web performance found that as page load time increases from 1 second to 3 seconds, the probability of a visitor bouncing increases by 32%. That figure climbs steeply from there — a 5-second load time pushes bounce probability up by 90%. The Google Search Central documentation makes clear that page experience signals, including load speed, affect how pages rank. CSR sites routinely fail on speed because the browser must download, parse, and execute JavaScript before showing anything useful — even on a fast connection.

CSR creates a specific search indexing problem. Google's crawler is sophisticated, but it does not always execute JavaScript fully on first crawl. When a CSR site sends Googlebot an empty HTML shell, the crawler may see no meaningful content. Google has published guidance on this: JavaScript-dependent content may be indexed on a second pass, which can take days to weeks. For a B2B company investing in organic search, this delay means pages that exist for buyers are invisible to Google for extended periods. SSR and SSG send complete HTML from the first request, so crawlers see the full content immediately. Google's JavaScript SEO documentation details exactly how this two-pass crawling process works and where content gets lost.

The Stanford Web Credibility Project found that even small technical errors — broken links, slow loads, incomplete pages — hurt a site's perceived credibility disproportionately compared to what most teams expect. For a growth-stage company sending a Series C investor or an enterprise procurement contact to its website, a blank screen or a multi-second spinner is not a neutral experience. It signals something about operational quality.

Core Web Vitals are now a confirmed Google ranking factor. The three metrics Google measures — Largest Contentful Paint (how fast the main content loads), Interaction to Next Paint (how fast the page responds to clicks), and Cumulative Layout Shift (whether content jumps around as it loads) — are directly influenced by rendering approach. Google's own Core Web Vitals guidance shows that sites scoring in the "Good" range on LCP (under 2.5 seconds) see measurably better ranking outcomes than those in the "Needs Improvement" range. CSR sites routinely underperform on Largest Contentful Paint because content does not exist until JavaScript runs. SSG sites typically score well because content is pre-built and served from edge infrastructure.

The cost of a slow site compounds. Akamai's research found that a 100-millisecond delay in page load time can cut conversion rates by 7%. For a B2B site converting at even a modest rate, that is a measurable revenue gap created entirely by architecture.

The Rendering Decision Matrix for B2B Marketing Sites

Not every site has the same requirements. The right rendering approach depends on what the site needs to do.

Rendering Type	How HTML Is Built	Best For	Risk For B2B Marketing
SSG	Pre-built at deploy time	Marketing sites, docs, blogs	Low — best default choice
ISR	Pre-built, refreshed on schedule	Sites with frequent content updates	Low — SSG with flexibility
SSR	Built per request on a server	Personalized or authenticated pages	Medium — server latency varies
CSR	Built in the browser via JavaScript	Interactive apps, dashboards	High — search visibility and speed risks

For most B2B marketing websites — the public-facing site that drives awareness, explains the product, and converts visitors into pipeline — SSG or ISR is the correct default. The content on these sites does not change in real time. Pre-building it and serving it from a CDN is faster, cheaper to host, more resilient, and better for search indexing than any of the alternatives.

SSR makes sense when pages must be personalized per visitor at request time: showing different pricing by geography, serving authenticated account data, or rendering content that changes frequently based on server-side logic. Hybrid architectures handle this well — pre-build the marketing pages as static, handle the authenticated product as SSR.

CSR belongs in product interfaces, dashboards, and tools where complex interactivity matters and search indexing is not a concern. It should almost never be the approach for a marketing website, though this mistake is common because development teams default to their familiar React setup without thinking through the rendering implications.

Where Teams Go Wrong: The CSR Trap

The most common rendering mistake at growth-stage technology companies is building the marketing website as a single-page application — the same architecture used for the product itself — because the engineering team already works in React or Vue and maintaining one codebase is simpler.

The downstream consequences follow a predictable pattern. Organic search performance is poor because key pages either fail to index or index slowly. Speed scores underperform benchmarks even after image optimization. When a performance audit eventually runs, the recommendation is to migrate to a framework that supports SSG or SSR — a meaningful rebuild that would have been free if the decision had been made correctly at the start.

Nielsen Norman Group's research on usability ROI makes the broader point: fixing problems found early in the build process costs roughly 10 to 100 times less than fixing them post-launch. Rendering architecture is one of the earliest decisions made, and one of the most expensive to reverse.

The frameworks that now handle this well — Next.js, Nuxt, Astro, Remix — allow teams to choose rendering per page or per route. A Next.js site can serve the homepage and blog as pre-built static pages while serving a pricing page with SSR so that geo-targeted pricing is accurate. This per-route flexibility is the practical reason Next.js has become a dominant choice for marketing sites at technical companies. We covered the full case for this approach in our guide to Next.js for B2B websites.

What This Looks Like in Practice

When we partnered with Rezolve AI — a NASDAQ-listed commerce AI company managing four acquired product surfaces under one brand — the site architecture decisions were inseparable from the brand and UX decisions. A fragmented product story told on a slow, poorly indexed site compounds itself: buyers form a negative first impression from the technical experience before they process the messaging. You can read more about that work at /work/rezolve.

The same dynamic appears consistently across B2B technology companies at growth stage. The product team has shipped something impressive. The brand story has been sharpened. But the delivery mechanism — the marketing website — is built on an architecture that works against both, loading slowly, indexing partially, and creating a credibility gap before any content lands.

The fix is architectural, but it does not require rebuilding the product. It requires treating the marketing site as its own surface with its own performance requirements, then selecting the rendering approach that matches those requirements. For the vast majority of B2B marketing sites, that means SSG or ISR as the foundation, with SSR reserved for routes that genuinely need per-request computation.

The Baymard Institute's UX benchmark research consistently shows that performance and perceived reliability are trust signals — not just usability factors. For enterprise buyers evaluating a vendor, a fast, responsive site is one of the first signals they register, often before reading a single word of copy. Baymard's benchmarks across more than 500 e-commerce and B2B sites confirm that slow or visually unstable pages rank among the top reasons buyers abandon before converting.

Frequently Asked Questions

What is the difference between SSR and SSG?

SSR (Server-Side Rendering) builds the HTML for each page at the moment a visitor requests it — the server assembles the page fresh on every visit. SSG (Static Site Generation) pre-builds all pages during a deploy process and serves them from a CDN. SSG is faster and cheaper to host; SSR is necessary when pages must reflect real-time or personalized data.

Does web rendering type affect SEO?

Yes, directly. Search engines index the HTML content they receive from a page request. CSR (Client-Side Rendering) often delivers an empty or minimal HTML shell, because page content is built by JavaScript running in the browser — which crawlers may not fully execute. SSG and SSR deliver complete HTML immediately, making content reliably indexable. Google has confirmed that JavaScript-rendered content may be processed on a delayed second crawl pass, sometimes taking days to weeks.

Is CSR always bad for marketing websites?

CSR is a poor default for marketing websites because it creates search indexing risk and speed penalties that most marketing sites cannot absorb. It is appropriate for interactive product interfaces and dashboards where users are already authenticated and search visibility is not a concern. The problem is when teams apply CSR to the full marketing site because it matches the product's architecture.

What is ISR and when should a B2B site use it?

ISR (Incremental Static Regeneration) is a variant of SSG where pages are pre-built and served from a CDN, but can be regenerated in the background on a schedule without a full site rebuild. A B2B site publishing blog content daily, updating pricing pages weekly, or displaying frequently changing case study data benefits from ISR — it gets the speed and indexability of SSG without requiring a full deploy every time content changes.

Can a single website use multiple rendering types?

Yes, and it is common practice in modern frameworks like Next.js, Nuxt, and Remix. A well-structured B2B marketing site might use SSG for the homepage, product pages, and blog; ISR for the resources section where content updates regularly; and SSR for any personalized or geo-targeted routes. Per-route rendering flexibility is one of the primary reasons these frameworks have replaced earlier single-page application setups for marketing sites at technical companies.

The Rendering Decision Is a Business Decision

Web rendering type sounds like it belongs three levels below the VP of Product. In practice, it determines how fast your site loads for a senior buyer on a conference connection, whether your product pages appear in searches your buyers are running, and what impression your technical competence makes before a word of your pitch is read.

The right choice for most growth-stage B2B marketing sites is SSG or ISR — pre-built, CDN-served, immediately indexable, and fast by default. That decision is worth making explicitly rather than inheriting from whatever framework the team last shipped the product in.

If your marketing site is underperforming on speed, search visibility, or conversion despite strong positioning and good copy, the rendering architecture is a likely culprit. At RNO1, we evaluate these systems as part of how we design and build digital experiences for technology companies — the delivery layer is inseparable from the brand and UX layer.

Book a discovery call if you want to understand what is working against your site and what a well-architected rebuild would change.