Statikus előállítás és hibrid renderelés

Célok

A lecke végére meg tudod mondani, mit jelent a statikus előállítás (SSG), mi a hátránya a frissesség szempontjából, és hogyan lehet egy oldalon többféle renderelési stratégiát kombinálni.

Miért ne kelljen minden kérésnél újra összerakni?

Az SSR minden kérésnél munkát végez. Ha a tartalom sokaknak azonos és ritkán változik (kurzusleírás, szabályzat, dokumentáció), ez fölösleges: ugyanazt a HTML-t állítaná elő újra és újra. A statikus előállításnál a HTML a közzététel előtt készül el, és később fájlként szolgálható ki, akár CDN-ről (4.4). Az SSG (Static Site Generation) a statikus oldalgenerálás.

Kurzusleírás a közzététel előtt

Az egyetem közzéteszi a következő félév hivatalos kurzusleírásait. Ha ezek a szövegek ritkán változnak és mindenkinek ugyanazok, a HTML előre létrehozható. A közzétételi folyamat (build) a forrásból elkészíti az oldalakat, a kiszolgáló vagy a CDN a kész HTML-t továbbítja.

flowchart LR
    F[Tartalmi forrás] --> E[Előállítás közzétételkor]
    E --> H[Kész HTML]
    H --> C[Kiszolgáló vagy CDN]
    C --> B[Böngésző]

A web.dev szerint a statikus renderelés gyors, egyenletes első bájtot ad, jól illeszkedik a CDN-ekhez, és kevés JavaScripttel az interaktivitás sem romlik. Nem jó viszont rengeteg URL-lel rendelkező oldalaknak és személyre szabott oldalaknak.

A frissesség ára

A kész HTML gyorsan kiszolgálható és egyszerűen gyorsítótárazható. Hátránya, hogy ha az adat megváltozik, a HTML-t újra elő kell állítani és közzé kell tenni. Kipróbáltuk ugyanazt a kurzuslistát két úton: az SSR változat kérésenként épül, az SSG változat egy előre elkészített fájl. Egy jelentkezés után:

                        jelentkezés előtt   egy jelentkezés után
/ssr (kérésenként)      9 szabad hely       8 szabad hely
/ssg (előre kész fájl)  9 szabad hely       9 szabad hely   <- elavult
/api (adat)             "jelentkezett":31   "jelentkezett":32

Az SSG-oldal a közzététel pillanatában igaz állapotot mutatja, és amíg nem generálják újra, nem követi a változást. Ez a leírás vagy az órarend esetében lehet elfogadható (újragenerálással), a szabad hely számánál nem. Ha az üzemeltető folyamata hibás, régi információ maradhat kint.

A megoldás gyakran az, hogy a statikus oldal a leírást tartalmazza, a friss számot viszont a böngésző külön API-kérésből szerzi meg. Ez már hibrid felépítés: a különböző tartalmak frissességi igénye eltérő.

Három hely a tartalom előállítására

Ugyanaz a nézet előállhat közzétételkor, a szerveren egy kérésnél, vagy a böngészőben. A választás nem pusztán „melyik gyorsabb?” kérdés:

Stratégia	Mikor áll elő a fő nézet?	Mire figyelünk?
SSG	Közzététel előtt	Frissítés és újragenerálás
SSR	A kérés kiszolgálásakor	Szervermunka és válaszidő
CSR	A böngészőben	JavaScript és adatbetöltés

A táblázat egyszerűsített. Valós alkalmazásokban a három keverhető: egy statikus dokumentációban lehet kliensoldali kereső, egy SSR-oldal interaktív része működhet kliensoldalon, egy SPA kaphat kezdeti szerveroldali HTML-t.

Hibrid megoldások és hidratálás

Hibrid megoldásnál az egyes oldalak vagy oldalelemek külön stratégiát követnek:

flowchart TB
    O[Kurzusoldal] --> L[Leírás: SSG, előre kész]
    O --> F[Szabad helyek: CSR, API-ból]
    O --> J[Jelentkezés: szerver dönt]
    L --> CDN[CDN-ből, gyors]
    F --> API[API-kérés]
    J --> SZ[POST a szervernek]

A leírás előre előállított, a szabad helyek száma API-ból frissül, a jelentkezést a szerver fogadja el. Ha az előre vagy szerveroldalon készült HTML-re a JavaScript átveszi az interaktív vezérlést, hidratálás történik (6.3). A legfontosabb, hogy ne küldjünk és futtassunk több programot, mint amennyi az adott feladat használhatóságához kell.

A web.dev további köztes formákat is említ, például az előrenderelést (prerendering: egy kliensalkalmazás állapotát a build idején HTML-be mentik) vagy a részleges hidratálást. A lényeg az, hogy a stratégiák nem külön világok, hanem egy skála.

Végigvezetett példa: a Kurzuspont oldalai

Oldal	Stratégia	Indok
Szabályzatok, félévi kurzusleírások	SSG	Ritkán változik, mindenkinek azonos, jól kereshető.
Kurzusoldal szabad hellyel	SSG + API-frissítés	A leírás statikus, a szám élő.
„Saját jelentkezéseim”	SSR vagy API-val töltött CSR	Személyes, bejelentkezéshez kötött, nem gyorsítótárazható közösen.
Közös tanulócsoport-szerkesztő	CSR	Sok helyi interakció.

Az építési folyamat tartalmaz egy ellenőrző lépést is: ha új kurzusleírás kerül ki, az újragenerálás automatikusan fut, és a CDN gyorsítótárát frissíti (10. fejezet).

Gyakori tévhitek

Állítás	Pontosítás
„A statikus oldal soha nem változik.”	Új közzétételkor frissülhet, és kliensoldali adatot is kérhet.
„SSG = JavaScript nélküli oldal.”	Interaktív program is kapcsolható a kész HTML-hez.
„Egy alkalmazásnak egyetlen renderelési stratégiát kell választania.”	Az oldalak és az elemek eltérő igényeket követhetnek.
„Az első gyors HTML garantálja a gyors interakciót.”	A későbbi programmunka és adatkérés is számít.
„A statikus oldal mindig a legolcsóbb megoldás.”	Frissítési folyamatot és ellenőrzést is igényel.

Röviden

• SSG: a HTML a közzététel előtt készül el, fájlként szolgálható ki; gyors és CDN-barát.
• Ára a frissesség: változás után újra kell generálni; a kipróbált példán az SSG-oldal elavult maradt.
• A hibrid stratégia a tartalmak eltérő frissességi igényéhez igazodik.
• A három stratégia (SSG, SSR, CSR) keverhető egy oldalon belül is.

Ellenőrző kérdések

1. Miért maradt elavult az /ssg válasz egy jelentkezés után?
2. Mikor jó választás az SSG, és mikor nem?
3. Hogyan lehet egy statikus oldalon élő adatot megjeleníteni?
4. Mi az előnye és a hátránya a hibrid felépítésnek?

Tanulási források

• Rendering on the Web (web.dev) — statikus renderelés, előrenderelés, hidratálás és társaik angolul.