Szerveroldali renderelés

Célok

A lecke végére meg tudod mondani, mit jelent a szerveroldali renderelés (SSR), mit nyer és mit kockáztat vele a felhasználó és a szerver, és el tudod magyarázni a hidratálás szerepét.

Miért állítsa elő a szerver a HTML-t?

A CSR-nél a felhasználó üres vázat kap, a tartalom csak a program lefutása után jelenik meg. Ha a szerver már a válaszban elküldi a fontos tartalmat, a böngésző azonnal megjeleníthet valamit, a keresőrobot és a hivatkozás-előnézet is látja, és gyengébb eszközön sem kell megvárni a program futását. A szerveroldali renderelés (SSR, Server-Side Rendering) azt jelenti, hogy a szolgáltatás a kéréshez HTML-t állít elő, amely már tartalmazza a nézet fontos tartalmát.

Friss kurzusadatból HTML

A Kurzuspont SSR-változata minden kérésnél az aktuális adatból építi fel a HTML-t. Az alábbi a tényleges válasz:

$ 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>

(Tördelve; a valódi válasz egy sorban érkezik.) Ellentétben a CSR-rel, itt a kurzusok és a szabad helyek már a válaszban vannak, JavaScript nélkül is olvashatók. Egy új jelentkezés után a következő kérés már a frissített adatot adja:

jelentkezés előtt:  /ssr -> 9 szabad hely
egy jelentkezés után: /ssr -> 8 szabad hely

A HTML tehát nem előre tárolt fájl: kérésenként áll elő.

flowchart LR
    Q[Kurzusoldal kérése] --> S[Szerver: adat + HTML-előállítás]
    S --> H[HTML-válasz]
    H --> B[Böngésző: feldolgozás]

A böngészőnek továbbra is le kell töltenie a stílusokat és más erőforrásokat. Az SSR nem „kész képet” küld, hanem kész tartalmú dokumentumot, amelyből a böngésző ugyanúgy építi a DOM-ot és a képernyőt (3.3).

A szerver munkája és az első tartalom

Az SSR előnye, hogy a lényeges tartalom már az első HTML-válaszban megjelenik. A web.dev összefoglalója szerint ez gyors első tartalmi megjelenést és kevesebb kliensoldali JavaScriptet adhat; az ára az, hogy a szerver munkája miatt az első bájt később érkezhet meg. Nem automatikus gyorsulás: a szervernek adatot kell lekérnie és HTML-t előállítania, és ha ez lassú, a válasz késik (10. fejezet).

Interaktivitás és hidratálás

Egy szerver által előállított HTML-oldal önmagában is tartalmazhat működő hivatkozásokat és űrlapokat. Ha a felület bonyolultabb kliensoldali interakciót kíván, a böngészőben futó JavaScript a meglévő HTML-hez eseménykezelést és alkalmazási állapotot kapcsol. Ezt hívjuk hidratálásnak (hydration). A web.dev ezt úgy írja le, hogy a szerver HTML-t küld, majd a kliens JavaScript adja hozzá az állapotot és az interaktivitást, így az oldal késznek látszhat, mielőtt a bevitelre reagálna.

sequenceDiagram
    participant B as Böngésző
    participant S as Szerver
    B->>S: GET /kurzusok
    S-->>B: Kész HTML (a lista látható)
    Note over B: Olvasható, de a gombok még nem reagálnak
    B->>S: GET /app.js
    S-->>B: JavaScript
    Note over B: Hidratálás után a gombok működnek

A hidratálásnak is van ára: a programot le kell tölteni és futtatni, és a szerveroldali HTML-nek illeszkednie kell ahhoz az állapothoz, amelyet a kliens várt. Ha a kettő eltér, hibás megjelenés vagy fölösleges újrarajzolás keletkezhet. A részletes keretrendszer-mechanizmusok itt nem célok; a fogalmi tanulság az, hogy a kész HTML és a működő kliensprogram két külön állapot, és közöttük idő telik el.

SSR és navigáció

Többoldalas alkalmazásnál minden navigáció kaphat új, szerveroldalon előállított HTML-t. Egyoldalas alkalmazásnál a legelső kérés érkezhet SSR-rel, a későbbi nézetváltás pedig történhet kliensoldalon (6.1). A navigációs modell és a renderelési stratégia tehát kombinálható.

Végigvezetett példa: a Kurzuspont kurzusoldala

Egy kurzus oldala nyilvános és fontos, hogy a hivatkozás-előnézet és a kereső lássa. A Kurzuspont szervere az oldal minden kérésére elkészíti a HTML-t az aktuális adatból. A jelentkezési gomb viszont csak hidratálás után működik JavaScripttel. Ennek kezelése: a gomb egy valódi <form> elemben van, amely JavaScript nélkül is elküldi a kérést (fokozatos fejlesztés, 3.5), a JavaScript pedig később gyorsabb élményt ad hozzá.

Idő	Mit lát a hallgató?	Mi még hiányzik?
HTML megérkezik	A kurzus teljes leírása és a szabad helyek	A szkript betöltése
Szkript lefut	A gombok azonnali visszajelzése	–

Gyakori tévhitek

Állítás	Pontosítás
„SSR esetén a szerver képernyőképet küld.”	HTML-t állít elő, amelyet a böngésző renderel.
„SSR oldalon nincs JavaScript.”	Később interaktív program is kapcsolódhat a HTML-hez.
„A látható HTML minden gombot azonnal működővé tesz.”	A JavaScriptre épülő műveletek később válnak elérhetővé.
„SSR csak MPA-ban létezik.”	Egy SPA kezdeti oldalához is használható.
„Az SSR mindig gyorsabb, mint a CSR.”	Az első tartalom gyorsabb lehet, de a szerver munkája késleltetheti.

Röviden

• SSR: a szerver kérésenként állítja elő a HTML-t az aktuális adatból.
• Előny: az első válasz már tartalmazza a fontos tartalmat; hátrány: szervermunka, és az első bájt később érkezhet.
• A hidratálás a kész HTML-hez kapcsolja a kliensprogramot; közben a felület látszólag kész, de még nem interaktív.
• A személyre szabott HTML gyorsítótárazása külön figyelmet kér.

Ellenőrző kérdések

1. Mi a különbség a /csr és a /ssr válasza között?
2. Mi a hidratálás, és miért lehet köztes állapot, amikor a gomb még nem működik?
3. Miért lehet lassabb az első bájt SSR-nél?
4. Hogyan lehet a jelentkezési gomb JavaScript nélkül is működőképes?

Tanulási források

• Rendering on the Web (web.dev) — SSR, hidratálás és kompromisszumaik angolul.