Dynamic rendering: teljes útmutató

A dynamic rendering, magyarul dinamikus renderelés, azt jelenti, hogy a szerver felismeri a keresőrobotokat, és nekik egy előre lerenderelt, statikus HTML-változatot küld, míg a látogatók a megszokott, JavaScript-alapú oldalt kapják. Ez egy átmeneti kerülőmegoldás a JavaScript-függő oldalak indexelési gondjaira. A Google maga sem javasolja hosszú távú megoldásként: ahol lehet, szerveroldali vagy statikus renderelés a jobb út.

Alapfogalmak

A dinamikus renderelés megértéséhez először azt kell tisztázni, mit jelent a renderelés. Egy modern, JavaScript-alapú webhelyen a szerver gyakran csak egy üres vázat küld, és a tényleges tartalmat a böngészőben futó szkript rakja össze. Ezt a folyamatot hívjuk renderelésnek. A látogató ebből semmit nem érzékel, a keresőrobot viszont nehezebb helyzetben van: ha nem futtatja le a JavaScriptet, vagy csak később teszi meg, akkor az első lekéréskor alig lát tartalmat.

A dinamikus renderelés erre a gondra ad egy kétsávos választ. A szerver megnézi, ki kéri az oldalt. Ha a kérés egy ismert keresőrobottól vagy közösségimédia-előnézetet készítő robottól jön, akkor egy olyan HTML-t kap, amelyben a tartalom már ki van töltve. Ha egy átlagos böngészőtől jön, akkor a megszokott kliensoldali alkalmazás töltődik be. A két változat tartalmában azonosnak kell lennie, csak az előállítás módja különbözik.

Fontos elhatárolni a dinamikus renderelést a cloakingtól. A cloaking azt jelenti, hogy a kereső és a látogató érdemben más tartalmat lát, például a robot kulcsszavakkal teletömött szöveget kap. Ez irányelvsértés. A dinamikus renderelés akkor elfogadható, ha a robot ugyanazt a tartalmat kapja, csak kész formában. A Google dokumentációja ezt a határt általánosságban így írja le, a konkrét megítélés pedig mindig a tényleges eltéréstől függ.

A módszer ma már inkább örökölt megoldásnak számít. A Google korábban ajánlotta a JavaScript-nehéz oldalaknak, később a dokumentációjában kerülőmegoldásnak minősítette, és a szerveroldali renderelést, a statikus generálást vagy a hidratálást javasolja helyette. Ettől még sok webhelyen fut, ezért érdemes pontosan érteni.

A legfontosabb fogalmak

Fogalom	Jelentés
Dinamikus renderelés	A robot előre lerenderelt HTML-t kap, a látogató a kliensoldali alkalmazást
Előrenderelés (prerender)	Az oldal HTML-jének előállítása egy fej nélküli böngészővel, a kérés előtt vagy közben
Fej nélküli böngésző	Grafikus felület nélkül futó böngésző, amely lefuttatja a JavaScriptet
User-agent	A kérést küldő program azonosító szövege, erre épül a robotfelismerés
Cloaking	Érdemben eltérő tartalom a robotnak és a látogatónak, irányelvsértés
Kiinduló HTML	Amit a szerver elsőre visszaküld, JavaScript futtatása nélkül

Hogyan működik?

A dinamikus renderelés három szereplőre épül: a webszerverre vagy egy elé helyezett köztes rétegre, egy renderelő szolgáltatásra és egy gyorsítótárra. A kérés útja a következő. Beérkezik egy lekérés, a köztes réteg megvizsgálja a user-agent fejlécet, és eldönti, hogy robotról vagy emberről van szó. Emberi látogatónál a kérés változatlanul megy tovább az alkalmazáshoz. Robotnál a köztes réteg a renderelő szolgáltatáshoz fordul.

A renderelő szolgáltatás egy fej nélküli böngészőben megnyitja az adott URL-t, lefuttatja a JavaScriptet, megvárja, amíg a tartalom betöltődik, majd a kész DOM-ot HTML-ként visszaadja. Ez lassú és erőforrás-igényes művelet, ezért szinte minden megvalósítás gyorsítótárba teszi az eredményt. A következő robotlekérés már a tárolt változatot kapja, egészen addig, amíg az le nem jár vagy valaki ki nem üríti.

A folyamat kényes pontja a várakozás. A renderelőnek tudnia kell, mikor kész az oldal. Ha túl korán menti el a HTML-t, a lassan érkező adatok, például a terméklista vagy az árak, kimaradnak belőle. Ha túl sokáig vár, a robot válaszideje megnő, ami ronthatja a feltérképezés hatékonyságát. A legtöbb megoldásban beállítható egy időkorlát, vagy az alkalmazás jelezheti, hogy elkészült.

A kérés útja lépésről lépésre

Beérkezik a kérés egy URL-re.
A köztes réteg a user-agent alapján robotot vagy embert azonosít.
Embernél az alkalmazás a szokásos vázat és szkripteket küldi.
Robotnál a réteg megnézi, van-e érvényes tárolt változat.
Ha van, azonnal visszaküldi, ha nincs, a renderelő elkészíti és eltárolja.
A robot kész HTML-t kap, benne a tartalommal, a linkekkel és a meta jelzésekkel.

Érdemes észben tartani, hogy a robot a kész HTML mellett a helyes HTTP státuszkódot is várja. Ha egy nem létező termékoldal a látogatónak hibaüzenetet mutat, de a renderelt változat 200-as kóddal megy ki, a kereső egy tartalom nélküli oldalt indexelhet. A renderelő rétegnek ezért a státuszkódot is az alkalmazás logikájához kell igazítania.

Hasonló a helyzet az átirányításokkal. Egy kliensoldali alkalmazás gyakran JavaScripttel irányít át egy régi útvonalról az újra, a renderelő pedig ilyenkor vagy a régi URL alatt menti el az új oldal tartalmát, vagy egy félkész állapotot rögzít. A tiszta megoldás az, ha a köztes réteg szerveroldali 301-es átirányítást küld a robotnak, még a renderelés előtt. Ugyanez a logika érvényes a nyelvi és regionális változatokra: ha az alkalmazás a böngésző nyelve alapján vált tartalmat, a renderelőnek rögzített beállítással kell dolgoznia, különben a robot véletlenszerűen hol az egyik, hol a másik nyelvet kapja ugyanazon az URL-en. Végül a renderelt HTML-ből érdemes eltávolítani a felesleges szkripteket, de csak óvatosan, mert a strukturált adatot tartalmazó blokkoknak benne kell maradniuk.

Fő módszerek

A dinamikus renderelést többféleképpen lehet megvalósítani, és a választás főleg azon múlik, mennyi fejlesztői kapacitás áll rendelkezésre, és mennyi oldalról van szó. Az alábbiakban a jellemző megközelítéseket vesszük sorra, általános szinten, konkrét termékek nélkül.

Az első a saját üzemeltetésű renderelő. Ilyenkor a csapat maga állít be egy fej nélküli böngészőt futtató szolgáltatást, és a webszerver vagy a terheléselosztó ehhez irányítja a robotkéréseket. Előnye a teljes kontroll, hátránya, hogy a renderelő szervereket üzemeltetni, frissíteni és méretezni kell. Nagy forgalmú webhelyen a robotlekérések száma meglepően magas lehet.

A második a külső, szolgáltatásként igénybe vett előrenderelés. A webhely egy köztes kódrészlettel továbbítja a robotkéréseket egy külső szolgáltatóhoz, amely visszaadja a kész HTML-t és tárolja is. Ez gyorsan bevezethető, viszont függést teremt egy harmadik féltől, és a tárolt változatok frissességét is az ő beállításai határozzák meg.

A harmadik a peremhálózati megoldás, amikor a robotfelismerés és a tárolt változat kiszolgálása egy CDN szintjén történik. Ez csökkenti a válaszidőt, de a hibakeresés nehezebb, mert a logika több rétegben él.

Döntési szabály: mikor melyik megoldás?

Helyzet	Javasolt irány
Új projekt, szabad a keretrendszer választása	Ne dinamikus renderelés, hanem szerveroldali vagy statikus generálás
Meglévő kliensoldali alkalmazás, az átírás hónapokig tartana	Átmeneti dinamikus renderelés, mellette ütemezett átállás
Kevés, ritkán változó oldal	Statikus előrenderelés build időben, robotfelismerés nélkül
Sok, gyakran változó oldal, kicsi fejlesztői csapat	Külső előrenderelő szolgáltatás, szigorú frissítési szabályokkal
Saját infrastruktúra, erős üzemeltetés	Saját renderelő, gyorsítótárral és monitorozással

A saját tapasztalatunkból leszűrt szabály egyszerű: ha a dinamikus renderelés bevezetése és az átállás a szerveroldali renderelésre nagyjából azonos munka, mindig az átállást válaszd. A dinamikus renderelés két külön rendszert jelent, amelyeket ezután folyamatosan szinkronban kell tartani, és ennek a költsége hónapról hónapra jelentkezik.

Bevezetési munkafolyamat, ha mégis dinamikus renderelés mellett döntesz

Sablononként listázd a fontos oldaltípusokat, és mindegyikhez válassz tesztoldalakat.
Rögzítsd, mit lát most a robot: mentsd el a kiinduló HTML-t és az URL-ellenőrző eredményét.
Állítsd be a robotlistát, és külön teszteld a közösségi előnézeteket készítő robotokat is.
Határozd meg a várakozási időt a leglassabb sablon alapján, nem az átlag alapján.
Kösd a gyorsítótár ürítését a tartalomkezelő mentési eseményéhez.
Élesítés előtt vesd össze a látogatói és a robotváltozatot minden tesztoldalon.
Írd le az átállás tervezett időpontját a tartós megoldásra, hogy az ideiglenes állapot ne váljon véglegessé.

Gyakori hibák

A dinamikus renderelés hibái ritkán látványosak. Az oldal a böngészőben hibátlanul működik, a fejlesztő nem lát semmi furcsát, közben a kereső egy hiányos vagy elavult változatot kap. Ezért a legtöbb gond csak hetekkel később, a forgalom vagy az indexelt oldalak számának csökkenésekor derül ki.

A leggyakoribb hiba az elavult gyorsítótár. A renderelt HTML napokig vagy hetekig is tárolva maradhat, miközben a valódi oldalon már új ár, új készletadat vagy új szöveg szerepel. A robot ilyenkor régi tartalmat indexel, ami rosszabb esetben a találati oldalon is látszik. A megoldás a tartalomváltozáshoz kötött ürítés, nem csak egy fix lejárati idő.

A második gyakori hiba a hiányos robotlista. Ha a köztes réteg csak néhány keresőrobotot ismer fel, a többi, például a közösségi oldalak előnézetét készítő robotok, üres vázat kap, és a megosztott linkek kép és leírás nélkül jelennek meg. Fordított hiba is előfordul: túl tág mintázat, amely emberi látogatókat is a renderelt változatra terel.

A harmadik a tartalmi eltérés. Ha a renderelt változatból kimarad egy szakasz, vagy a látogató mást lát, mint a robot, az a cloaking határát súrolja. Ide tartozik az is, amikor a renderelő sütibanner vagy bejelentkezési ablak mögött rögzíti az oldalt.

Hibák és javításuk

Hiba	Tünet	Javítás
Elavult tárolt változat	A találati oldalon régi ár vagy cím	Tartalomváltozáskor célzott ürítés
Túl korai mentés	Hiányzó lista vagy üres blokk a renderelt HTML-ben	Hosszabb várakozás vagy kész jelzés az alkalmazásból
Rossz státuszkód	Nem létező oldalak 200-as kóddal	404 és 301 átadása a renderelt válaszban
Hiányos robotlista	Megosztott link előnézet nélkül	A lista bővítése és rendszeres felülvizsgálata
Eltérő meta jelzések	Más canonical vagy robots a két változatban	A meta elemek összevetése minden sablonon
Blokkolt erőforrás	A renderelő nem éri el az API-t vagy a szkriptet	A robots.txt és a tűzfalszabályok ellenőrzése

Külön figyelmet érdemel a robots.txt. Ha a renderelő szolgáltatás egy olyan API-végpontot hívna, amelyet a robots.txt vagy egy tűzfalszabály letilt, a renderelt oldal hiányos lesz. Ugyanez igaz fordítva: a meta robots és az X-Robots-Tag jelzéseknek a renderelt változatban is pontosan úgy kell szerepelniük, ahogy a látogatói változatban.

Mérés

A dinamikus renderelés mérése lényegében egy összehasonlítás: ugyanazt az URL-t kétféleképpen kérjük le, és megnézzük, ugyanazt kapjuk-e. Az egyik lekérés böngészőként, a másik keresőrobotként azonosítja magát. A két válasz közötti eltérés mutatja meg, hol csúszott el valami.

Az első eszköz egy egyszerű parancssori lekérés, amelyben a user-agent fejlécet egy keresőrobotéra állítjuk. Így láthatjuk, mit küld a szerver a robotnak, és benne van-e a lényegi szöveg, a belső linkek, a cím és a canonical. A második a Search Console URL-ellenőrzője, amely megmutatja a Google által lekért és renderelt HTML-t. Ez azért fontos, mert a Google valódi robotja más IP-címről jön, így a user-agent utánzásánál megbízhatóbb képet ad. A harmadik a szervernapló, amelyből kiderül, milyen gyakran kérnek oldalakat a robotok, és a renderelt válaszok mennyi idő alatt mennek ki.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó jel
Tartalom a robotnak küldött HTML-ben	Lekérés robot user-agenttel	A lényegi szöveg és a linkek benne vannak
Egyezés a látogatói változattal	A két HTML szövegének összevetése	Azonos cím, szöveg, linkek
Google által látott változat	Search Console URL-ellenőrző	A renderelt HTML teljes
Státuszkódok	Nem létező URL lekérése robotként	404, nem 200
Frissesség	Egy frissen módosított oldal lekérése robotként	Az új tartalom jelenik meg
Válaszidő	Szervernapló, feltérképezési statisztikák	Stabil, nem romló

Kidolgozott példa: havi összevetés

Vegyünk egy képzeletbeli webáruházat, amely kliensoldali alkalmazáson fut, és átmenetileg dinamikus renderelést használ. A csapat havonta egyszer lefuttat egy egyszerű szkriptet: minden fő sablonból, azaz a főoldalból, egy kategóriából, egy termékből és egy blogcikkből kiválaszt öt-öt URL-t, és mindegyiket lekéri böngészőként és robotként is. A szkript mindkét válaszból kinyeri a címet, a canonicalt, a robots jelzést, a belső linkek számát és a látható szöveg szavainak számát, majd táblázatba írja a különbséget.

A döntési szabály: ha a szószám eltérése egy sablonon belül meghaladja a tíz százalékot, vagy bármelyik meta elem eltér, a sablont vizsgálatra jelölik. Az egyik futásnál a termékoldalak renderelt változatából hiányzott a vásárlói vélemények blokkja. Kiderült, hogy a vélemények egy lassú külső hívásból érkeztek, és a renderelő időkorlátja rövidebb volt ennél. A korlát emelése után a következő futásnál az eltérés eltűnt. A tíz százalékos küszöb a mi választásunk, nem iparági szabvány, a saját oldaladhoz érdemes hangolni.