Server-side rendering: teljes útmutató

A server-side rendering, magyarul szerveroldali renderelés, azt jelenti, hogy az oldal HTML-jét a szerver állítja elő minden kérésre, és a böngésző már kész tartalmat kap. A kereső így a lekéréskor, renderelés nélkül is látja a szöveget, a linkeket és a meta jelzéseket. A JavaScript ezután hidratálással teszi interaktívvá az oldalt, a tartalom elérhetősége pedig nem függ tőle.

Alapfogalmak

A szerveroldali renderelés a web eredeti működési módjához áll közel: a szerver kész HTML-oldalt küld, amelyet a böngésző azonnal meg tud jeleníteni. A modern értelemben vett szerveroldali renderelés annyiban más, hogy ugyanaz a JavaScript-alapú alkalmazáskód fut a szerveren és a böngészőben is. A szerver lefuttatja az alkalmazást az adott URL-re, előállítja belőle a HTML-t, és ezt küldi el. A böngészőben a szkript ezután átveszi az irányítást, és innentől az oldal úgy működik, mint egy kliensoldali alkalmazás.

A keresők szempontjából ez a megoldás egyesíti a két világ előnyét. A kiinduló HTML-ben ott van a teljes tartalom, a linkek és a meta adatok, így a kereső a lekéréskor mindent megkap, és nem kell a renderelésre várnia. A látogató pedig a gyors első megjelenés után alkalmazásszerű, interaktív élményt kap.

A legfontosabb fogalmak

Fogalom	Jelentés
Szerveroldali renderelés	A HTML kérésenként, a szerveren készül el
Hidratálás	A böngészőben futó szkript a kész HTML-hez rendeli az eseménykezelőket és az állapotot
Statikus generálás	A HTML a közzétételkor, előre készül el, nem kérésenként
Időszakos újragenerálás	Az előre generált oldalak meghatározott feltételek szerint újra elkészülnek
Streaming renderelés	A szerver darabokban küldi a HTML-t, amint egy-egy rész elkészül
Kiinduló HTML	A szerver válasza, még a szkriptek lefutása előtt

Szerveroldali, kliensoldali, statikus

A három renderelési mód közötti különbség az, hogy hol és mikor készül el a HTML. A kliensoldali renderelésnél a látogató böngészőjében, minden betöltéskor. A statikus generálásnál a build folyamatban, egyszer. A szerveroldali renderelésnél a szerveren, minden kérésre. A szerveroldali és a statikus megoldás SEO szempontból hasonló eredményt ad, mert mindkettőnél a kiinduló HTML tartalmazza a tartalmat. A különbség a frissességben és a szerver terhelésében van: a szerveroldali renderelés mindig a legfrissebb adatot mutatja, de minden kérés számítási munkát jelent.

Kinek érdemes szerveroldali renderelést választania?

A szerveroldali renderelés elsősorban azoknak a webhelyeknek hasznos, amelyek JavaScript-alapú keretrendszerre épülnek, és amelyeknek a nyilvános oldalai keresésből várnak látogatókat. Ilyenek a webáruházak, a hírportálok, az álláshirdetési és ingatlanoldalak, valamint minden olyan tartalmas webhely, ahol az adatok gyakran változnak. Egy hagyományos tartalomkezelő rendszerre épülő oldal eleve a szerveren állítja elő a HTML-t, így ott a kérdés fel sem merül. Egy tisztán belső használatú alkalmazásnál pedig a szerveroldali renderelés többletköltsége ritkán térül meg.

Hogyan működik?

A szerveroldali renderelés egy kérés-válasz ciklus, amelynek minden lépése a szerveren zajlik, mielőtt a böngésző bármit kapna. Ezt követi a böngészőben a hidratálás, amely az oldalt interaktívvá teszi.

A kérés útja

A kérés beérkezik. A böngésző vagy a robot lekéri az URL-t.
Útválasztás. A szerver meghatározza, melyik oldalsablon tartozik az URL-hez.
Adatlekérés. A szerver lekéri a szükséges adatokat, például egy adatbázisból vagy egy belső programozási felületről.
Renderelés. Az alkalmazáskód az adatokból előállítja a HTML-t, benne a címmel, a meta adatokkal és a linkekkel.
Válasz. A szerver elküldi a kész HTML-t a megfelelő státuszkóddal.
Hidratálás. A böngésző megjeleníti a tartalmat, letölti a szkripteket, és azok a kész HTML-re építve interaktívvá teszik az oldalt.

Mit lát a kereső?

A Googlebot a lekéréskor megkapja a teljes HTML-t. A tartalom, a belső linkek, a canonical, a meta robots és a strukturált adatok már ekkor rendelkezésre állnak. A Google a JavaScriptes oldalakat renderelési szakaszban is feldolgozza, de szerveroldali renderelésnél a renderelés már nem ad hozzá lényeges tartalmat, csak megerősíti azt, ami a kiinduló HTML-ben volt. Így a renderelési sorban való várakozás és a renderelés közbeni hibák kockázata jelentősen csökken. Azok a robotok is látják a tartalmat, amelyek egyáltalán nem futtatnak JavaScriptet.

A státuszkódok szerepe

A szerveroldali renderelés egyik kevésbé emlegetett előnye, hogy a szerver a tartalom ismeretében válaszol, így helyes státuszkódot tud adni. Ha egy termék nem létezik, a szerver 404-et küldhet, ha egy oldal átkerült, 301-es átirányítást, ha pedig az adatforrás nem érhető el, 5xx hibát. A kliensoldali alkalmazásoknál ez gyakran nehézkes, mert a szerver minden címre ugyanazt a vázat küldi 200-as kóddal. A státuszkódok jelentéséről a HTTP státuszkódok útmutató ír.

A hidratálás ára

A hidratálás során a böngészőnek le kell töltenie és le kell futtatnia ugyanazt az alkalmazáskódot, amely a szerveren a HTML-t előállította. Amíg ez nem fejeződik be, az oldal látszik, de nem minden eleme reagál. Ha a JavaScript mennyisége nagy, ez az időszak hosszú lehet, és az interakciókra adott válasz késhet. A szerveroldali renderelés tehát a tartalom megjelenését gyorsítja, a JavaScript mennyiségét viszont önmagában nem csökkenti.

Fő módszerek

A szerveroldali renderelés nem egyetlen technika, hanem egy megközelítés, amelynek több változata van. A megfelelő változat a tartalom frissülési gyakoriságától, a forgalomtól és a technikai környezettől függ.

1. Klasszikus kérésenkénti renderelés

Minden kérésre a szerver újra előállítja a HTML-t. Ez a legfrissebb tartalmat adja, és jól illik a gyakran változó oldalakhoz, például a készletet és árat mutató termékoldalakhoz vagy a friss híreket tartalmazó nyitóoldalakhoz. Hátránya a szerver terhelése és az, hogy a válaszidő az adatlekérés és a renderelés idejétől függ.

2. Szerveroldali renderelés gyorsítótárral

A renderelt HTML eltárolható a szerveren vagy egy CDN peremszerverén, és a következő kérések ezt kapják, amíg a tárolt változat érvényes. Ez a kérésenkénti renderelés frissességét és a statikus fájlok gyorsaságát ötvözi. A kulcskérdés az érvénytelenítés: mikor kell a tárolt változatot eldobni. A gyorsítótárazás módjairól a cache útmutató ír.

3. Statikus generálás és időszakos újragenerálás

Ha a tartalom ritkán változik, a legjobb megoldás gyakran nem is a kérésenkénti renderelés, hanem a statikus generálás. A HTML a közzétételkor elkészül, és fájlként szolgálják ki. Több keretrendszer támogatja, hogy az előre generált oldalak meghatározott feltételek szerint újra elkészüljenek, így a frissesség és a sebesség is biztosítható.

4. Streaming renderelés

A streaming renderelésnél a szerver nem várja meg, hogy az egész oldal elkészüljön, hanem darabokban küldi. Az oldal fejléce és a gyorsan elérhető tartalom azonnal elindul, a lassabb részek később érkeznek. Ez rövidítheti az első megjelenés idejét. SEO szempontból arra kell figyelni, hogy a lényegi tartalom ne olyan részben legyen, amely csak kliensoldali lekérés után töltődik be.

5. Vegyes megoldás útvonalanként

A modern keretrendszerek többsége lehetővé teszi, hogy útvonalanként eltérő renderelési módot válasszunk. A nyilvános tartalomoldalak statikusak, a termékoldalak szerveroldaliak, a bejelentkezés mögötti felület kliensoldali. Ez gyakran a legjobb egyensúly a SEO, a sebesség és a fejlesztési költség között.

Döntési szabály

Az oldal célja a keresési forgalom? Ha igen, a tartalom legyen a kiinduló HTML-ben, szerveroldali vagy statikus módon.
A tartalom ritkán változik? Statikus generálás, szükség esetén időszakos újragenerálással.
Gyakran változik, és minden látogatónak ugyanaz? Szerveroldali renderelés gyorsítótárral.
Kérésenként eltér, például személyre szabott? Kérésenkénti renderelés, a személyes részek esetleg kliensoldalon.
Nem kell a keresőbe? A kliensoldali renderelés is megfelelő.

Kidolgozott példa: egy hírportál átállása

Egy hírportál kliensoldali alkalmazásként működött. A cikkek a böngészőben töltődtek be egy programozási felületről, a közösségi oldalakon megosztott linkek előnézete pedig gyakran üres volt, mert a megosztási kép és a cím csak szkripttel került be. A csapat a cikkoldalakat szerveroldali renderelésre állította át, rövid ideig érvényes gyorsítótárral a CDN-en. A friss hír közzétételekor az érintett oldalak gyorsítótárát érvénytelenítették. Az átállás után a kiinduló HTML tartalmazta a címet, a leadet, a cikk szövegét, a szerzőt és a strukturált adatot, a megosztási előnézetek helyesen jelentek meg, és a nem létező cikkek valódi 404-et adtak.

Gyakori hibák

A szerveroldali renderelés sok JavaScript SEO problémát megold, de saját hibalehetőségeket hoz. Ezek egy része a keresőt érinti, más része a sebességet vagy a szerver stabilitását.

Tipikus hibák

Csak a váz szerveroldali. A szerver a fejlécet és a menüt rendereli, a lényegi tartalom viszont továbbra is kliensoldalon töltődik be. A kiinduló HTML-ben így éppen az hiányzik, ami a legfontosabb.
Eltérés a szerver és a kliens között. Ha a szerveren és a böngészőben más HTML jön létre, a hidratálás hibára futhat, és az oldal tartalma a betöltés után megváltozhat.
Lassú válaszidő. Ha a renderelés lassú adatforrásokra vár, a szerver válaszideje megnő, ami a látogatónak és a feltérképezésnek is rossz.
Hiányzó gyorsítótár. Minden kérés teljes renderelést indít, ami forgalmi csúcsokon túlterhelheti a szervert, és 5xx hibákhoz vezethet.
Hibás státuszkód. A szerver renderel, de a nem létező oldalra mégis 200-at ad egy hibaüzenettel.
Személyes adat a gyorsítótárban. Ha személyre szabott tartalom kerül egy közös gyorsítótárba, más látogatók is megkaphatják.
Túl sok JavaScript a hidratáláshoz. A tartalom gyorsan látszik, de az oldal sokáig nem reagál.

Tévhit: a szerveroldali renderelés rangsorolási előny

A renderelési mód önmagában nem rangsorolási tényező. A szerveroldali renderelés azért hasznos, mert csökkenti annak kockázatát, hogy a kereső hiányos tartalmat lát, és mert gyorsíthatja a tartalom megjelenését. Ha egy kliensoldali oldal tartalmát a Google hibátlanul rendereli és indexeli, a szerveroldali átállás önmagában nem hoz jobb helyezést. Az előny a megbízhatóságban és a sebességben van, nem egy külön jelzésben.

Ellenpélda: gyorsabb megjelenés, lassabb reakció

Egy webáruház szerveroldali renderelésre váltott, és a termékoldalak tartalma valóban hamarabb megjelent. A valós felhasználói adatokban viszont az interakciókra adott válaszidő romlott. Az ok az volt, hogy a hidratáláshoz a böngészőnek továbbra is az egész alkalmazás kódját le kellett töltenie és futtatnia, és közben a látogatók már kattintottak. A javítás a JavaScript mennyiségének csökkentése volt: kódfelosztás, a nem interaktív részek hidratálásának elhagyása, és a harmadik féltől származó szkriptek későbbre ütemezése.

Mérés

A szerveroldali renderelés mérésekor három dolgot kell ellenőrizni: a kiinduló HTML tartalmazza-e a lényeget, a szerver elég gyorsan válaszol-e, és a hidratálás nem rontja-e az interaktivitást.

A kiinduló HTML ellenőrzése

A legegyszerűbb próba egy parancssori lekérés, például curl, vagy a böngésző forráskód-nézete. Ha a lényegi szöveg, a belső linkek, a cím, a meta leírás, a canonical és a strukturált adat itt megjelenik, a szerveroldali renderelés a keresők szempontjából teljesíti a feladatát. A Search Console URL-ellenőrzője mutatja a renderelt változatot, és a kettő összevetése kideríti, változtat-e a szkript valamin a betöltés után.

Válaszidő

A szerver válaszideje a szerveroldali renderelés legfontosabb teljesítménymutatója. A böngésző fejlesztői eszközeiben az első bájt megérkezéséig eltelt idő látszik, a Search Console feltérképezési statisztikái pedig a Googlebot által mért átlagos válaszidőt mutatják. Ha ez romlik, érdemes a gyorsítótárazást és a lassú adatforrásokat vizsgálni. A válaszidő a crawl budgetre is hatással van.

Valós felhasználói adatok

A Search Console Core Web Vitals jelentése és a saját valós felhasználói mérés mutatja meg, hogyan élik meg a látogatók az oldalt. A szerveroldali renderelés általában a tartalom megjelenését, az LCP mutatót javítja, a hidratálás pedig az INP mutatót befolyásolja. Mindkettőt érdemes átállás előtt és után is rögzíteni.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó jel
Tartalom a kiinduló HTML-ben	curl, forráskód-nézet	A lényegi szöveg és a linkek megjelennek
Meta jelzések	Forráskód és URL-ellenőrző	Cím, canonical, robots egyezik a két állapotban
Státuszkódok	Nem létező és átkerült URL lekérése	404, illetve 301, nem 200
Válaszidő	Fejlesztői eszközök, feltérképezési statisztikák	Stabil, nem romló
Hidratálás	Böngészőkonzol, teljesítménypanel	Nincs eltérési hiba, rövid a fő szál foglaltsága
Gyorsítótár	Válaszfejlécek	Közös tartalom tárolva, személyes nem

Kidolgozott példa: átállás utáni ellenőrzés

Egy szolgáltatói webhely kliensoldali rendereléséről szerveroldalira váltott. Az átállás előtt rögzítették a fontos sablonok kiinduló HTML-jét, a Googlebot átlagos válaszidejét és a Core Web Vitals értékeit. Az átállás után sablononként curl-lel ellenőrizték, hogy a tartalom és a linkek a kiinduló HTML-ben vannak, lekértek néhány nem létező URL-t a státuszkódok miatt, és a böngészőkonzolban hidratálási hibákat kerestek. Egy sablonnál eltérést találtak: a dátumot a szerver és a böngésző más időzónában írta ki, ami hidratálási figyelmeztetést okozott. A javítás után a következő hetekben a feltérképezési statisztikákban a válaszidő stabil maradt, a valós felhasználói adatokban pedig javult a fő tartalom megjelenése.