By the end of the lesson, you can say what static generation (SSG) means, what its drawback is with respect to freshness, and how several rendering strategies can be combined on one page.
Why should it not have to be reassembled on every request?
SSR does work on every request. If the content is the same for many people and changes rarely (a course description, a regulation, documentation), this is wasteful: it would produce the same HTML again and again. With static generation the HTML is made before publication, and can later be served as a file, even from a CDN (4.4). SSG (Static Site Generation) is static page generation.
A course description before publication
The university publishes the official course descriptions of the next semester. If these texts change rarely and are the same for everyone, the HTML can be created in advance. The publishing process (build) produces the pages from the source, and the server or the CDN passes on the finished HTML.
flowchart LR
F[Content source] --> E[Generation at publication]
E --> H[Finished HTML]
H --> C[Server or CDN]
C --> B[Browser]
According to web.dev, static rendering gives a fast, consistent first byte, fits CDNs well, and with little JavaScript interactivity does not suffer either. It is not good, however, for pages with a huge number of URLs and for personalized pages.
The price of freshness
Finished HTML can be served quickly and cached easily. Its drawback is that when the data changes, the HTML must be produced again and published. We tried the same course list in two ways: the SSR version is built per request, the SSG version is a file prepared in advance. After one enrolment:
before an enrolment after one enrolment
/ssr (per request) 9 szabad hely 8 szabad hely
/ssg (file prepared) 9 szabad hely 9 szabad hely <- stale
/api (data) "jelentkezett":31 "jelentkezett":32
("szabad hely" means "free places"; "jelentkezett" means "enrolled".) The SSG page shows the state that was true at the moment of publication, and until it is generated again it does not follow the change. This can be acceptable for a description or a timetable (with regeneration), but not for the number of free places. If the operator's process is faulty, old information can remain published.
The solution is often that the static page contains the description, while the browser obtains the fresh number from a separate API request. This is already a hybrid structure: the freshness needs of different contents differ.
Three places to produce the content
The same view can be produced at publication, on the server at a request, or in the browser. The choice is not merely a question of "which is faster?":
Strategy
When is the main view produced?
What do we watch?
SSG
Before publication
Refreshing and regeneration
SSR
When serving the request
Server work and response time
CSR
In the browser
JavaScript and data loading
The table is simplified. In real applications the three can be mixed: a static documentation can have a client-side search, the interactive part of an SSR page can work on the client side, an SPA can get initial server-side HTML.
Hybrid solutions and hydration
In a hybrid solution individual pages or page elements follow separate strategies:
flowchart TB
O[Course page] --> L[Description: SSG, prepared]
O --> F[Free places: CSR, from the API]
O --> J[Enrolment: the server decides]
L --> CDN[From the CDN, fast]
F --> API[API request]
J --> SZ[POST to the server]
The description is produced in advance, the number of free places is refreshed from the API, and the enrolment is accepted by the server. If JavaScript takes over interactive control of HTML made in advance or on the server, hydration takes place (6.3). The most important thing is not to send and run more programs than the usability of the given task needs.
Web.dev also mentions further intermediate forms, for example prerendering (the state of a client application is saved into HTML at build time) or partial hydration. The point is that the strategies are not separate worlds, but a spectrum.
Worked example: the pages of Kurzuspont
Page
Strategy
Reason
Regulations, semester course descriptions
SSG
Changes rarely, the same for everyone, easily searchable.
Course page with free places
SSG + API refresh
The description is static, the number is live.
"My enrolments"
SSR or CSR loaded from the API
Personal, tied to login, cannot be cached in common.
Shared study-group editor
CSR
Lots of local interaction.
The build process also includes a checking step: when a new course description is published, regeneration runs automatically, and refreshes the CDN's cache (chapter 10).
Common misconceptions
Statement
Clarification
"A static page never changes."
It can be refreshed at a new publication, and can also request client-side data.
"SSG = a page without JavaScript."
An interactive program can be attached to the finished HTML.
"An application must choose a single rendering strategy."
Pages and elements can follow different needs.
"A fast first HTML guarantees fast interaction."
The later program work and data requests count too.
"A static page is always the cheapest solution."
It also needs a refresh process and checking.
In brief
SSG: the HTML is made before publication and can be served as a file; fast and CDN-friendly.
Its price is freshness: after a change it must be generated again; in the tried example the SSG page stayed stale.
A hybrid strategy adapts to the different freshness needs of contents.
The three strategies (SSG, SSR, CSR) can be mixed even within one page.
Review questions
Why did the /ssg response stay stale after an enrolment?
When is SSG a good choice, and when is it not?
How can live data be displayed on a static page?
What are the advantage and the drawback of a hybrid structure?
Static generation and hybrid rendering
Objectives
By the end of the lesson, you can say what static generation (SSG) means, what its drawback is with respect to freshness, and how several rendering strategies can be combined on one page.
Why should it not have to be reassembled on every request?
SSR does work on every request. If the content is the same for many people and changes rarely (a course description, a regulation, documentation), this is wasteful: it would produce the same HTML again and again. With static generation the HTML is made before publication, and can later be served as a file, even from a CDN (4.4). SSG (Static Site Generation) is static page generation.
A course description before publication
The university publishes the official course descriptions of the next semester. If these texts change rarely and are the same for everyone, the HTML can be created in advance. The publishing process (build) produces the pages from the source, and the server or the CDN passes on the finished HTML.
flowchart LR F[Content source] --> E[Generation at publication] E --> H[Finished HTML] H --> C[Server or CDN] C --> B[Browser]According to web.dev, static rendering gives a fast, consistent first byte, fits CDNs well, and with little JavaScript interactivity does not suffer either. It is not good, however, for pages with a huge number of URLs and for personalized pages.
The price of freshness
Finished HTML can be served quickly and cached easily. Its drawback is that when the data changes, the HTML must be produced again and published. We tried the same course list in two ways: the SSR version is built per request, the SSG version is a file prepared in advance. After one enrolment:
("szabad hely" means "free places"; "jelentkezett" means "enrolled".) The SSG page shows the state that was true at the moment of publication, and until it is generated again it does not follow the change. This can be acceptable for a description or a timetable (with regeneration), but not for the number of free places. If the operator's process is faulty, old information can remain published.
The solution is often that the static page contains the description, while the browser obtains the fresh number from a separate API request. This is already a hybrid structure: the freshness needs of different contents differ.
Three places to produce the content
The same view can be produced at publication, on the server at a request, or in the browser. The choice is not merely a question of "which is faster?":
The table is simplified. In real applications the three can be mixed: a static documentation can have a client-side search, the interactive part of an SSR page can work on the client side, an SPA can get initial server-side HTML.
Hybrid solutions and hydration
In a hybrid solution individual pages or page elements follow separate strategies:
flowchart TB O[Course page] --> L[Description: SSG, prepared] O --> F[Free places: CSR, from the API] O --> J[Enrolment: the server decides] L --> CDN[From the CDN, fast] F --> API[API request] J --> SZ[POST to the server]The description is produced in advance, the number of free places is refreshed from the API, and the enrolment is accepted by the server. If JavaScript takes over interactive control of HTML made in advance or on the server, hydration takes place (6.3). The most important thing is not to send and run more programs than the usability of the given task needs.
Web.dev also mentions further intermediate forms, for example prerendering (the state of a client application is saved into HTML at build time) or partial hydration. The point is that the strategies are not separate worlds, but a spectrum.
Worked example: the pages of Kurzuspont
The build process also includes a checking step: when a new course description is published, regeneration runs automatically, and refreshes the CDN's cache (chapter 10).
Common misconceptions
In brief
Review questions
/ssgresponse stay stale after an enrolment?Learning resources