Fejlesztői boncasztal - Sima React SPA vs. Vike

A probléma: Az SPA rákfenéje és a Lighthouse pofon

Amikor elkezdtem Reacttel dolgozni, a projektet már Vike alapokra építettem. Azt hittem, hogy ettől automatikusan gyors és jól optimalizált alkalmazást kapok. Aztán az első élesítés után jött a hidegzuhany.

A Vite villámgyorsan buildelte az alkalmazást, én pedig magabiztosan futtattam le az első Lighthouse mérést. Az eredmény azonban messze elmaradt attól, amire számítottam.

Hamar rájöttem, hogy a probléma nem a React vagy a Vite volt, hanem maga a klasszikus Client-Side Rendering (CSR).

Egy hagyományos React SPA esetében a böngésző kezdetben szinte csak egy minimális HTML fájlt kap. A tényleges tartalom csak azután jelenik meg, hogy letöltődött és lefutott a JavaScript. Ez nemcsak az első megjelenést lassítja, hanem a keresőoptimalizálást is megnehezítheti.

Bár a Google ma már képes JavaScriptet renderelni, ez egy plusz feldolgozási lépés, amely lassabb indexelést és kevésbé ideális SEO-t eredményezhet.

A megoldás: Vike (korábban vite-plugin-ssr)

Néhány nap kutatás után számomra egyértelmű lett, hogy érdemes átállni a Vike-ra.

Na de mit is tud pontosan?

A Vike lehetővé teszi, hogy ugyanabban a projektben egyszerre használjunk kliensoldali és szerveroldali renderelést.

Amikor engedélyezzük az SSR-t, a szerver már előre elkészíti az oldal HTML-jét, amelyet a böngésző azonnal meg tud jeleníteni. Ezután a React hidratálja (hydration) az oldalt, vagyis interaktívvá teszi azt.

Ennek két óriási előnye van.

Sebesség és teljesítmény

Míg egy hagyományos React SPA-nál először a JavaScriptnek kell lefutnia ahhoz, hogy megjelenjen a tartalom, addig SSR esetén a felhasználó már az első pillanatban kész HTML-t kap.

Az én projektemben ez közel 20 pontos Lighthouse Performance javulást eredményezett. Természetesen ez minden alkalmazásnál más lehet, de jól mutatja, hogy megfelelő esetben mekkora különbséget jelenthet a szerveroldali renderelés.

Keresőoptimalizálás (SEO)

A Vike minden kérésnél képes a szerveren előrenderelni az adott oldal HTML-jét (SSR), illetve statikus oldalak esetén előre generált oldalakat (SSG) is készíthet.

Ennek köszönhetően a keresőmotorok már kész HTML-t kapnak, így könnyebben feltérképezik és indexelik az oldalt.

Természetesen ugyanezt a problémát a Next.js is megoldja.

A különbség inkább a filozófiában rejlik. A Next.js egy teljes értékű keretrendszer rengeteg beépített funkcióval, míg a Vike sokkal minimalistább megközelítést alkalmaz. Számomra ez nagyobb szabadságot és könnyebb testreszabhatóságot jelentett.

React SPA vs. Vike

Struktúra: A többdimenziós fejlesztés

A Vike struktúrája jelentősen eltér egy hagyományos React projekttől.

Beszélhetnénk külön a routingról, a fájlrendszer-alapú konfigurációról vagy a renderelési stratégiákról is, de ezek önmagukban is megérnek egy külön cikket.

Amit viszont mindenképpen kiemelnék, hogy számomra a Vike egy teljesen más gondolkodásmódot hozott.

Miért nevezem többdimenziós fejlesztésnek?

Mert a projekt egy része szerveroldalon, egy másik része kliensoldalon fut. Fejlesztés közben folyamatosan tudatosan kell eldöntenünk, hogy egy adott komponensnek vagy logikának melyik környezetben van a helye.

Elsőre szokatlan, de amikor az ember megérti a működését, rendkívül rugalmas fejlesztési lehetőségeket nyit meg.

Hibalehetőségek

Az SSR rengeteg előnyt ad, de új hibalehetőségeket is hoz magával.

Az alábbiak azok, amelyekkel én is találkoztam a fejlesztés során.

Minified React Error

Ez talán az egyik legismertebb React hiba.

Gyakran akkor jelenik meg, amikor olyan komponens vagy könyvtár kerül szerveroldali renderelésre, amely valójában csak böngészőben működik.

Például egyes MUI komponensek, Portalok vagy useLayoutEffect használata külön odafigyelést igényel SSR környezetben.

További gyakori okok:

• window, document vagy localStorage használata szerveroldalon.
• Érvénytelen HTML struktúra (például <div> egy <p> elemen belül).
• A szerver- és kliensoldali állapot eltérése a hidratáció pillanatában.

Hydration Mismatch

Hydration Mismatch akkor történik, amikor a szerver által renderelt HTML és a kliens által renderelt HTML nem egyezik.

Ennek számos oka lehet:

• eltérő időzóna miatt más eredményt ad a new Date();
• Math.random() vagy más dinamikus érték renderelés közben;
• window.innerWidth vagy más kizárólag kliensoldalon elérhető adat használata;
• eltérő API-válaszok vagy aszinkron állapotok.

Saját tapasztalat: friss deploy után nem mindig a kód a hibás.

Érdemes elsőként böngésző- és szervercache-t üríteni, mert egy régi JavaScript bundle vagy gyorsítótárazott HTML könnyen okozhat hidratációs hibákat.

Zárás

Remélem, sikerült egy kicsit közelebb hoznom a Vike világát azok számára is, akik eddig csak hagyományos React SPA alkalmazásokkal dolgoztak.

A Vike jelenleg még egy viszonylag niche technológia, kevés magyar nyelvű tartalommal és kisebb közösséggel.

Éppen ezért éreztem hiánypótlónak ezt a cikket.

A jövőben szeretnék további szakmai bejegyzéseket írni a Vike működéséről, a renderelési stratégiákról, a routingról, valamint azokról a hibákról és megoldásokról, amelyekkel fejlesztés közben találkoztam.

Ha akár egy fejlesztőnek sikerült időt vagy néhány óra hibakeresést megspórolnom ezzel a cikkel, akkor már megérte megírni.

Köszönöm, hogy elolvastad!