AWS Builder Center

Builder Center

Server-Side Rendering vs Client-Side Rendering: Understanding Modern Web Applications

Learn how Server-Side Rendering (SSR) and Client-Side Rendering (CSR) work, how they differ in performance, SEO, security, and scalability, and when to choose each approach for a modern web application.

Server-Side Rendering vs Client-Side Rendering: Understanding Modern Web Applications

When building a modern web application, one of the important architectural decisions is where the HTML should be generated.
Should the server generate the HTML and send it to the browser?
Or should the browser download JavaScript and generate most of the page itself?
These approaches are commonly known as Server-Side Rendering (SSR) and Client-Side Rendering (CSR).
Understanding the difference helps developers make better decisions when choosing technologies such as React, Next.js, Angular, Vue, ASP.NET Core, and other modern web frameworks.

What Is Server-Side Rendering?

Server-Side Rendering (SSR) means that the server generates the HTML for a page before sending it to the user's browser.
A simplified request looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
Browser
|
| HTTP Request
v
Web Server
|
| Generate HTML
v
HTML Response
|
v
Browser
For example, a user requests:
1
https://example.com/products
The server might retrieve product information from a database, generate the HTML, and return something like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<html>
<body>
<h1>Products</h1>

<div>
<h2>Laptop</h2>
<p>$999</p>
</div>

<div>
<h2>Monitor</h2>
<p>$299</p>
</div>
</body>
</html>
The browser can immediately display the HTML.
JavaScript can then be loaded to provide additional interactivity.

What Is Client-Side Rendering?

Client-Side Rendering (CSR) moves much of the rendering work from the server to the browser.
Instead of sending a fully generated page, the server may initially send a basic HTML document and JavaScript files.
The browser then executes the JavaScript application and generates the user interface.
A simplified flow looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Browser
|
| Request
v
Web Server
|
| HTML + JavaScript
v
Browser
|
| Execute JavaScript
v
API Server
|
| JSON Data
v
Browser
|
| Render UI
v
Web Page
For example, a React application might initially receive:
1
2
<div id="root"></div>
<script src="/assets/app.js"></script>
The browser downloads app.js, executes it, requests data from an API, and then creates the user interface.

SSR vs CSR

The fundamental difference is where the initial HTML is generated.
FeatureServer-Side RenderingClient-Side Rendering
HTML generated byServerBrowser
Initial JavaScript dependencyLowerHigher
Initial page renderingUsually fasterCan be slower
SEOGenerally easierRequires additional consideration
Server workloadHigherLower for rendering
Browser workloadLowerHigher
API-driven applicationsPossibleVery common
Interactive applicationsPossibleVery common
ArchitectureServer-centricClient-centric

How SSR Works

Let's look at a simplified SSR application.
The user requests:
1
GET /products
The server performs several operations:
1
2
3
4
5
6
7
8
9
10
11
1. Receive request
↓
2. Authenticate user
↓
3. Query database
↓
4. Generate HTML
↓
5. Send HTML to browser
↓
6. Browser displays page
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Browser
|
| GET /products
v
Application Server
|
| SELECT * FROM products
v
Database
|
| Product data
v
Application Server
|
| Render HTML
v
Browser
This means the user can receive meaningful content before the browser has downloaded and executed the complete JavaScript application.

How CSR Works

With CSR, the initial request may look more like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Browser
|
| GET /products
v
Web Server
|
| HTML + JS
v
Browser
|
| Execute JavaScript
|
| GET /api/products
v
API Server
|
| Query database
v
Database
|
| JSON
v
API Server
|
| JSON response
v
Browser
|
| Render components
v
User sees products
The browser is responsible for much of the rendering process.
This is one of the reasons frameworks such as React became popular for building highly interactive applications.

The Performance Difference

One of the biggest differences between SSR and CSR is the initial page load experience.
Consider a CSR application.
The browser might need to:
1
2
3
4
5
6
7
8
9
10
11
12
13
Download HTML
↓
Download JavaScript
↓
Parse JavaScript
↓
Execute JavaScript
↓
Request API data
↓
Process data
↓
Render UI
Only after several of these steps does the user see the complete page.
With SSR:
1
2
3
4
5
6
7
8
9
Request page
↓
Server retrieves data
↓
Server generates HTML
↓
Browser receives HTML
↓
Page can be displayed
This can make SSR particularly useful for pages where displaying meaningful content quickly is important.
However, SSR is not automatically faster in every situation.
A poorly designed SSR application can be slow if the server performs expensive database queries or rendering operations for every request.
Similarly, a well-optimized CSR application can provide an excellent user experience.

SSR and SEO

Search engine optimization is another important consideration.
With traditional SSR, the server sends fully rendered HTML:
1
2
<h1>Hotel Reviews</h1>
<p>Read reviews from verified travelers.</p>
Search engines can generally process this content directly.
With a traditional CSR application, the initial HTML might contain very little content:
1
<div id="root"></div>
The actual content is generated after JavaScript executes.
Modern search engines are capable of processing JavaScript, but rendering JavaScript adds complexity and can affect how quickly content becomes available for indexing.
For websites where search traffic is important, SSR or other forms of pre-rendering can simplify the architecture.
Examples include:
  • E-commerce websites
  • News websites
  • Blogs
  • Documentation websites
  • Marketing websites
  • Public product pages

SSR and Security

SSR can also change how an application handles sensitive operations.
For example, the server can perform authorization before generating a page:
1
2
3
4
5
6
7
8
9
10
11
User
↓
Server
↓
Check authentication
↓
Check authorization
↓
Query protected data
↓
Generate response
Sensitive business logic can remain on the server.
However, CSR applications can also be secure.
A common mistake is assuming that because an application uses SSR it is automatically more secure.
Security depends on the entire architecture, including:
  • Authentication
  • Authorization
  • API security
  • Session management
  • Input validation
  • Database security
  • Secret management
  • Transport encryption
Client-side code should always be treated as untrusted because users can inspect and modify JavaScript running in their browser.

The Advantage of CSR: Rich Interactivity

CSR is particularly useful for highly interactive applications.
Consider a dashboard containing:
  • Charts
  • Filters
  • Drag-and-drop components
  • Real-time updates
  • Notifications
  • Complex forms
  • Interactive tables
After the initial application loads, the browser can update individual parts of the interface without requesting an entirely new HTML page.
For example:
1
2
3
4
5
6
7
8
9
User changes filter
↓
JavaScript handles event
↓
API request
↓
Receive JSON
↓
Update component
The entire page does not necessarily need to reload.
This can create a smooth application-like experience.

SSR Does Not Mean "No JavaScript"

This is an important misconception.
SSR and JavaScript are not mutually exclusive.
A modern SSR application can initially generate HTML on the server and then use JavaScript in the browser for interaction.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
Server
|
Generate HTML
|
v
Browser
|
Display HTML
|
Load JavaScript
|
v
Add interactivity
This process is often associated with hydration.

What Is Hydration?

Hydration is the process where client-side JavaScript attaches behavior to HTML that was already generated on the server.
For example, the server might generate:
1
<button>Buy Now</button>
The browser can display the button immediately.
After JavaScript loads, the application attaches an event handler:
1
2
3
4
5
6
7
<button>
↓
JavaScript loads
↓
Event handler attached
↓
Button becomes interactive
This allows an application to combine the initial rendering advantages of SSR with the interactivity of client-side applications.
Frameworks such as Next.js provide mechanisms for this type of architecture.

SSR vs CSR Architecture

A simplified SSR architecture might look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌──────────────┐
│ Browser │
└──────┬───────┘
│
▼
┌──────────────┐
│ Web / App │
│ Server │
└──────┬───────┘
│
▼
┌──────────────┐
│ Database │
└──────────────┘
A typical CSR architecture may look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌──────────────┐
│ Browser │
│ React / Vue │
└──────┬───────┘
│
│ API
▼
┌──────────────┐
│ API Server │
└──────┬───────┘
│
▼
┌──────────────┐
│ Database │
└──────────────┘
The CSR architecture often separates the frontend and backend more clearly.

When Should You Use SSR?

SSR can be useful when:
  • Initial page content needs to appear quickly.
  • SEO is important.
  • Pages contain content that search engines should discover.
  • The application has public-facing pages.
  • Server-side authentication and authorization are important.
  • You want to deliver meaningful HTML before the full JavaScript application loads.
Examples:
E-commerce
1
2
3
4
5
6
7
Product page
↓
Server renders product information
↓
Browser displays product
↓
JavaScript adds cart and interaction
News website
1
2
3
4
5
6
7
Article request
↓
Server retrieves article
↓
HTML generated
↓
Browser displays article

When Should You Use CSR?

CSR can be useful when:
  • The application is highly interactive.
  • SEO is not a major requirement.
  • The application behaves more like desktop software.
  • The frontend and backend are independently developed.
  • A large amount of UI state is maintained in the browser.
  • You are building an authenticated dashboard.
Examples include:
  • Admin dashboards
  • Project management systems
  • Internal business applications
  • Analytics dashboards
  • Collaboration tools
  • Web-based productivity applications
For example:
1
2
3
4
5
6
7
8
9
10
11
Login
↓
Dashboard
↓
Load user data
↓
Interact with charts
↓
Filter data
↓
Update components
A CSR architecture can work very well for this type of application.

You Can Also Combine SSR and CSR

Modern web frameworks increasingly blur the boundary between SSR and CSR.
Instead of choosing one approach for the entire application, developers can use different rendering strategies for different pages.
For example:
1
2
3
4
5
6
7
8
E-commerce Website

Home Page → SSR
Product Page → SSR
Search Page → SSR/Hybrid
User Dashboard → CSR
Admin Panel → CSR
Checkout → Hybrid
This is often called a hybrid rendering approach.
Different parts of the same application can therefore use different strategies depending on their requirements.

Next.js and Modern Rendering

Frameworks such as Next.js provide multiple rendering strategies.
Depending on the application and configuration, developers can use:
  • Server rendering
  • Static generation
  • Client-side rendering
  • Incremental/static regeneration approaches
  • Server components
  • Client components
This means you don't necessarily have to choose between "everything is SSR" and "everything is CSR."
Instead, rendering can be treated as an architectural decision made at the page or component level.

SSR vs CSR: A Practical Example

Imagine you are building a hotel review platform.
The public hotel page contains:
1
2
3
4
5
6
Hotel Name
Location
Rating
Reviews
Room information
Images
For this page, server-side rendering can be useful because:
1
2
3
4
5
6
7
Search Engine
↓
Hotel Page
↓
Server generates HTML
↓
Search engine receives content
Now imagine the hotel management dashboard:
1
2
3
4
5
Review statistics
Sentiment charts
Filters
AI-generated responses
Review moderation
This interface may benefit from client-side rendering:
1
2
3
4
5
6
7
8
9
Dashboard
↓
React application
↓
API requests
↓
Interactive charts
↓
Dynamic updates
The same application can therefore use both approaches.

SSR vs CSR: Key Trade-offs

There is no universally correct rendering strategy.
The decision depends on the requirements of the application.

SSR

Advantages
  • HTML is available earlier.
  • Can simplify SEO.
  • Useful for public content.
  • Server can handle data fetching and rendering.
  • Can provide a good first-load experience.
Considerations
  • Rendering creates server workload.
  • Server response time can affect initial rendering.
  • Caching needs careful design.
  • Architecture can be more complex when combined with client-side interactivity.

CSR

Advantages
  • Excellent for highly interactive applications.
  • Can reduce repeated full-page rendering.
  • Clear separation between frontend and API backend.
  • Client can manage complex UI state.
  • Works well for dashboards and internal applications.
Considerations
  • Larger JavaScript dependency.
  • Initial loading can involve more steps.
  • SEO may require additional rendering strategies.
  • More work is performed by the user's device.

A Simple Decision Guide

You can use this as a starting point:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Start
|
v
Is SEO important?
/ \
Yes No
| |
v v
SSR Is it highly
interactive?
/ \
Yes No
| |
v v
CSR SSR/CSR
depending
on requirements
But real applications are rarely this simple.
Other factors should also be considered:
  • Expected traffic
  • Server resources
  • Database performance
  • Caching strategy
  • SEO requirements
  • JavaScript bundle size
  • User device performance
  • Authentication requirements
  • Application complexity
  • Development team experience

Final Thoughts

Server-Side Rendering and Client-Side Rendering are not competing technologies that require every application to choose one permanently.
They represent two different approaches to generating and delivering a web application's user interface.
SSR generally moves more rendering work to the server and can be particularly useful for public, content-heavy and SEO-sensitive pages.
CSR moves more rendering work to the browser and can be particularly useful for highly interactive applications such as dashboards and web-based productivity tools.
Modern frameworks increasingly support hybrid approaches, allowing developers to choose the most appropriate rendering strategy for different parts of an application.
The most important question is therefore not:
"Is SSR better than CSR?"
Instead, ask:
"Where should rendering happen for this particular part of my application, and why?"
That question leads to a much better architectural decision.
# web-development
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article