Szerveroldali renderelés

A szerveroldali renderelés egy olyan megközelítés, amelyben a szerver generálja az oldal teljes jelölőkódját, és elküldi azt a böngészőnek, ahelyett, hogy egy minimális dokumentumot küldene, amelyet aztán JavaScript tölt fel. A böngésző értelmes tartalmat jeleníthet meg, amint a válasz megérkezik, anélkül, hogy egy csomagnak kellene letöltenie, elemeznie, végrehajtania és lekérnie az adatokat.

A tisztán kliensoldali renderelés specifikus és jól dokumentált gyengeségeit kezeli. A tartalom lényegesen hamarabb jelenik meg, különösen lassabb eszközökön és kapcsolatokon, ahol a JavaScript végrehajtása költséges. A keresőmotorok és más automatizált fogyasztók közvetlenül kapják meg a tartalmat, ahelyett, hogy egy olyan renderelési szakasztól függnének, amely késhet vagy hiányos lehet. A közösségi megosztás előnézetei speciális kezelés nélkül működnek. A felhasználói élmény pedig zökkenőmentesebben romlik, ha a JavaScript nem töltődik be vagy nem fut le, ami gyakrabban történik, mint a legtöbb csapat feltételezi.

A hidratáció az ezzel járó költség, amelyet gyakran alábecsülnek. Miután a szerver által renderelt jelölőkód megjelenik, a kliensoldali keretrendszernek eseménykezelőket kell csatolnia, és újra kell építenie belső állapotát, hogy az oldal interaktív legyen. Ez idő alatt az oldal készen áll, de nem válaszol, ami egy jellegzetes hibát okoz, ahol a látogató rákattint valami láthatóra, és semmi sem történik. Nagy oldalakon és lassabb eszközökön ez az ablak jelentős lehet.

Számos megközelítés született a költségek csökkentésére. A részleges és szelektív hidratálás csak az oldal interaktív részeit teszi interaktívvá, nem pedig az egészet. A streamelés fokozatosan küldi a jelölőnyelvet, így a tartalom a teljes oldal generálása előtt megjelenik. A szigetarchitektúrák az interaktív komponenseket elszigetelt egységekként kezelik az egyébként statikus jelölőnyelven belül. Mindegyik csökkenti a kliensoldali munka mennyiségét, amely a kezdeti renderelés után szükséges.

A statikus webhelygenerálás az elsődlegesen megfontolandó alternatíva olyan tartalom esetén, amely nem változik kérésenként. Az oldalak az építési időben jelennek meg, és fájlokként szolgálnak ki, ami gyorsabb, mint a kérésenkénti renderelés, olcsóbb a kiszolgálás, rugalmasabb és könnyebben gyorsítótárazható a peremhálózaton. Ahol a tartalom változik, de nem látogatónként, az inkrementális regenerációs stratégiák ütemterv szerint vagy igény szerint újjáépítik az érintett oldalakat, ami a legtöbb előnyt kihasználja a teljes újjáépítés nélkül.

A működési vonatkozások a statikus tárhelytől eltérőek, és tervezést igényelnek. A kérésenkénti renderelés a forgalommal arányosan fogyasztja a szerver erőforrásait, ami olyan skálázási szempontokat és költségeket vet fel, amelyekkel a statikus fájlok nem rendelkeznek. A gyorsítótárazás fontossá válik, és a személyre szabott tartalmat tartalmazó oldalak gyorsítótárazása gondosan elkülöníti a felhasználónként eltérő elemeket. A szerverhibák mostantól az oldalmegjelenítést is befolyásolják, nem csak az adatbetöltést.

Az adatlehívási stratégia határozza meg a gyakorlati előnyök nagy részét. A szerveren történő renderelés csak akkor segít, ha az oldal számára szükséges adatok gyorsan elérhetők, és egy olyan szerver renderelés, amely több lassú belső szolgáltatásra vár, lassabb lehet az első bájt eléréséhez, mint egy kliens renderelés, amely azonnal megjeleníti a shell-t. Ahol a függőségek lassúak, a kész részek folyamatos továbbítása, amíg a többi feldolgozódik, megőrzi az előnyt.

A döntésnek a tartalmat és a közönséget kell követnie, nem pedig a keretrendszer stílusát. A tartalomban gazdag oldalak, amelyeknek rangsorolniuk kell a keresési találatokat, és gyorsan kell betölteniük magukat gyenge kapcsolaton is, jelentősen profitálnak ebből. A hitelesítés mögött álló, interaktív alkalmazások, ahol a keresési láthatóság irreleváns, és a felhasználók már betöltötték az alkalmazást, sokkal kevesebbet profitálnak, és nem feltétlenül indokolják a bonyolultságot. Számos termék ésszerűen eltérő megközelítéseket alkalmaz a különböző részekre.

Mivel a választás egyszerre befolyásolja az infrastruktúrát, a kézbesítést és a keresési teljesítményt, ez inkább architektúrális döntés, mintsem a felhasználói felület preferenciája. A gyakorlatban a rendszeren belül értékelik. webes teljesítmény a mért terepi adatokkal végzett munka, amelyet a következők révén valósítanak meg: termékfejlesztés, és a keresési következményeket a következővel értékelik: marketing szolgáltatások, mivel az indexelési viselkedés gyakran a változtatás mellett szóló legerősebb érv.