What Is Website Rendering: CSR, SSR, and SSG Explained

Website rendering techniques directly influence how fast pages feel and how search engines see them. As traffic and product requirements grow, rendering choices start affecting how well web applications hold up.

Website rendering turns your code into the visual content users see and interact with in their browsers. It affects page load speed, responsiveness, and interactivity.

In brief:

• Website rendering determines how quickly users see and interact with your content, directly influencing engagement and retention.
• Different rendering methods (CSR, SSR, SSG, and hybrid approaches) offer trade-offs for performance and SEO, with different levels of user interactivity depending on your project goals.
• Your rendering strategy affects Core Web Vitals and search visibility.
• Modern frameworks and headless CMS platforms like Strapi help you choose rendering approaches that match your specific performance, content, and scalability needs.

Basics of Website Rendering

Website rendering is how browsers turn your HTML, CSS, and JavaScript into the interactive content that users see and engage with. That sequence is what MDN calls the critical rendering path: the steps a browser takes to turn HTML, CSS, and JavaScript into pixels on screen.

When a browser renders a web page, it moves through these steps:

1. HTML Parsing: The browser reads your HTML and constructs the Document Object Model (DOM).
2. CSS Processing: It parses your CSS into the CSS Object Model (CSSOM). This step is render blocking; the browser waits until it receives and processes all the CSS before rendering the page.
3. Render Tree Construction: The DOM and CSSOM combine to create a render tree representing what will be displayed. Nodes hidden with display: none are excluded.
4. Layout: The browser calculates the position and size of every element.
5. Paint: Apply colors, text, and images to each visual element.
6. Composite: Assemble layers into the final image that the user sees.

This sequence turns source code into a usable, visual interface in the browser.

JavaScript boosts rendering by supporting content updates and high interactivity. Whether you're manipulating the DOM directly or using a framework like React, JavaScript lets you update elements in real time without reloading the page.

Types of Website Rendering

The four primary rendering approaches are client-side rendering (CSR), server-side rendering (SSR), static site generation (SSG), and hybrid rendering.

Client-Side Rendering

With CSR, the browser handles rendering. Your server sends a minimal HTML shell and a JavaScript bundle. The JavaScript runs in the browser to build and display the UI. CSR is a common fit for single-page applications (SPAs), dashboards, and internal tools. SPAs remain the most-used rendering pattern among developers: 9,467 of 13,002 respondents in the 2025 State of JavaScript survey reported building them, ahead of SSR at 6,308.

In practice, the user requests a web page, the server returns a basic HTML page and JavaScript bundle, and the browser downloads, parses, and executes the JavaScript to render the content. That model supports highly interactive, app-like interfaces, reduces server workload by offloading rendering to the browser, and supports fast in-app navigation without full page reloads.

CSR has trade-offs. Due to slower initial load, users may see a blank or loading screen while JavaScript loads. SEO takes extra care; Google renders JavaScript but queues it, per JavaScript SEO basics, and crawler JavaScript limits remain common. If JavaScript fails, content may not render at all.

CSR still fits interactive experiences well, especially when the most important content does not depend entirely on client-side JavaScript.

Server-Side Rendering

Server-side rendering renders your HTML on the server for each request. The server sends fully rendered pages to the browser, which makes the content immediately visible. SSR works well for content-rich and SEO-critical pages, such as e-commerce platforms. For a deeper look at how SSR compares to other approaches, the SSR vs CSR guide covers the trade-offs.

In an SSR flow, the user requests a web page, the server generates and returns fully rendered HTML, and the browser displays the page while JavaScript hydrates it to add interactivity. Rendering on the Web describes SSR as a strong default for website rendering because the browser receives full HTML right away, search engines can crawl content immediately, and users get a more consistent experience across different devices.

SSR also creates higher server load per request, can lead to slower page transitions if not paired with client-side navigation, and can add complexity, especially for interactive apps.

SSR is often a good starting point when content visibility and first paint matter more than minimizing server work.

Static Site Generation

SSG builds your site's pages at build time before users request them. You serve pre-rendered HTML files via a content delivery network (CDN), which keeps delivery fast. SSG is well-suited for marketing sites, blogs, documentation, and pages that change rarely. For understanding when static vs dynamic sites make sense, that comparison covers the decision points.

With SSG, a static site generator pulls content and builds HTML files at deployment, then users receive static files from a nearby CDN edge. SSG advantages for website rendering include fast performance with no render time on request, high scalability suitable for CDN distribution, and fully pre-rendered HTML that supports strong SEO.

In contrast, SSG is not ideal for frequently changing content, since updates require a rebuild and redeploy. Real-time personalization and frequently changing features also require additional workarounds.

SSG works best when content changes predictably and delivery speed matters most.

Hybrid Rendering Approaches

Hybrid rendering combines SSR, CSR, and SSG to serve different content with different strategies depending on need. Frameworks like Next.js let you define rendering behavior per page. Hybrid rendering fits large web apps with varied content needs, and it is gaining ground: hybrid architectures now power over 12% of the most popular 10,000 websites, up 67% in 2024, according to the HTTP Archive Almanac.

In a hybrid setup, SSG usually fits stable, high-traffic pages, SSR usually fits up-to-date content like product listings or search results, and CSR usually fits highly interactive components. Teams often combine them using techniques like Incremental Static Regeneration (ISR) to update pages at runtime selectively.

With hybrid rendering, you can improve performance and SEO where it matters most, choose the right rendering model per route or feature, and scale modern apps with both static and changing content. More moving parts can make debugging and managing mixed rendering modes harder.

Hybrid rendering usually pays off when one rendering model would force too many compromises across the application.

Impact of Website Rendering on Performance and SEO

Website rendering directly shapes how users experience your site. Different rendering approaches can significantly influence key performance metrics. Google measures that experience through three Core Web Vitals, all evaluated at the 75th percentile of page loads per web.dev's Core Web Vitals thresholds:

• Largest Contentful Paint (LCP): 2.5 seconds or less
• Interaction to Next Paint (INP): 200 milliseconds or less
• Cumulative Layout Shift (CLS): 0.1 or less

These thresholds give you a practical baseline for comparing rendering choices.

INP replaced First Input Delay as a Core Web Vital on March 12, 2024.

Web performance involves actual performance and perceived performance. Actual performance is measured through load times, Time to First Byte (TTFB), Core Web Vitals, and resource usage. Perceived performance is how fast the website feels to users, regardless of actual load time.

Even if your page loads quickly, a poorly handled rendering strategy can still make it feel slow, and slow-feeling pages carry a measurable business cost. Ray-Ban cut mobile LCP by 43.28% (4.69s to 2.66s) and saw conversion rates climb 101.47% on mobile and 156.16% on desktop, per a web.dev case study. Choosing a rendering method lets you control both real and perceived speed. Only 48% of mobile sites and 56% of desktop sites passed all Core Web Vitals in the most recent Web Almanac crawl, according to the Almanac performance chapter.

Server-Side Rendering Performance

SSR can put meaningful content on screen quickly because the browser receives rendered HTML instead of waiting for a full client-side build. It can also reduce rendering pressure on low-powered client devices. On content-heavy or SEO-critical pages, those qualities often improve FCP and LCP, provided client-side JavaScript stays lean.

These gains are strongest when hydration work stays under control.

One caveat: full rehydration can hurt Total Blocking Time (TBT) and INP even when it improves FCP, so keep client-side JavaScript lean. web.dev warns that SSR with full rehydration "can have a significant negative impact on TBT and INP, even if it improves FCP," per Rendering on the Web.

Client-Side Rendering Performance

CSR sends the browser a bare HTML shell and relies on JavaScript to build the page. FCP arrives later when nothing meaningful renders until the bundle downloads, parses, and executes. Interactivity also depends on bundle size, so heavy client JavaScript pushes out INP.

CSR performance depends heavily on keeping the initial JavaScript bundle small.

Static Site Generation Performance

SSG starts from a fast baseline because no server-side computation is needed during page load. INP can stay strong as long as you limit client-side JavaScript, and performance stays more consistent across page loads and devices.

SSG gives you a strong performance baseline, but client-side scripts can still erode that advantage.

Search Engine Indexing

Your rendering strategy also shapes how search engines index and rank your content. Each rendering method affects how quickly and effectively search engines can crawl and interpret your site.

Google processes JavaScript web apps in three phases: crawling, rendering, and indexing, per Google Search Central. Googlebot fetches only the first 2 MB of any URL, and its rendering service runs statelessly by clearing storage between page loads.

With client-side rendering, Google renders JavaScript reliably now, and rendering usually takes a few seconds, though it can take longer. Still, other bots often can't run JavaScript at all, and depending on JavaScript for informational sites adds fragility and slows things down.

Server-side rendering provides fully rendered HTML on the initial request, so search engines see your content immediately. Google Search Central's current guidance: "Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript," per Google's JavaScript SEO basics.

Static site generation delivers pre-rendered HTML files that load instantly and are indexed reliably. When paired with fast load times, SSG offers an SEO-friendly rendering approach.

Pre-rendered content reduces crawler uncertainty, especially for pages that need to rank reliably.

SEO Tips for Better Indexing

For better visibility and faster, more accurate indexing, CSR sites should consider server-rendering the most important, high-traffic pages so bots can access meaningful content. Rendering different output for bots is worth avoiding: Google's documentation now calls it a deprecated workaround and recommends server-side rendering, static rendering, or client-side rendering with hydration instead.

SSR and SSG can make the most of their SEO advantage with metadata, Open Graph tags, and structured data. These are available in your pre-rendered output. For a developer-focused SEO checklist, that guide covers the fundamentals.

For hybrid approaches, SSG usually fits static content and marketing pages, while CSR is better reserved for authenticated or interactive areas where SEO is not as critical.

Make important content available before crawler-side JavaScript becomes a dependency.

Rendering Engines, Technologies, and Improvement

Rendering engines control how browsers turn code into visual interfaces. Whether you're working in Chrome, Firefox, Safari, or Edge, the rendering engine dictates how your app is interpreted and displayed.

Browser Rendering Engines

Browser rendering engines may interpret the same code differently. Blink is used by Chrome and Edge. Gecko is used by Firefox. WebKit is used by Safari, and by Chrome and other browsers on iOS and iPadOS, because of the iOS WebKit requirement.

Testing across engines still matters because similar pipelines do not guarantee identical behavior.

Rendering in JavaScript Frameworks

In the React 19 release, Server Components and Server Functions became stable. Frameworks like Next.js build SSR, SSG, and streaming on top of it, so you can pick a rendering mode per route or page.

Vue 3.5 added lazy hydration for async components. You can extend it with Nuxt to support SSR, SSG, and hybrid rendering for SEO-critical or high-performance pages. Angular uses the @angular/ssr package, which replaced the deprecated Angular Universal packages and is current in recent Angular releases, to support SSR and configure per-route render modes: RenderMode.Server, RenderMode.Client, or RenderMode.Prerender.

Framework-level choices let teams choose rendering behavior route by route.

Emerging Rendering Technologies

To meet rising performance expectations, several new rendering techniques are gaining traction:

• Incremental Static Regeneration (ISR): Static pages can update on demand without a complete site rebuild. Revalidation can be time-based or on demand.
• Partial Hydration / Island Architecture: Reduces the JavaScript payload by making only parts of a page interactive, not the entire page. Astro popularized this pattern.
• Edge Rendering: The edge rendering guide moves rendering to edge servers closer to the user, which reduces global latency. Host support varies: Vercel now provides Edge runtime guidance that recommends the Node.js runtime over its deprecated Edge Functions runtime, so check what your host supports.
• WebAssembly: Runs compiled code in the browser for high-performance tasks. The Wasm 3.0 specification is now a W3C Candidate Recommendation Draft maintained as a living standard.

These techniques are useful when the standard CSR, SSR, and SSG trade-offs become too blunt for your application.

The JavaScript frameworks review compares popular JavaScript frameworks and their features.

Best Practices for Improving Website Rendering

These techniques improve rendering performance regardless of which strategy you use:

1. Code splitting and lazy loading help keep startup work smaller. Splitting JavaScript into smaller chunks and downloading only what a page needs at startup directly improves INP. The import() mechanism is recommended. It's safer not to lazy-load your LCP image, though; fetch priority guidance explains how fetchpriority="high" helps the browser fetch it immediately.
2. A smaller JavaScript payload means less parsing and execution work. You can reduce that work by removing unused code, turning on minification, and compressing your JavaScript bundles.
3. Images and media assets benefit from compression, modern formats, and responsive techniques to serve the right size for each device. Next.js's own guidance still recommends WebP for most use cases, noting through AVIF encoding guidance that AVIF compresses about 20% smaller but takes roughly 50% longer to encode.
4. Simpler CSS selectors and shallower rules reduce layout recalculations. Cut render-blocking CSS too: the browser will not paint until it has processed every stylesheet it receives, so inline what the first screen needs and defer the rest.

These improvements keep the browser's startup work smaller, which helps every rendering model.

Server-Side Rendering Improvement

SSR can improve performance and SEO, but only if implemented efficiently. Caching server-rendered pages or data avoids regenerating content for every request, while faster server responses usually depend on tuned server configurations, database queries, and API calls. Critical interactive elements should hydrate first. Streaming SSR in Next.js sends the static shell immediately while deferred content streams in, and Angular's incremental hydration uses @defer blocks with triggers like hydrate on viewport to make pages interactive sooner.

SSR improvement is mostly about reducing repeated server work and delaying noncritical client work.

For Next.js-specific guidance, the performance optimization guide covers best practices.

Client-Side Rendering Improvement

CSR apps depend on JavaScript to render content, so improving perceived performance is key:

• import() calls and route-based chunking help load only the JavaScript needed for the current view.
• Placeholder elements or spinners can keep users oriented while content loads.
• Critical content is safer when pre-rendered or server-rendered, since not all bots can run JavaScript.
• Core functionality should degrade gracefully when JavaScript fails to load.

The less JavaScript users need before seeing useful content, the more resilient CSR becomes.

Static Site Generation Improvement

SSG sites are fast by default, but you can still push them further. Regenerating only updated content during deploys with techniques like ISR in Next.js keeps rebuild work smaller. Global CDNs can serve static assets from the nearest edge location; for fingerprinted assets, Cache-Control: max-age=31536000,immutable follows cache header guidance. Compression and minification for HTML, CSS, JS, and image files help reduce delivery time and latency.

SSG improvement keeps build, cache, and delivery behavior predictable as the site grows.

Security Considerations in Web Rendering

Each rendering approach introduces different security challenges. Cross-site scripting (XSS) remains a major concern, so this is worth taking seriously across environments.

Server-Side Rendering Security

With SSR, you process and deliver changing or user-specific content on the server, which opens the door to a few potential risks. Unsanitized input can expose your site to XSS or SQL injection, and backend fetches based on user input can open a server-side request forgery (SSRF) path to internal systems or cloud metadata endpoints. APIs used for rendering may also inadvertently leak data if not protected.

Sanitize all input and use context-appropriate output encoding. URL validation should use an allowlist. OWASP is explicit here: "Do not mitigate SSRF via the use of a deny list or regular expression," per its SSRF guidance. Server-side endpoints should use authentication and authorization, with HTTPS on every request.

Treat server rendering as a sensitive backend path.

Client-Side Rendering Security

CSR shifts logic to the client, increasing reliance on secure front-end practices. XSS is the major concern: if the content isn't properly sanitized, injected scripts can execute in your users' browsers. Public API access also requires secure authentication and rate limiting, and weak or missing content security policies (CSPs) can allow malicious scripts to run unchecked. Avoid unsafe sinks like innerHTML and document.write; when you must render raw HTML, OWASP recommends DOMPurify sanitization.

Send strong CSP headers on all responses, though OWASP's CSP cheat sheet notes CSP "should not be relied upon as the only defensive mechanism against XSS." Token-based auth (e.g., JWT) with HTTPS can secure API communication, and tokens should never be stored in localStorage or sessionStorage.

CSR security depends on reducing unsafe browser-side execution paths and protecting exposed APIs.

Hybrid Rendering Security

Hybrid approaches combine the risks of SSR and CSR and add complexity on top. Multiple rendering modes increase potential vulnerability entry points. State management can also leak data; the official Vue SSR guide calls this cross-request state pollution: shared singleton state mutated for one user "can be accidentally leaked to a request from another user." Create fresh app, router, and store instances per request. Shared caches add another risk, since unchecked headers or shared caches can serve malicious or stale content.

Input and output sanitization should be consistent across server and client. User-supplied input should not go into headers without stripping CR/LF characters. Protect personalized responses with Cache-Control: private and sensitive data with no-store, and invalidate caches on updates.

Hybrid security works best when teams apply the same validation, encoding, and caching rules across every rendering path.

How Strapi Helps with Website Rendering

As a headless CMS, Strapi 5 gives you an API backend for client-side rendering, server-side rendering, static site generation, or a hybrid of all three. Strapi 5 brings a flattened REST response format (attributes sit directly on the data object) and a documentId-based Document Service API, which keeps front-end data handling simpler across rendering methods. For the full list of Strapi 5 changes, that overview covers what's new for developers.

Strapi's content API works with any front-end rendering method:

• Server-side rendering: Strapi provides content via REST or GraphQL to SSR frameworks like Next.js or Nuxt, so those frameworks can fetch current content before returning HTML.
• Static site generation: With Strapi's structured content APIs, static site generators can build pre-rendered pages at build time. Strapi's webhooks fire on events like entry.publish and media.update, so you can trigger rebuilds when content changes and keep static sites current. For how webhooks work in Strapi, that guide covers the implementation.
• Client-side rendering: For SPAs built with React, Vue.js, or Angular, Strapi delivers content via API for client-side rendering of changing content and interactive experiences. The Remix integration guide covers server-side rendering and data handling with another React framework.
• Hybrid rendering: Strapi's architecture supports mixed rendering approaches, so you can choose different techniques for different parts of your application. For deployment, Render integration covers automated SSL/TLS, built-in PostgreSQL, zero-downtime deployment, and simplified configuration.

That flexibility lets the content layer support your rendering strategy instead of forcing one.

Strapi Cloud provides managed hosting for Strapi projects. For teams that do not want to manage CMS hosting themselves, plans include a global CDN, DDoS protection, push-to-deploy from GitHub, custom domains, and GDPR and SOC 2 compliance. For more on the hosting decision, the self-hosted vs Cloud comparison covers the trade-offs.

Bringing It All Together

Website rendering affects user experience, indexing, and front-end scaling. It directly affects how users experience your site, how search engines index your content, and how your front-end scales.

The four major approaches to rendering are client-side rendering for interactive, app-like behavior, server-side rendering for SEO and fast first-paint performance, static site generation for fast delivery and scalability, and hybrid rendering for flexibility across your app's needs.

Choose based on your project's requirements:

• Need fast SEO-driven pages? SSR may be the right fit.
• Building an SPA or dashboard? CSR may be the right fit.
• Want fast delivery with low infrastructure cost? SSG may be the right fit.
• Serving both static and frequently updated content? Hybrid rendering can balance both worlds.

Match the rendering model to your content freshness, interactivity, SEO, and operational constraints.

Use Strapi 5 as the API backend while you choose rendering per page based on content freshness, interactivity, SEO, and operational constraints.