Client-Side Rendering (CSR)

FigureThe CSR loading sequence. Note the delay before the user sees content (First Contentful Paint).

What is Client-Side Rendering?

Client-Side Rendering (CSR) is a web rendering approach where the browser (client) handles most of the work of building the page. The server sends a minimal HTML "shell" — often just a div container and script tags — and JavaScript running in the browser fetches data and constructs the actual page content.

This approach became popular with the rise of JavaScript frameworks like React, Vue, and Angular. These single-page application (SPA) frameworks typically use CSR by default.

In CSR, the rendering sequence is:

Browser requests the page
Server returns minimal HTML (often nearly empty)
Browser downloads the JavaScript bundle
Browser executes JavaScript
JavaScript makes API calls to fetch data
JavaScript builds and displays the page content

Users see nothing meaningful until step 6 completes.

How CSR Works Technically

The Empty Shell

A typical CSR HTML response looks like:

html

<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
</head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>

There is no actual content — just a container div and a script reference. All content is generated by JavaScript after the page loads.

The JavaScript Bundle

The JavaScript bundle contains:

Framework code (React, Vue, Angular)
Application logic and components
Routing logic
State management

Bundle sizes can range from 100KB to several megabytes, all of which must download and execute before content appears.

Data Fetching

After JavaScript initializes, it typically makes API calls to fetch the data needed for the page:

javascript

// Simplified example
fetch('/api/products')
  .then(response => response.json())
  .then(data => renderProducts(data))

This adds additional network round-trips before content is visible.

SEO Implications of CSR

1. The Empty Page Problem

When a search engine crawler requests a CSR page, it initially receives the empty shell HTML. The crawler must:

Recognize that JavaScript needs to execute
Actually render the JavaScript
Wait for API calls to complete
Parse the resulting DOM

Historically, most search engines could not execute JavaScript at all. They saw only the empty shell and indexed nothing.

2. Google's JavaScript Rendering

Google has significantly improved its ability to render JavaScript. However, there are important limitations:

Two-Wave Indexing:

Wave 1: Google crawls the HTML and sees the empty shell
Wave 2: Google renders JavaScript and sees actual content

Wave 2 may occur hours or days after Wave 1, creating indexing delays for new content.

Resource Limitations:

JavaScript rendering is expensive for Google
Not all JavaScript executes correctly
Timeouts may prevent complete rendering
Complex or buggy JavaScript may fail

3. Other Search Engines

Bing, Yandex, Baidu, and other search engines have varying JavaScript rendering capabilities. Many still struggle with CSR content. If international SEO matters to you, CSR creates significant risks.

4. Social Media Crawlers

Facebook, Twitter, LinkedIn, and other social platforms cannot render JavaScript when generating link previews. CSR pages shared on social media often display:

Blank previews
Missing images
Generic or missing titles and descriptions

This severely impacts social sharing effectiveness.

5. Performance and Core Web Vitals

CSR typically produces poor Core Web Vitals scores:

Largest Contentful Paint (LCP): Content cannot appear until JavaScript downloads, executes, fetches data, and renders. This inherently delays LCP.

First Contentful Paint (FCP): Users see a blank or loading screen while waiting for JavaScript.

Cumulative Layout Shift (CLS): Content popping in after JavaScript loads often causes layout shifts.

Time to Interactive (TTI): The main thread is blocked during JavaScript execution.

When CSR is Acceptable

CSR can work for:

Behind Authentication

Content that requires login (dashboards, user accounts, admin panels) does not need to be indexed. CSR works fine for authenticated experiences.

Non-SEO Applications

Internal tools, productivity apps, and applications where search visibility is irrelevant can use CSR without SEO concerns.

Progressive Enhancement Base

CSR can serve as the enhanced experience while server-rendered HTML provides the baseline for crawlers and users without JavaScript.

When to Avoid CSR

Public Content

Blog posts, product pages, landing pages, and any content that should appear in search results should not rely on CSR alone.

Marketing Sites

Sites focused on user acquisition need both SEO visibility and fast loading. CSR fails on both counts.

E-commerce

Product pages need to be indexed and load quickly. CSR creates friction for both search engines and impatient shoppers.

Alternatives to CSR

Server-Side Rendering (SSR)

The server renders complete HTML for each request. JavaScript then "hydrates" the page for interactivity. This provides immediate content for crawlers and users.

Static Site Generation (SSG)

Pages are pre-built at deploy time. Perfect for content that does not change per-request. Fastest possible delivery with complete SEO compatibility.

Incremental Static Regeneration (ISR)

Combines SSG with on-demand rebuilding. Pages are static but regenerate periodically or on-demand.

Hybrid Approaches

Modern frameworks like Next.js, Nuxt, and Remix allow mixing rendering strategies per page:

Marketing pages: SSG
Product pages: SSR with caching
User dashboard: CSR

CSR Best Practices

If you must use CSR, mitigate SEO risks:

Use Real HTML Links

Ensure navigation uses actual anchor tags with href attributes, not JavaScript event handlers:

Bad: Using onclick handlers like div onclick="navigate('/products')" creates content that search engines cannot follow.

Good: Using standard anchor elements with href attributes allows crawlers to discover and follow links naturally.

Implement Dynamic Rendering

Serve pre-rendered HTML to search engine bots while serving CSR to regular users. This adds complexity but bridges the gap.

Pre-render Critical Pages

Use tools like Prerender.io or build-time pre-rendering to generate static HTML snapshots for important pages.

Optimize Bundle Size

Smaller JavaScript bundles load and execute faster:

Code splitting
Tree shaking
Lazy loading non-critical components

Add Meta Tags Server-Side

Ensure Open Graph and meta tags are in the initial HTML, not injected by JavaScript, for social sharing compatibility.