Server-side rendering

Objectives

By the end of the lesson, you can say what server-side rendering (SSR) means, what the user and the server gain and risk with it, and you can explain the role of hydration.

Why should the server produce the HTML?

With CSR the user receives an empty skeleton, and the content appears only after the program has run. If the server already sends the important content in the response, the browser can display something at once, the search robot and the link preview see it too, and even on a weaker device there is no need to wait for the program to run. Server-side rendering (SSR) means that for the request the service produces HTML that already contains the important content of the view.

From fresh course data to HTML

The SSR version of Kurzuspont builds the HTML from the current data on every request. Below is the actual response:

$ curl localhost:8084/ssr
<!doctype html><html lang="hu"><head><meta charset="utf-8"><title>Kurzuspont</title></head>
<body><h1>Kurzusok</h1><ul>
<li><a href="/kurzusok/webprog">Webprogramozás 1.</a> (9 szabad hely)</li>
<li><a href="/kurzusok/adatbazisok">Adatbázisok</a> (0 szabad hely)</li>
</ul></body></html>

(Wrapped; the real response arrives on a single line. "szabad hely" means "free places".) Unlike with CSR, here the courses and the free places are already in the response, readable even without JavaScript. After a new enrolment the next request already gives the updated data:

before an enrolment:  /ssr -> 9 szabad hely
after one enrolment:  /ssr -> 8 szabad hely

The HTML is thus not a pre-stored file: it is produced per request.

flowchart LR
    Q[Request for the course page] --> S[Server: data + HTML production]
    S --> H[HTML response]
    H --> B[Browser: processing]

The browser still has to download the styles and other resources. SSR does not send a "finished picture", but a document with finished content, from which the browser builds the DOM and the screen in the same way (3.3).

The server's work and the first content

The advantage of SSR is that the essential content appears already in the first HTML response. According to the summary of web.dev, this can give a fast first content display and less client-side JavaScript; the price is that, because of the server's work, the first byte may arrive later. It is not an automatic speed-up: the server has to fetch data and produce the HTML, and if this is slow, the response is late (chapter 10).

Interactivity and hydration

An HTML page produced by a server can contain working links and forms on its own. If the interface requires more complex client-side interaction, JavaScript running in the browser attaches event handling and application state to the existing HTML. This is called hydration. Web.dev describes it as the server sending HTML and then the client JavaScript adding the state and interactivity, so the page can look ready before it reacts to input.

sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: GET /kurzusok
    S-->>B: Finished HTML (the list is visible)
    Note over B: Readable, but the buttons do not respond yet
    B->>S: GET /app.js
    S-->>B: JavaScript
    Note over B: After hydration the buttons work

Hydration also has a price: the program has to be downloaded and run, and the server-side HTML must match the state that the client expected. If the two differ, faulty display or needless repainting can arise. The detailed framework mechanisms are not goals here; the conceptual lesson is that finished HTML and a working client program are two separate states, and time passes between them.

SSR and navigation

In a multi-page application every navigation can receive new, server-produced HTML. In a single-page application the very first request can arrive with SSR, and the later view changes can happen on the client side (6.1). The navigation model and the rendering strategy can therefore be combined.

Worked example: the course page of Kurzuspont

The page of a course is public, and it matters that the link preview and the search engine see it. The server of Kurzuspont prepares the HTML from the current data for every request of the page. The enrolment button, however, works with JavaScript only after hydration. The way to handle this: the button is in a real <form> element, which sends the request even without JavaScript (progressive enhancement, 3.5), and JavaScript later adds a faster experience.

Time	What does the student see?	What is still missing?
The HTML arrives	The full description of the course and the free places	Loading of the script
The script runs	Instant feedback from the buttons	–

Common misconceptions

Statement	Clarification
"With SSR the server sends a screenshot."	It produces HTML, which the browser renders.
"An SSR page has no JavaScript."	An interactive program can later attach to the HTML.
"The visible HTML makes every button work at once."	Operations that rely on JavaScript become available later.
"SSR exists only in an MPA."	It can be used for the initial page of an SPA too.
"SSR is always faster than CSR."	The first content can be faster, but the server's work can delay it.

In brief

• SSR: the server produces the HTML from the current data per request.
• Advantage: the first response already contains the important content; drawback: server work, and the first byte may arrive later.
• Hydration attaches the client program to the finished HTML; meanwhile the interface looks ready but is not yet interactive.
• Caching personalized HTML needs separate attention.

Review questions

1. What is the difference between the responses of /csr and /ssr?
2. What is hydration, and why can there be an intermediate state when the button does not work yet?
3. Why can the first byte be slower with SSR?
4. How can the enrolment button work even without JavaScript?

Learning resources

• Rendering on the Web (web.dev) — SSR, hydration, and their trade-offs.