What is Static Site Generation (SSG)?

1. What is Static Site Generation?

Static Site Generation (SSG) is a rendering technique where HTML pages are generated in advance, usually during the application build process, rather than being generated for every user request.

The generated HTML files are then stored on a web server or CDN and served directly to users.

Simple definition

SSG generates HTML before the user requests the page.

For example, suppose your Angular application contains these pages:

/
/about
/articles
/articles/angular-signals
/articles/design-patterns
/contact

During the build/deployment process, Angular can generate HTML for selected routes:

index.html
about/index.html
articles/index.html
articles/angular-signals/index.html
articles/design-patterns/index.html
contact/index.html

When a user requests:

/articles/angular-signals

the server can return the already-generated HTML.

It doesn't need to render that page from scratch for every request.

2. Basic SSG Architecture

                 BUILD TIME
                     │
                     ▼
              Angular Application
                     │
                     │ Get data
                     ▼
              ASP.NET Core API
                     │
                     ▼
                 SQL Server
                     │
                     ▼
              Angular generates
                HTML pages
                     │
                     ▼
             Static HTML Files
                     │
                     │ Deploy
                     ▼
              Web Server / CDN


                 USER REQUEST
                     │
                     ▼
                   CDN
                     │
                     │ Existing HTML
                     ▼
                  Browser

The important point is:

Rendering happens BEFORE the user request.

3. Full Simple Sample Program

Let's consider a simple Angular application with an About page that we want to prerender.

Modern Angular commonly refers to this approach as prerendering.

app.routes.ts

import { Routes } from '@angular/router';
import { Home } from './home';
import { About } from './about';

export const routes: Routes = [
  {
    path: '',
    component: Home
  },
  {
    path: 'about',
    component: About
  }
];

home.ts

import { Component } from '@angular/core';

@Component({
  selector: 'app-home',
  standalone: true,
  templateUrl: './home.html'
})
export class Home {
}

home.html

<h1>Welcome to JN Tech</h1>

<p>
  Learn Angular, ASP.NET Core, SQL Server and Design Patterns.
</p>

about.ts

import { Component } from '@angular/core';

@Component({
  selector: 'app-about',
  standalone: true,
  templateUrl: './about.html'
})
export class About {
}

about.html

<h1>About Me</h1>

<p>
  Welcome to my technical portfolio.
</p>

<p>
  Here I share articles about Angular,
  ASP.NET Core, SQL Server and software architecture.
</p>

Server routes

With Angular's server-side rendering/prerendering configuration, routes can be configured with a render mode.

Conceptually:

import {
  RenderMode,
  ServerRoute
} from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  {
    path: '**',
    renderMode: RenderMode.Prerender
  }
];

Here:

RenderMode.Prerender

tells Angular that these routes should be generated ahead of time.

4. What Happens During the Build?

Suppose we build the application:

ng build

Angular processes the routes.

For example:

/
        ↓
Generate HTML

/about
        ↓
Generate HTML

The output can contain static HTML corresponding to those routes.

Conceptually:

dist/
│
├── index.html
│
└── about/
    └── index.html

The important difference is that the rendering happened during the build/prerender phase, not when the user visited /about.

5. What Happens When the User Visits?

Suppose the user opens:

https://www.example.com/about

The request becomes:

Browser
   │
   │ GET /about
   ▼
Web Server / CDN
   │
   │ Find generated HTML
   ▼
about/index.html
   │
   ▼
Browser

The HTML already exists.

Therefore, the server doesn't have to execute Angular to generate the initial HTML for that request.

6. SSG with API Data

SSG becomes more interesting when pages depend on backend data.

Suppose your portfolio contains an article:

/articles/angular-signals

Your API could provide:

GET /api/articles/angular-signals

During prerendering:

Angular Build
     │
     │ GET article
     ▼
ASP.NET Core Web API
     │
     ▼
SQL Server
     │
     ▼
Article JSON
     │
     ▼
Angular
     │
     ▼
Generate HTML

The generated page could contain:

<h1>Angular Signals</h1>

<p>
  Signals provide a reactive way to manage state
  in Angular applications.
</p>

That HTML is then deployed.

7. Important Point About Data

Suppose your article has:

Views: 100

At build time Angular generates:

<p>Views: 100</p>

Later the database changes:

Views: 150

The previously generated HTML may still contain:

Views: 100

until the page is regenerated/rebuilt, unless that particular data is subsequently fetched dynamically in the browser.

This is one of the most important characteristics of SSG:

Purely prerendered content reflects the data available when the page was generated.

8. Why is SSG Fast?

Consider SSR:

User
 ↓
Request
 ↓
Server executes application
 ↓
Fetch data
 ↓
Generate HTML
 ↓
Return HTML

With SSG:

Build Time

Generate HTML
      ↓
Store HTML


Later...

User
 ↓
Request
 ↓
Return existing HTML

The expensive rendering work has already happened.

That makes SSG particularly suitable for CDNs.

9. Advantages of SSG

Very fast page delivery

The HTML already exists.

The server doesn't need to generate it for every visitor.

Good SEO characteristics

Search engines receive meaningful HTML immediately.

For example:

<title>Angular Signals Tutorial</title>

<h1>Angular Signals</h1>

<p>
  Learn how Angular Signals work...
</p>

Low server workload

Because pages are pre-generated:

Request
   ↓
Static HTML

instead of:

Request
   ↓
Execute Angular
   ↓
Fetch data
   ↓
Generate HTML

Excellent CDN support

Static pages can easily be cached and distributed through CDNs.

User in India
      ↓
Nearby CDN
      ↓
Static HTML

Good security characteristics

A purely static frontend has less server-side rendering infrastructure exposed for page generation.

Your backend APIs still require normal authentication, authorization, validation, and other security controls.

10. Disadvantages of SSG

Data can become outdated

Suppose an article changes after deployment.

The generated page doesn't automatically know that the database changed.

You may need to:

Change content
      ↓
Rebuild/prerender
      ↓
Deploy new HTML

Large sites can have longer builds

Suppose you have:

10 pages

No problem.

But suppose you have:

100,000 product pages

Generating all of them during a build can become expensive and slow.

Not ideal for highly dynamic pages

Consider:

/admin/dashboard

The dashboard may contain:

Current User
Current Orders
Live Notifications
Current Revenue
User Permissions

Generating this ahead of time generally doesn't make sense.

CSR or SSR/dynamic approaches are more appropriate depending on the requirements.

11. SSG vs CSR vs SSR

This is the most important comparison.

12. The Most Important Difference

Remember these three sentences:

CSR
↓
Render when JavaScript runs in the browser.


SSR
↓
Render when the user requests the page.


SSG
↓
Render before the user requests the page.

Or even simpler:

CSR = Browser time

SSR = Request time

SSG = Build time

This is an excellent interview memory trick.

13. Example with Your Angular + ASP.NET Core Architecture

Imagine an Angular portfolio with:

Home
About
Articles
Article Details
Contact

Admin Login
Admin Dashboard
Article Management

You don't necessarily need the same rendering strategy everywhere.

For example:

Public Pages
│
├── Home ───────────── SSG
├── About ──────────── SSG
├── Articles ───────── SSG/SSR
├── Article Details ── SSG/SSR
│
└── Contact ────────── SSG/CSR


Admin
│
├── Login ──────────── CSR
├── Dashboard ──────── CSR
└── Article CRUD ───── CSR

Why?

Public article content benefits from:

Fast loading
+
SEO
+
Shareable content

while an admin dashboard needs:

Authentication
+
User-specific data
+
Frequent API calls
+
High interactivity

So CSR is usually more natural for that part.

This combination is often described as hybrid rendering.

14. What Happens After an SSG Page Loads?

An important point:

SSG does not mean Angular disappears.

The initial HTML can be generated beforehand:

Build
 ↓
Static HTML
 ↓
Browser

Then Angular JavaScript can load in the browser and make the application interactive.

Pre-generated HTML
       ↓
Browser displays it
       ↓
Angular JavaScript loads
       ↓
Hydration
       ↓
Interactive Angular application

Therefore:

SSG determines how the initial HTML is produced. Angular can still become a fully interactive client application afterward.

15. Key Points

• SSG = Static Site Generation.
• Angular commonly calls this prerendering.
• HTML is generated before the user's request.
• Generation normally happens during build/deployment.
• Generated pages can be served as static files.
• SSG provides excellent initial performance.
• It is highly CDN-friendly.
• It is useful for SEO-sensitive content.
• Static content can become stale.
• Content changes may require regeneration/redeployment.
• SSG isn't ideal for highly dynamic, personalized pages.
• Angular can hydrate a prerendered page and make it interactive.

Easy memory trick

CSR → Client renders

SSR → Server renders per request

SSG → Build generates beforehand

16. Interview Questions and Answers

1. What is Static Site Generation?

Answer:
Static Site Generation is a rendering technique where HTML pages are generated ahead of time, usually during the build process, and served as static files when users request them.

2. When is HTML generated in SSG?

Answer:

HTML is normally generated during:

Build / Prerender time

rather than when each user requests the page.

3. What is SSG called in Angular?

Answer:
Angular commonly refers to this approach as prerendering, where selected application routes are rendered into static HTML ahead of user requests.

4. What is the difference between SSR and SSG?

Answer:

SSR
Request → Generate HTML → Return HTML

SSG
Build → Generate HTML

Later:

Request → Return existing HTML

SSR generates pages dynamically for requests, while SSG generates them beforehand.

5. What is the difference between CSR and SSG?

Answer:

CSR → Browser generates initial UI

SSG → HTML generated beforehand

With CSR, JavaScript running in the browser produces the initial application content. With SSG, useful HTML already exists when the request arrives.

6. What is the main advantage of SSG?

Answer:
Performance. Because HTML is already generated, it can be served quickly from a web server or CDN with very little server-side processing.

7. What is the main disadvantage of SSG?

Answer:
Generated content can become outdated when backend data changes. The page may need to be regenerated and redeployed.

8. Is SSG good for SEO?

Answer:
Yes. Search crawlers receive meaningful pre-generated HTML, making SSG well suited to public, indexable content.

9. Can SSG pages call APIs?

Answer:
Yes. APIs can be called during prerendering to obtain data used to generate the HTML. Angular can also make additional API requests in the browser after the page loads.

10. Can Angular use CSR, SSR and SSG together?

Answer:
Yes. Modern Angular applications can use different rendering strategies for different routes.

For example:

Home             → SSG
About            → SSG
Article Details  → SSR/SSG
Admin Dashboard  → CSR

This is a hybrid rendering approach.

Interview One-Line Answer

Static Site Generation (SSG) is a rendering approach where HTML pages are generated ahead of time, typically during the build/prerender process, and served as pre-generated static files instead of being rendered for every request.