← Back to Articles         
What is Server-Side Rendering (SSR)?

What is Server-Side Rendering (SSR)?

Published on 02 Oct 2026     9 min read Angular
SSR, CSR, SSG

What is Server-Side Rendering (SSR)?

1. What is Server-Side Rendering?

Server-Side Rendering (SSR) is a rendering technique where the server generates the initial HTML page and sends that rendered HTML to the browser.

In Angular SSR:

  1. Browser requests a page.
  2. Server runs the Angular application.
  3. Angular generates the initial HTML on the server.
  4. Server sends the rendered HTML to the browser.
  5. User can see the initial page content quickly.
  6. Angular JavaScript loads in the browser.
  7. Angular hydrates the server-rendered HTML.
  8. The application becomes fully interactive.

Simple definition

SSR means the initial HTML is rendered on the server and sent to the browser, after which Angular takes over in the browser.

2. SSR Architecture

A simplified Angular SSR flow looks like this:

Browser
   │
   │ GET /products
   ▼
Angular SSR Server
   │
   │ Run Angular
   │
   │ Get required data
   ▼
ASP.NET Core Web API
   │
   │ JSON
   ▼
Angular SSR Server
   │
   │ Generate HTML
   ▼
Browser
   │
   │ Display rendered HTML
   ▼
Angular JavaScript loads
   │
   ▼
Hydration
   │
   ▼
Interactive Angular Application

The major difference from CSR is where the initial rendering occurs.

CSR → Browser renders initial UI

SSR → Server renders initial UI

3. Full Simple Sample Program

Let's create a simple Angular SSR application that displays products from an ASP.NET Core Web API.

ASP.NET Core Web API

Product.cs

public class Product
{
    public int Id { get; set; }

    public string Name { get; set; } = string.Empty;

    public decimal Price { get; set; }
}

ProductsController.cs

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult GetProducts()
    {
        var products = new List<Product>
        {
            new Product
            {
                Id = 1,
                Name = "Laptop",
                Price = 50000
            },
            new Product
            {
                Id = 2,
                Name = "Mouse",
                Price = 1000
            },
            new Product
            {
                Id = 3,
                Name = "Keyboard",
                Price = 2000
            }
        };

        return Ok(products);
    }
}

Angular SSR Application

For a new Angular project, SSR can be enabled when creating the application, or added to an existing application using Angular CLI.

For example:

ng add @angular/ssr

The CLI configures the SSR infrastructure for the project.

product.ts

export interface Product {
  id: number;
  name: string;
  price: number;
}

product-service.ts

import { inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

import { Product } from './product';

@Injectable({
  providedIn: 'root'
})
export class ProductService {

  private http = inject(HttpClient);

  private apiUrl = 'https://localhost:7001/api/products';

  getProducts(): Observable<Product[]> {
    return this.http.get<Product[]>(this.apiUrl);
  }
}

products.ts

import { Component, inject } from '@angular/core';
import { AsyncPipe } from '@angular/common';

import { ProductService } from './product-service';

@Component({
  selector: 'app-products',
  standalone: true,
  imports: [AsyncPipe],
  templateUrl: './products.html'
})
export class Products {

  private productService = inject(ProductService);

  products$ = this.productService.getProducts();
}

products.html

<h2>Products</h2>

@if (products$ | async; as products) {

  @for (product of products; track product.id) {

    <div>
      <h3>{{ product.name }}</h3>

      <p>
        Price: {{ product.price }}
      </p>
    </div>

  }

}

app.config.ts

import { ApplicationConfig } from '@angular/core';
import {
  provideHttpClient,
  withFetch
} from '@angular/common/http';
import { provideClientHydration } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {

  providers: [

    provideHttpClient(
      withFetch()
    ),

    provideClientHydration()

  ]

};

The exact SSR bootstrap/configuration files can vary with the Angular version and CLI-generated project structure, but the component and service programming model remains largely familiar.

4. How SSR Works

Suppose the user opens:

https://www.example.com/products

Step 1 — Browser requests /products

Browser
   │
   │ GET /products
   ▼
Server

Unlike pure CSR, the server doesn't simply rely on the browser to generate all the initial content.

Step 2 — Angular executes on the server

The server runs Angular and creates the Products component.

The component requests:

products$ = this.productService.getProducts();

The request goes to the ASP.NET Core Web API.

Angular SSR Server
       │
       │ GET /api/products
       ▼
ASP.NET Core Web API

Step 3 — ASP.NET Core returns JSON

The API returns:

[
  {
    "id": 1,
    "name": "Laptop",
    "price": 50000
  },
  {
    "id": 2,
    "name": "Mouse",
    "price": 1000
  }
]

Step 4 — Angular generates HTML on the server

Angular processes:

@for (product of products; track product.id) {
    <h3>{{ product.name }}</h3>
}

The server can generate HTML conceptually similar to:

<h2>Products</h2>

<div>
    <h3>Laptop</h3>
    <p>Price: 50000</p>
</div>

<div>
    <h3>Mouse</h3>
    <p>Price: 1000</p>
</div>

Step 5 — Server sends rendered HTML

The browser receives HTML containing the initial page content.

Server
   │
   │ Rendered HTML
   ▼
Browser

The browser can therefore display:

Products

Laptop
Price: 50000

Mouse
Price: 1000

before Angular has fully taken over on the client.

5. What Happens Next? — Hydration

This is an important modern Angular SSR concept.

After receiving server-rendered HTML, the browser still downloads the Angular JavaScript.

Server-rendered HTML
        ↓
Browser displays page
        ↓
Angular JS downloads
        ↓
Angular starts
        ↓
Hydration
        ↓
Application becomes interactive

What is Hydration?

Hydration is the process where Angular running in the browser attaches its application behavior to the HTML that was already rendered by the server.

For example, the server may have already produced:

<button>Add to Cart</button>

Initially, the user can see the button.

After hydration, Angular's event handling becomes active:

Click
   ↓
Angular event handler
   ↓
Add product to cart

Easy way to remember

SSR creates the initial HTML. Hydration makes that HTML part of the interactive Angular application.

6. SSR Request Flow

The complete flow can be remembered as:

             Initial Request

Browser
   │
   │ GET /products
   ▼
Angular SSR Server
   │
   │ API Request
   ▼
ASP.NET Core Web API
   │
   │ JSON
   ▼
Angular SSR Server
   │
   │ Generate HTML
   ▼
Browser
   │
   │ Display HTML
   ▼
Angular JavaScript
   │
   ▼
Hydration
   │
   ▼
Interactive Application

7. Advantages of SSR

Faster initial content display

The browser receives useful HTML immediately rather than waiting for all client-side JavaScript to execute first.

Better SEO support

Search engines receive meaningful HTML directly from the server.

For example, an article page could arrive as:

<h1>Understanding ASP.NET Core Web API</h1>

<p>
    ASP.NET Core Web API is used to build HTTP services...
</p>

This is particularly useful for:

  • Blogs
  • Portfolio sites
  • Article pages
  • Product pages
  • E-commerce sites
  • Public content

Better social-media previews

SSR can make it easier for crawlers to obtain page metadata such as:

<title>Angular Tutorial</title>

<meta
  name="description"
  content="Learn Angular step by step">

8. Disadvantages of SSR

More server work

With CSR:

Server → files/data
Browser → rendering

With SSR:

Server → execute Angular
       → fetch data
       → generate HTML
       → send HTML

Therefore SSR adds server-side rendering work.

More architectural complexity

You now have both:

Server environment
+
Browser environment

Some browser-specific APIs need special consideration because they don't exist on the server.

For example:

window
document
localStorage
sessionStorage

These are fundamentally browser APIs and must not be used indiscriminately during server execution.

Server cost

More requests may require server-side rendering work, which can increase CPU/memory requirements compared with serving a purely static CSR shell.

9. CSR vs SSR

This is the most important interview distinction.

Feature CSR SSR
Full form Client-Side Rendering Server-Side Rendering
Initial rendering Browser Server
Initial HTML content Usually minimal app shell Meaningful rendered HTML
JavaScript Required for initial app rendering Required for later Angular interactivity
Initial content Can take longer Often appears sooner
SEO More consideration required Generally easier
Server workload Lower rendering workload Higher rendering workload
Hydration Not applicable in the same initial SSR sense Important
Best suited for Dashboards, internal apps Public/content-heavy sites

10. CSR vs SSR with Angular + ASP.NET Core

CSR

Browser
   │
   ▼
Angular
   │
   │ HTTP
   ▼
ASP.NET Core Web API
   │
   ▼
SQL Server

Angular renders UI
in the browser

SSR

Browser
   │
   ▼
Angular SSR Server
   │
   ├──► ASP.NET Core Web API
   │           │
   │           ▼
   │       SQL Server
   │
   ▼
Rendered HTML
   │
   ▼
Browser
   │
   ▼
Hydration

11. Your Portfolio Example

For a portfolio containing public pages such as:

Home
Portfolio
Articles
Article Details
Contact

SSR can be useful particularly for public content such as:

/articles/angular-signals

because the initial response can already contain:

<h1>Angular Signals Explained</h1>

<p>
    Angular Signals provide reactive state management...
</p>

A search crawler or browser receives meaningful HTML immediately.

By contrast, an authenticated admin dashboard:

/admin/dashboard

often doesn't have the same SEO requirement and may work perfectly well with client-side rendering.

This is one reason modern Angular applications may use different rendering strategies depending on the route and application requirements.

12. Key Points

  • SSR = Server-Side Rendering.
  • Angular executes on the server for the initial rendering.
  • Server generates the initial HTML.
  • Browser receives meaningful rendered HTML.
  • Angular JavaScript subsequently runs in the browser.
  • Hydration makes the server-rendered page interactive.
  • SSR can improve initial content delivery.
  • SSR is particularly valuable for SEO-sensitive public pages.
  • SSR increases server workload and application complexity.
  • Browser-only APIs require care when code can execute on the server.

Easy memory trick

CSR
C = Client
Browser renders

SSR
S = Server
Server renders

13. Interview Questions and Answers

1. What is Server-Side Rendering?

Answer:
Server-Side Rendering is a technique where the server executes the application and generates the initial HTML before sending it to the browser.

2. How does SSR work in Angular?

Answer:
Angular runs on the server for the initial request, generates HTML, and sends it to the browser. Angular JavaScript then loads in the browser and hydrates the page.

3. What is hydration?

Answer:
Hydration is the process where Angular running in the browser reuses the server-rendered HTML and attaches Angular's application behavior and interactivity to it.

4. What is the difference between CSR and SSR?

Answer:

CSR → Initial UI rendered in browser
SSR → Initial UI rendered on server

SSR sends meaningful HTML initially, while CSR relies primarily on browser-side JavaScript to build the initial UI.

5. Why is SSR useful for SEO?

Answer:
SSR sends already-rendered HTML containing page content and metadata, making the initial content directly available to crawlers without depending entirely on client-side rendering.

6. Does Angular stop running in the browser when SSR is used?

Answer:
No. SSR handles the initial rendering. Angular subsequently runs in the browser and makes the application interactive through hydration.

7. What are the disadvantages of SSR?

Answer:
SSR adds server workload and architectural complexity. Developers must also handle code that may execute in both server and browser environments.

8. What kinds of applications benefit from SSR?

Answer:
SSR is particularly useful for public-facing, SEO-sensitive applications such as:

Blogs
Portfolio sites
News sites
E-commerce product pages
Public article sites

9. Can Angular use ASP.NET Core Web API with SSR?

Answer:
Yes. Angular's SSR server can call the ASP.NET Core Web API to obtain data needed for rendering.

Angular SSR
     ↓
ASP.NET Core Web API
     ↓
SQL Server

The generated HTML is then returned to the browser.

Interview one-line answer

Server-Side Rendering (SSR) is a rendering approach where Angular generates the initial HTML on the server and sends it to the browser, after which the client-side Angular application hydrates the page and provides interactivity.

Keep Learning - More From This Category

← Back to Articles