A gyorsabb weboldalbetöltési idők nagy szerepet játszanak a felhasználói élményben és a keresőoptimalizálásban, az oldalbetöltési sebesség pedig kulcsfontosságú meghatározó tényező a Google algoritmusa számára.
A front-end webfejlesztőnek el kell döntenie a webhely megjelenítésének legjobb módját, hogy az gyors élményt és dinamikus tartalmat biztosítson.
Két népszerű megjelenítési módszer a kliensoldali renderelés (CSR) és a szerveroldali megjelenítés (SSR).
Minden webhelyre eltérő követelmények vonatkoznak, így az ügyféloldali és a szerveroldali megjelenítés közötti különbség megértése segíthet a webhely üzleti céljainak megfelelő megjelenítésében.
Google és JavaScript
A Google kiterjedt dokumentációval rendelkezik arról, hogyan kezeli a JavaScriptet, és a Google munkatársai különféle – hivatalos és nem hivatalos – formátumokon keresztül betekintést nyújtanak, és rendszeresen válaszolnak a JavaScript-kérdésekre.
Például egy Search Off The Record podcastban szóba került, hogy a Google az összes oldalt megjeleníti a kereséshez, beleértve a JavaScriptet is tartalmazó oldalakat is.
Ez jelentős beszélgetést váltott ki a LinkedIn-en, és a podcastból és a folyamatban lévő vitákból még egy-két kivonat a következők:
- A Google nem követi nyomon, hogy mennyibe kerül bizonyos oldalak megjelenítése.
- A Google az összes oldalt megjeleníti a tartalom megtekintéséhez – függetlenül attól, hogy JavaScriptet használ-e vagy sem.
A beszélgetés egésze segített eloszlatni sok mítoszt és tévhitet arról, hogyan Google esetleg megkereste a JavaScriptet és kiosztotta az erőforrásokat.
Martin Splitt teljes kommentje a LinkedIn-en, amely ezzel foglalkozik:
„Nem követjük nyomon, hogy „mennyibe került nekünk ez az oldal?” vagy valami. Tudjuk, hogy az internet jelentős része JavaScriptet használ a weboldalak tartalmának hozzáadásához, eltávolításához és módosításához. Csak renderelni kell, hogy lássuk az egészet. Teljesen mindegy, hogy egy oldal használ-e JavaScriptet vagy sem, mert csak akkor lehetünk teljesen biztosak abban, hogy az összes tartalmat a megjelenítés után látjuk.”
Martin megerősítette a várakozási sort és az esetleges késést is a feltérképezés és az indexelés között, de nem csak azért, mert valami JavaScript vagy sem, és az sem „átláthatatlan” probléma, hogy a JavaScript jelenléte az URL-ek nem indexelésének alapvető oka.
Általános JavaScript bevált gyakorlatok
Mielőtt belevágnánk a kliensoldali versus szerveroldali vitába, fontos, hogy kövessük az általános bevált gyakorlatokat az alábbi megközelítések bármelyikének működéséhez:
- Ne blokkolja a JavaScript-erőforrásokat a Robots.txt fájlon vagy a szerverszabályokon keresztül.
- Kerülje a renderelés blokkolását.
- Kerülje a JavaScript beszúrását a DOM-ba.
Mi az a kliensoldali renderelés, és hogyan működik?
Az ügyféloldali megjelenítés egy viszonylag új megközelítés a webhelyek megjelenítéséhez.
Akkor vált népszerűvé, amikor a JavaScript-könyvtárak elkezdték integrálni, az Angular és a React.js pedig az ilyen típusú megjelenítéshez használt könyvtárak egyik legjobb példája.
Úgy működik, hogy a webhely JavaScript-kódját a böngészőben jeleníti meg, nem pedig a szerveren.
A szerver a JS-fájlokat tartalmazó csupasz HTML-dokumentummal válaszol, ahelyett, hogy a HTML-dokumentum teljes tartalmát lekérné.
Míg a kezdeti feltöltési idő kissé lassú, a későbbi oldalbetöltések gyorsak lesznek, mivel nem függenek útvonalonként eltérő HTML-oldaltól.
A logika kezelésétől az adatok API-ból való lekéréséig az ügyfél által megjelenített webhelyek mindent „függetlenül” csinálnak. Az oldal a kód végrehajtása után elérhető, mivel a felhasználó által felkeresett minden oldal és a hozzá tartozó URL dinamikusan jön létre.
A CSR folyamat a következő:
- A felhasználó beírja a meglátogatni kívánt URL-t a címsorba.
- Adatkérést küld a szerver a megadott URL-címen.
- A kliens webhelyre vonatkozó első kérésére a szerver a statikus fájlokat (CSS és HTML) eljuttatja a kliens böngészőjébe.
- Az ügyfélböngésző először a HTML tartalmat tölti le, majd a JavaScriptet. Ezek a HTML fájlok összekapcsolják a JavaScriptet, és elindítják a betöltési folyamatot a fejlesztő által a felhasználó számára meghatározott betöltési szimbólumok megjelenítésével. Ebben a szakaszban a webhely még mindig nem látható a felhasználó számára.
- A JavaScript letöltése után a tartalom dinamikusan generálódik az ügyfél böngészőjében.
- A webtartalom láthatóvá válik, amikor az ügyfél navigál és interakcióba lép a webhelyen.
Mi az a szerveroldali renderelés, és hogyan működik?
A szerveroldali megjelenítés az elterjedtebb technika az információk képernyőn történő megjelenítésére.
A webböngésző információkérést küld a szervertől, lekéri a felhasználó-specifikus adatokat a feltöltéshez, és egy teljesen renderelt HTML oldalt küld a kliensnek.
Minden alkalommal, amikor a felhasználó felkeres egy új oldalt a webhelyen, a szerver megismétli a teljes folyamatot.
Lépésről lépésre az SSR folyamat menete:
- A felhasználó beírja a meglátogatni kívánt URL-t a címsorba.
- A szerver megjelenítésre kész HTML választ szolgál ki a böngészőnek.
- A böngésző megjeleníti az oldalt (most már megtekinthető), és letölti a JavaScriptet.
- A böngésző végrehajtja a Reactot, így interaktívvá teszi az oldalt.
Mi a különbség az ügyféloldali és a szerveroldali renderelés között?
A fő különbség e két megjelenítési megközelítés között a működésük algoritmusaiban van. A CSR betöltés előtt egy üres oldalt, míg az SSR egy teljesen renderelt HTML oldalt jelenít meg az első betöltéskor.
Ez gyorsasági előnyt biztosít a szerveroldali megjelenítésnek a kliensoldali rendereléssel szemben, mivel a böngészőnek nem kell nagy JavaScript fájlokat feldolgoznia. A tartalom gyakran néhány ezredmásodperc alatt látható.
A keresőmotorok feltérképezhetik a webhelyet a jobb keresőoptimalizálás érdekében, így egyszerűvé téve a weboldalak indexelését. Ez a szöveges olvashatóság pontosan az, ahogyan az SSR webhelyek megjelennek a böngészőben.
Az ügyféloldali megjelenítés azonban olcsóbb megoldás a webhelytulajdonosok számára.
Csökkenti a szerverek terhelését, áthárítva a renderelés felelősségét a kliensre (a botra vagy a felhasználóra, aki megpróbálja megtekinteni az oldalt). Gazdag webhely-interakciókat is kínál azáltal, hogy a kezdeti betöltés után gyors webhely-interakciót biztosít.
Kevesebb HTTP-kérés érkezik a kiszolgálóhoz a CSR használatával, ellentétben az SSR-rel, ahol minden oldal a nulláról készül, ami lassabb átmenetet eredményez az oldalak között.
Az SSR magas szerverterhelés alatt is megbukhat, ha a szerver egyszerre több kérést kap különböző felhasználóktól.
A CSR hátránya a hosszabb kezdeti betöltési idő. Ez hatással lehet a SEO-ra; Előfordulhat, hogy a robotok nem várják meg, amíg a tartalom betöltődik, és kilép a webhelyről.
Ez a kétfázisú megközelítés felveti annak lehetőségét, hogy üres tartalom jelenjen meg az oldalon, mivel az oldal HTML-kódjának első feltérképezése és indexelése után hiányzik a JavaScript-tartalom. Ne feledje, hogy a legtöbb esetben a CSR külső könyvtárat igényel.
Mikor használjunk szerveroldali renderinget
Ha javítani szeretné a Google láthatóságát, és előkelő helyet szeretne elérni a keresőmotorok eredményoldalain (SERP), akkor a szerveroldali megjelenítés az első számú választás.
Az e-learning webhelyek, az online piacterek és az egyszerű felhasználói felülettel rendelkező alkalmazások, kevesebb oldallal, szolgáltatással és dinamikus adattal, mind profitálnak az ilyen típusú megjelenítésből.
Mikor használjuk az ügyféloldali renderelést
Az ügyféloldali megjelenítés általában dinamikus webalkalmazásokkal, például közösségi hálózatokkal vagy online üzenetküldőkkel párosul. Ennek az az oka, hogy ezeknek az alkalmazásoknak az információi folyamatosan változnak, és nagy és dinamikus adatokkal kell foglalkozniuk, hogy gyors frissítéseket hajtsanak végre a felhasználói igények kielégítése érdekében.
A hangsúly itt egy gazdag webhelyen van, sok felhasználóval, és a felhasználói élményt helyezi előtérbe a SEO-val szemben.
Melyik a jobb: szerveroldali vagy ügyféloldali renderelés?
A legjobb megközelítés meghatározásakor nemcsak SEO-igényeit kell figyelembe vennie, hanem azt is, hogy a webhely hogyan működik a felhasználók számára, és hogyan biztosít értéket.
Gondolja át projektjét, és azt, hogy a választott megjelenítés hogyan befolyásolja pozícióját a SERP-ben és webhelye felhasználói élményét.
Általában a CSR jobb dinamikus webhelyekhez, míg az SSR a statikus webhelyekhez.
Tartalomfrissítési gyakoriság
Az olyan webhelyek, amelyek rendkívül dinamikus információkat tartalmaznak, mint például a szerencsejáték- vagy FOREX-webhelyek, másodpercenként frissítik a tartalmukat, ami azt jelenti, hogy ebben a forgatókönyvben valószínűleg a CSR-t választja az SSR helyett – vagy a CSR-t választja bizonyos céloldalakhoz, és nem minden oldalhoz, attól függően felhasználószerzési stratégia.
Az SSR hatékonyabb, ha a webhely tartalma nem igényel sok felhasználói beavatkozást. Pozitívan befolyásolja a hozzáférhetőséget, az oldal betöltési idejét, a SEO-t és a közösségi média támogatását.
Másrészt a CSR kiválóan alkalmas a webalkalmazások költséghatékony megjelenítésére, valamint egyszerűbb felépíteni és karbantartani; ez jobb az első beviteli késleltetéshez (FID).
Egy másik CSR-megfontolás az, hogy a metacímkéket (leírás, cím), kanonikus URL-eket és a Hreflang címkéket szerveroldalon kell megjeleníteni, vagy be kell mutatni a kezdeti HTML-válaszban, hogy a robotok a lehető leghamarabb azonosíthassák őket, és ne csak a rendereltben jelenjenek meg. HTML.
Platform szempontok
A CSR-technológia fenntartása általában drágább, mivel a React.js-ben vagy a Node.js-ben jártas fejlesztők óradíja általában magasabb, mint a PHP- vagy WordPress-fejlesztőké.
Ezenkívül kevesebb kész beépülő modul vagy kész megoldás áll rendelkezésre a CSR-keretrendszerekhez, mint a nagyobb plugin-ökoszisztémához, amelyhez a WordPress-felhasználók is hozzáférhetnek.
Azok számára, akik a fej nélküli WordPress-beállítást fontolgatják, például a Frontity használatát, fontos megjegyezni, hogy React.js-fejlesztőket és PHP-fejlesztőket is fel kell venniük.
Ennek az az oka, hogy a fej nélküli WordPress a React.js-re támaszkodik az előtérben, miközben továbbra is PHP-t igényel a háttérben.
Fontos megjegyezni, hogy nem minden WordPress beépülő modul kompatibilis a fej nélküli beállításokkal, ami korlátozhatja a funkcionalitást, vagy további egyéni fejlesztést igényelhet.
A webhely funkcionalitása és célja
Néha nem kell választania a kettő közül, mivel hibrid megoldások is rendelkezésre állnak. Mind az SSR, mind a CSR megvalósítható egyetlen webhelyen vagy weboldalon belül.
Például egy online piactéren a termékleírásokat tartalmazó oldalak megjeleníthetők a szerveren, mivel ezek statikusak, és a keresőmotoroknak könnyen indexelniük kell őket.
Az e-kereskedelemnél maradva, ha számos oldalon magas szintű személyre szabottságot biztosít a felhasználók számára, akkor nem tudja SSR-megjeleníteni a tartalmat a robotok számára, ezért meg kell határoznia valamilyen alapértelmezett tartalmat a Googlebot számára, amely cookie-mentesen térképez fel és hontalan.
Az olyan oldalakat, mint a felhasználói fiókok, nem kell rangsorolni a keresőmotorok eredményoldalain (SERP), így a CRS-megközelítés jobb lehet az UX-hez.
Mind a CSR, mind az SSR népszerű megközelítések a webhelyek megjelenítésére. Önnek és csapatának ezt a döntést a termékfejlesztés kezdeti szakaszában kell meghoznia.
További források:
