Client-side rendering: teljes útmutató

A client-side rendering, magyarul kliensoldali renderelés, az a megoldás, amikor a szerver csak egy vázszerű HTML-t és JavaScript-fájlokat küld, az oldal tartalmát pedig a látogató böngészője állítja elő a szkriptek lefuttatásával. SEO szempontból ez azt jelenti, hogy a kereső csak renderelés után látja a tartalmat, ezért a keresésből elérendő oldalaknál külön figyelmet igényel.

Alapfogalmak

A kliensoldali renderelés a modern webalkalmazások egyik alapmodellje. A szerver nem kész oldalt küld, hanem egy kiinduló HTML-dokumentumot, amelyben jellemzően egyetlen üres gyökérelem és néhány szkripthivatkozás szerepel. A böngésző letölti a szkripteket, lefuttatja őket, a szkript lekéri az adatokat egy programozási felületről, és ezekből építi fel az oldal elemeit. A látogató csak a folyamat végén látja a tényleges tartalmat.

Ezt a megközelítést leggyakrabban az egyoldalas alkalmazások, angolul single page application, használják. Ezeknél az első betöltés után a böngésző nem kér le új HTML-oldalt minden navigációnál, hanem a szkript cseréli ki a képernyő tartalmát, és a History API segítségével frissíti a címsorban látható URL-t. A látogató számára ez gyors, alkalmazásszerű élményt adhat, a keresők számára viszont minden tartalom a szkript lefutásától függ.

A kliensoldali renderelés és rokonai

Megközelítés	Ki állítja elő a HTML-t?	Mikor?
Kliensoldali renderelés	A látogató böngészője	Minden betöltéskor, a szkriptek lefutása után
Szerveroldali renderelés	A szerver	Kérésenként, a válasz előtt
Statikus generálás	A build folyamat	Közzétételkor, egyszer
Előrenderelés	Egy külön szolgáltatás vagy build lépés	Előre, a kliensoldali alkalmazás futtatásával

Mikor elfogadható a kliensoldali renderelés?

A kliensoldali renderelés önmagában nem hiba. Bejelentkezés mögötti felületeknél, vezérlőpultoknál, szerkesztőknél és minden olyan alkalmazásrésznél, amelynek nem kell a keresőben megjelennie, teljesen megfelelő választás lehet. A kérdés mindig az, hogy az adott oldal célja-e, hogy keresésből látogatókat hozzon. Ha igen, a kliensoldali renderelés kockázatot jelent, amelyet vagy kezelni kell, vagy más renderelési módot kell választani.

A JavaScript SEO tágabb keretében

A kliensoldali renderelés a JavaScript SEO legfontosabb részterülete, mert itt a legnagyobb a különbség a kiinduló és a renderelt HTML között. Egy hagyományos oldalon a JavaScript csak kiegészít, itt viszont minden rajta múlik.

Kiinduló és renderelt HTML

A kliensoldali renderelés megértéséhez két állapotot kell megkülönböztetni. A kiinduló HTML az, amit a szerver elküld, és amit a böngésző forráskód-nézete mutat. A renderelt HTML az, ami a szkriptek lefutása után a böngészőben kialakul, és amit a fejlesztői eszközök elemvizsgálója mutat. Egy hagyományos oldalon a kettő szinte azonos. Kliensoldali renderelésnél a kiinduló HTML-ben gyakran csak a cím, néhány meta elem és a szkripthivatkozások szerepelnek, a renderelt HTML-ben viszont ott a teljes tartalom. Minden SEO-vizsgálat azzal kezdődik, hogy megnézzük, a két állapot közül melyikben mi található, és melyiket látja az adott robot.

Hogyan működik?

A kliensoldali renderelés folyamata egy látogató böngészőjében több lépésből áll, és mindegyik lépés ideje hozzáadódik ahhoz, amíg a tartalom megjelenik. A kereső hasonló lépéseken megy végig, csak a saját renderelő motorjában.

A betöltés lépései

A HTML letöltése. A szerver gyorsan válaszol, mert csak egy kis vázat küld.
A szkriptek letöltése. A böngésző lekéri az alkalmazás JavaScript-csomagjait, amelyek jóval nagyobbak lehetnek a HTML-nél.
A szkriptek feldolgozása és futtatása. A böngésző értelmezi és lefuttatja a kódot, ami a fő szálat foglalja.
Az adatok lekérése. Az alkalmazás egy programozási felülettől kéri le a megjelenítendő adatokat.
A felület felépítése. A szkript létrehozza az oldal elemeit, és a tartalom megjelenik.

A lépések egymásra épülnek: az adatok lekérése csak akkor indul, amikor a szkript már fut, a szkript pedig csak akkor fut, amikor letöltődött. Ez a lánc az oka annak, hogy a kliensoldali renderelésű oldalak első megjelenése gyakran lassabb, mint a szerveren előállított oldalaké, különösen gyengébb eszközön és lassú kapcsolaton.

Mit lát a kereső?

A Googlebot a lekéréskor a kiinduló HTML-t kapja meg, amelyben a kliensoldali renderelés esetén alig van tartalom. A Google ezután a renderelési szakaszban lefuttatja a JavaScriptet, és a renderelt állapotot használja az indexeléshez. Ha minden erőforrás elérhető, és a kód hibátlanul lefut, a Google jó eséllyel látja a tartalmat. A kockázat abban van, ami közben elromolhat: tiltott erőforrások, időtúllépés, szkripthibák, olyan adatlekérés, amely a robot számára nem érhető el, vagy tartalom, amely csak interakcióra jelenik meg.

Útválasztás egyoldalas alkalmazásban

Az egyoldalas alkalmazásoknál az útválasztás a böngészőben történik. Ha az alkalmazás a History API-t használja, minden nézetnek valódi URL-je van, amelyet közvetlenül is le lehet kérni, és a szervernek ezekre a címekre is ki kell szolgálnia az alkalmazást. Ha az alkalmazás kettőskeresztes útvonalakat használ, a Google a kettőskereszt utáni részt nem kezeli külön oldalként, így a nézetek nem indexelhetők külön.

Kidolgozott példa: egy termékoldal útja

Egy kliensoldali renderelésű webáruházban a látogató egy keresési találatról érkezik egy termékoldalra. A szerver visszaadja a vázat, a böngésző letölti az alkalmazás fő csomagját, amely a teljes webáruház kódját tartalmazza. A szkript lefut, lekéri a termék adatait, majd megjeleníti a nevet, az árat, a képet és a leírást. A fő termékkép csak ekkor kezd letöltődni, mert addig a böngésző nem is tudott róla. A Search Console URL-ellenőrzőjében a renderelt oldal helyes, a valós felhasználói adatokban viszont a termékoldalak betöltési ideje lassúnak mutatkozott. A csapat először kódfelosztást vezetett be, hogy a termékoldal csak a saját kódját töltse le, később pedig a termékoldalakat szerveroldali renderelésre állította át.

Fő módszerek

Ha egy webhely kliensoldali rendereléssel működik, és a keresésből is forgalmat vár, több út áll rendelkezésre. Az egyik irány a kockázatok csökkentése a kliensoldali modellen belül, a másik a renderelés részleges vagy teljes áthelyezése a szerverre vagy a build folyamatba.

1. A nyilvános oldalak kiemelése a kliensoldali modellből

A leghatékonyabb megoldás gyakran az, hogy a keresésből elérendő oldalak, például a termék-, kategória- és tartalomoldalak, szerveroldali rendereléssel vagy statikus generálással készülnek, míg a bejelentkezés mögötti részek kliensoldaliak maradnak. A modern keretrendszerek többsége támogatja, hogy útvonalanként eltérő renderelési módot válasszunk.

2. Előrenderelés

Az előrenderelés során egy build lépés vagy külön eszköz lefuttatja az alkalmazást a kiválasztott URL-ekre, és elmenti az eredményül kapott HTML-t. Ezt a fájlt kapja minden látogató és robot, a szkript pedig utána veszi át az irányítást. Ez jól működik viszonylag állandó tartalmú oldalaknál, de gyakran változó adatoknál a mentett HTML elavulhat.

3. Valódi linkek, valódi URL-ek, valódi státuszkódok

Linkek: minden navigáció legyen <a href> elem, valódi URL-lel, akkor is, ha a kattintást a szkript kezeli.
URL-ek: History API alapú útválasztás, kettőskeresztes útvonalak nélkül.
Státuszkódok: a nem létező nézetekre ne 200-as üres oldal jöjjön. Ha a szerver nem tud 404-et adni, a szkript irányítson át egy 404-es URL-re, vagy tegyen noindexet az oldalra, hogy elkerülje a soft 404 helyzetet.

4. A betöltési lánc rövidítése

A kliensoldali renderelés sebességét a JavaScript mennyisége és a lépések sorrendje határozza meg. A kódfelosztás azt jelenti, hogy minden útvonal csak a saját kódját tölti le. A kritikus adatok lekérése korábban indítható, a fő kép pedig jelezhető a böngészőnek, hogy ne a szkript lefutására várjon. A preload és a prefetch ebben segíthet.

5. Meta adatok helyes kezelése

A cím, a meta leírás, a canonical és a robots jelzések kliensoldali alkalmazásban gyakran szkripttel kerülnek be. A Google a renderelt állapotot olvassa, de a noindex esetében a kiinduló HTML is számít, és más robotok csak azt látják. A legbiztosabb, ha ezek a jelzések már a szerver válaszában helyesek.

Döntési szabály

Az oldal célja, hogy keresésből látogatót hozzon? Ha nem, a kliensoldali renderelés megfelelő.
Ha igen, és a tartalom ritkán változik: előrenderelés vagy statikus generálás.
Ha igen, és a tartalom gyakran változik: szerveroldali renderelés az adott útvonalakra.
Ha az átállás rövid távon nem lehetséges: legalább a linkek, az URL-ek, a státuszkódok és a meta adatok legyenek rendben, és a renderelést rendszeresen ellenőrizni kell.

Gyakori hibák

A kliensoldali renderelés hibái két csoportba sorolhatók. Az egyik csoport a keresőt érinti: a tartalom, a linkek vagy a jelzések nem jutnak el hozzá. A másik a sebességet: a látogató túl sokáig vár, amíg a tartalom megjelenik vagy az oldal reagál.

Tipikus hibák

Üres kiinduló HTML nyilvános oldalakon. A tartalom csak renderelés után létezik, és ha a renderelés hibázik, a kereső üres oldalt lát.
Eseménykezelős navigáció. A href nélküli linkeket a robot nem követi, így a belső linkstruktúra láthatatlan.
Tiltott adatvégpontok. Ha az adatokat szolgáltató felület tiltva van a robots.txt-ben, a renderelt oldal hiányos.
Egyetlen óriási JavaScript-csomag. Minden oldal letölti az egész alkalmazás kódját, ami lassítja az első megjelenést.
Mindenre 200-as válasz. A nem létező nézetek soft 404-ként kerülnek a kereső elé.
Interakcióhoz kötött tartalom. A csak kattintásra betöltődő leírás vagy vélemény a robot számára nem létezik.
Hiányzó hibakezelés. Ha az adatlekérés sikertelen, a szkript üres felületet hagy, amelyet a robot is üresnek lát.

Tévhit: a Google úgyis rendereli, tehát nincs gond

A Google valóban rendereli a JavaScriptet, de a renderelés egy további lépés, amely erőforrást igényel, és amelyben több dolog elromolhat. A renderelés sikere nem garantált minden oldalon és minden időpontban. Ráadásul más keresők és feldolgozó rendszerek nem feltétlenül renderelnek. A kliensoldali renderelés tehát nem tiltott, de nem is kockázatmentes, és a keresésből elérendő oldalakon ezért érdemes a kiinduló HTML-re is építeni.

Ellenpélda: az üres lista

Egy álláshirdetési oldal listaoldalai kliensoldalon kérték le a hirdetéseket. A fejlesztők a lekérést úgy írták meg, hogy ha a felhasználó nem fogadta el a sütiket, a szkript egy üres listát jelenített meg, és a hirdetések helyett egy tájékoztatót. A robot nem fogad el sütiket, így minden listaoldalt üresnek látott. A böngészőben tesztelő csapat ezt nem vette észre, mert ők korábban már elfogadták a sütiket. A hiba az URL-ellenőrző képernyőképén derült ki, a javítás pedig az volt, hogy a hirdetések megjelenítése független lett a sütiválasztástól.

A sebesség mint rejtett hiba

A kliensoldali renderelés sebességi problémái a Core Web Vitals mutatóiban jelentkeznek. A legnagyobb tartalmi elem megjelenése, az LCP, késhet, mert a fő tartalom a szkriptre és az adatokra vár. A sok JavaScript a fő szálat is terheli, ami az interakciókra adott válaszidőt, az INP mutatót ronthatja.

Mérés

A kliensoldali renderelés mérésekor két kérdést kell külön vizsgálni: látja-e a kereső a tartalmat, és milyen gyorsan kapja meg a valós látogató. Az első a renderelés helyességéről, a második a teljesítményről szól.

A kereső nézőpontja

A Search Console URL-ellenőrzőjében az élő teszt megmutatja a renderelt HTML-t, a képernyőképet, a betöltött és a be nem tölthető erőforrásokat, valamint a JavaScript-konzol üzeneteit. Ellenőrizni kell, hogy a lényegi tartalom, a belső linkek és a meta jelzések megjelennek-e. Egy további egyszerű próba: a böngésző fejlesztői eszközeiben kikapcsolni a JavaScriptet, és megnézni, mi marad az oldalból. Ez azt mutatja meg, mit látnak a renderelést nem végző robotok.

A látogató nézőpontja

A Lighthouse és a böngésző teljesítménypanelje laboratóriumi körülmények között mutatja meg a betöltési láncot: mikor töltődik le a szkript, mennyi ideig fut, mikor érkeznek meg az adatok, és mikor jelenik meg a fő tartalom. A valós felhasználói adatok, például a Search Console Core Web Vitals jelentése, azt mutatják meg, hogyan élik ezt meg a látogatók a saját eszközeiken.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó jel
Renderelt tartalom	URL-ellenőrző élő teszt	A teljes tartalom látszik a renderelt HTML-ben és a képernyőképen
Linkek	Renderelt HTML	Minden navigáció a href elem, valódi URL-lel
Erőforrások	URL-ellenőrző, robots.txt	Nincs be nem tölthető szkript vagy adatvégpont
Nem létező URL	Közvetlen lekérés	404 vagy noindex
JavaScript nélkül	Fejlesztői eszközök	A nyilvános oldalakon a lényegi tartalom megmarad
Sebesség	Lighthouse, Core Web Vitals jelentés	A fő tartalom nem vár feleslegesen a szkriptre

Kidolgozott példa: sablonszintű mérés

Egy utazási oldal minden úti cél oldalát kliensoldalon renderelte. A mérést sablononként végezték: minden oldaltípusból kiválasztottak néhány URL-t, és mindegyiket megvizsgálták az URL-ellenőrzővel, JavaScript nélkül és a Lighthouse-szal. Az úti cél oldalakon a renderelt tartalom helyes volt, de a JavaScript nélküli nézet teljesen üres maradt, és a fő kép későn jelent meg. A csapat ezeket az oldalakat statikus generálásra állította át, a foglalási felület kliensoldali maradt. Az átállás után a JavaScript nélküli nézetben is megjelent a szöveg és a navigáció, és a valós felhasználói adatokban javult a fő tartalom megjelenésének ideje.