<p>When a React, Angular or Vue app starts having SEO problems, someone inevitably suggests "just use SSR." Sometimes that's the right call. Sometimes it's months of refactoring for a problem you could solve in a day. Each strategy makes a different trade-off between build complexity, runtime cost, and content freshness.</p><h2>CSR — Client-Side Rendering</h2><p>In a standard React, Angular or Vue app, rendering happens entirely in the browser:</p><ol><li>Server returns a minimal HTML shell.</li><li>Browser downloads the JS bundle.</li><li>Framework executes, fetches data, paints the UI.</li></ol><p><strong>Good at:</strong> developer simplicity, rich interactivity, no server infrastructure beyond a static file host.</p><p><strong>Breaks down when:</strong> crawlers and bots that skip JavaScript receive the empty shell. This affects search indexing, OG previews, and any tool that parses your HTML. For exactly what crawlers see, read <a href="https://readypivs.com/blog/how-crawlers-see-your-react-app/">How a Search Crawler Actually Sees Your React App</a>.</p><h2>SSR — Server-Side Rendering</h2><p>Every HTTP request triggers a server-side render: the server runs your framework code, fetches data, produces a complete HTML document, and sends it to the client. React then hydrates the page — attaches event listeners to the already-visible DOM.</p><p><strong>Good at:</strong></p><ul><li>Crawlers, bots, and users all get the same fully rendered HTML.</li><li>Content is always fresh — no build step needed to reflect data changes.</li><li>Faster perceived FCP on content-heavy pages since HTML is ready before the JS bundle executes.</li></ul><p><strong>Gets complicated because:</strong></p><ul><li>You need a persistent Node.js (or equivalent) server. Deployment is no longer "upload a folder to S3."</li><li>Server costs scale with traffic — every request is CPU work.</li><li>Your code must be isomorphic. Libraries that use <code>window</code>, <code>document</code>, or browser APIs need guards; third-party components may not support SSR at all.</li><li>CDN caching is possible but cache invalidation becomes your problem.</li></ul><p><strong>Fits when:</strong> content changes per-request and per-user — authenticated dashboards, personalized feeds, real-time data.</p><h2>SSG — Static Site Generation</h2><p>HTML is generated once at build time. The framework fetches all data, outputs a directory of <code>.html</code> files, and you deploy those to a CDN.</p><p><strong>Good at:</strong></p><ul><li>Fastest possible response time — serving a pre-built file from a CDN edge is as fast as HTTP gets.</li><li>Zero per-request compute cost.</li><li>Simple, resilient infrastructure.</li></ul><p><strong>Gets complicated because:</strong></p><ul><li>Build times grow with content volume — thousands of pages can mean minutes per deploy.</li><li>Content is stale until the next rebuild; a CMS update doesn't appear until you trigger and ship a new build.</li><li>Highly dynamic content requires client-side fetching on top of the static shell, reintroducing the CSR problem.</li></ul><p><strong>Fits when:</strong> content is mostly static, updates on a predictable schedule, and no per-user server logic is needed.</p><h2>Prerendering</h2><p>Prerendering works differently from SSR and SSG. It doesn't change what your app serves to real users — they still get the SPA. It intercepts bot requests and serves a pre-generated HTML snapshot instead.</p><p>The snapshot is generated by running your page in a headless Chromium instance, so it reflects the fully-executed JavaScript output.</p><p><strong>Good at:</strong></p><ul><li>Fixes crawler and bot visibility without touching your app architecture.</li><li>No isomorphic code requirement.</li><li>Works across React, Vue, Angular, and non-framework JS setups.</li><li>Meta tag overrides (<code>title</code>, <code>description</code>, <code>keywords</code>) per URL or via regex — no code deploy.</li><li>Cache warming via sitemap eliminates the cold-start on first request.</li></ul><p><strong>Limits:</strong></p><ul><li>Doesn't improve runtime performance for real users — they still load and execute the JS bundle.</li><li>Snapshot freshness depends on cache TTL; very frequently updated pages need correct invalidation.</li></ul><p><strong>Fits when:</strong> you have an existing SPA with a crawlability or social preview problem and rewriting to SSR or SSG is a disproportionate investment.</p><h2>Side-by-side</h2><figure class="table"><table><thead><tr><th>&nbsp;</th><th>CSR</th><th>SSR</th><th>SSG</th><th>Prerendering</th></tr></thead><tbody><tr><td>Crawler-readable HTML</td><td style="text-align:center;">✗</td><td style="text-align:center;">✓</td><td style="text-align:center;">✓</td><td style="text-align:center;">✓ (bots only)</td></tr><tr><td>Always fresh content</td><td style="text-align:center;">✓</td><td style="text-align:center;">✓</td><td style="text-align:center;">✗ (rebuild needed)</td><td style="text-align:center;">✓ (within TTL)</td></tr><tr><td>Server runtime required</td><td style="text-align:center;">✗</td><td style="text-align:center;">✓</td><td style="text-align:center;">✗</td><td style="text-align:center;">external service</td></tr><tr><td>App code changes needed</td><td style="text-align:center;">✗</td><td style="text-align:center;">✓ (isomorphic)</td><td style="text-align:center;">✓ (build integration)</td><td style="text-align:center;">✗</td></tr><tr><td>Scales to large content sets</td><td style="text-align:center;">✓</td><td style="text-align:center;">✓</td><td style="text-align:center;">slow builds at scale</td><td style="text-align:center;">✓</td></tr><tr><td>User-personalized responses</td><td style="text-align:center;">✓</td><td style="text-align:center;">✓</td><td style="text-align:center;">✗</td><td style="text-align:center;">✗</td></tr></tbody></table></figure><h2>How to pick</h2><p>Match the strategy to your constraint:</p><ul><li>Crawlers don't see my content → Prerendering, if you already have a working SPA.</li><li>Building a new app, SEO from day one → SSR or SSG depending on content dynamism.</li><li>Content rarely changes, same for all users → SSG.</li><li>Content is personalized or real-time → SSR.</li><li>Change meta tags on hundreds of pages without a deploy → Prerendering + meta overrider.</li></ul><p>These strategies can coexist. A Next.js app can still use prerendering for URL patterns where the server render is too slow or where you need bulk meta overrides.</p>

SSR, SSG, CSR, prerendering — four rendering strategies with real trade-offs. Here's an honest breakdown of when each one fits and when it doesn't.

SSR vs SSG vs Prerendering: When it makes sense

<h2>The mismatch</h2><p>You open your React app in Chrome and see a fully rendered product page. A search crawler hits the same URL and gets back <code>&lt;div id="root"&gt;&lt;/div&gt;</code>. Same URL, completely different document.</p><h2>How a browser renders your SPA</h2><ol><li>The server returns a minimal HTML shell — a <code>&lt;div id="root"&gt;</code> and a <code>&lt;script&gt;</code> tag.</li><li>The browser downloads the JavaScript bundle.</li><li>React executes, fetches data if needed, and writes the final DOM.</li></ol><h2>What a crawler actually receives</h2><p>Most crawlers are not browsers. They make an HTTP request, read the response body, and move on — they do not execute JavaScript.</p><p>What they get: the raw shell. Your product names, descriptions, headings, and internal links are inside the JS bundle, unreachable.</p><p>Googlebot <i>can</i> execute JavaScript, but does so with a crawl delay and resource constraints that vary by site. Other crawlers — Bing, social bots for OG previews, RSS parsers, link unfurlers in Slack or iMessage — typically don't run JS at all. A broken OG preview in a chat is the most visible symptom.</p><h2>Where prerendering fits in</h2><p>Prerendering solves the problem at the server response level, before the crawler decides whether to run JS.</p><p>The flow with readypivs:</p><ol><li>A crawler hits your URL.</li><li>readypivs intercepts the request, identifies it as a bot, and serves a <strong>pre-generated HTML snapshot</strong> instead.</li><li>The crawler gets a complete document: real headings, real copy, real <code>&lt;meta&gt;</code> tags, all internal links.</li><li>Real users get your normal SPA — nothing changes for them.</li></ol><p>The snapshot is generated by running your JavaScript in a headless Chromium instance, so the output matches what Chrome would render. It is not a hand-crafted template.</p><h2>CSS cleanup</h2><p>Running a full Chromium render picks up all the inline styles and component-level CSS your app injected at runtime. readypivs removes the rules not applied to any element in the rendered output — making the snapshot lighter and faster to parse.</p><h2>Meta tag overrides</h2><p>SPAs typically set <code>&lt;title&gt;</code> and <code>&lt;meta name="description"&gt;</code> dynamically via something like <code>react-helmet</code>. A crawler seeing the shell gets whatever fallback values exist — often the <code>&lt;title&gt;My App&lt;/title&gt;</code> you never customized.</p><p>Prerendering already handles the basic case since the JS ran before the snapshot was taken. For bulk control — pages from a CMS with wrong meta values, or URL patterns you want to update in one shot — readypivs includes an HTML Overrider: set <code>title</code>, <code>description</code>, <code>keywords</code>, and other meta fields per URL or via a regex rule, no code deploy needed.</p><h2>Cache warming</h2><p>The first request to any URL triggers a Chromium render, which takes time. readypivs eliminates that cold start by reading your <code>sitemap.xml</code> and pre-crawling every listed URL upfront. You choose between a lightweight <code>fetch</code>-based pass or a full Chromium-based one. After warming, every request hits a ready snapshot.</p><h2>When prerendering is the right tool</h2><ul><li>Your existing SPA works and migrating to SSR or SSG would be a large refactor.</li><li>SEO and social sharing matter but you don't need per-user server rendering.</li><li>You want bot-specific optimization without touching your frontend architecture.</li></ul><p>It doesn't replace SSR for personalized server-rendered content, or SSG for fully static sites built at deploy time. But for most production SPAs, it's the shortest path to a crawler-readable site.</p><p>If you're new to the concept, the <a href="https://readypivs.com/blog/dynamic-prerender/">readypivs overview</a> covers the basics.</p>

How a Search Crawler Actually Sees Your React App

<p>Dynamic prerender is a service that allows you to improve SEO for web pages that use JavaScript to display content. If a web page uses JavaScript, search engines may have problems indexing and ranking the page because they cannot always process the content generated by JavaScript.</p><p>Dynamic renderer solves this problem by providing pre-rendering of web pages by the server. During the pre-rendering process, the server creates HTML code for the web page that includes the content generated by JavaScript. Thanks to this HTML code, search engines can read the information on the page and index it correctly, which has a positive effect on SEO.</p><p>Therefore, Dynamic Prerender is useful for websites that use JavaScript, because it improves SEO and allows search engines to index content correctly.</p>

BLOG

Latest updates and Hand-picked resources.

SSR vs SSG vs Prerendering: When it makes sense

How a Search Crawler Actually Sees Your React App

What is dynamic prerender