# Szerveroldali renderelés

> Lépésenkénti útmutató, ha a szerver szinte üres HTML-t küld, és a tartalmat csak a JavaScript rakja ki: SSR, statikus kiszolgálás vagy előrenderelés.

Ezt a javítási kártyát a riport akkor adja, ha az oldal HTML-je a szervertől szinte üres, a tartalmat pedig csak a JavaScript rakja ki a böngészőben (kliensoldali renderelés, CSR). A keresők és a lassú telefonok így későn vagy egyáltalán nem látják a tartalmat.

## Hogyan mérjük

A riport összeveti a szerver által küldött HTML szövegét a renderelt lap szövegével. A kártya akkor jelenik meg (magas súlyossággal, SEO-kategóriában), ha egyszerre igaz:

- a szerver HTML-jében 100 karakternél kevesebb a szöveg,
- a renderelt lapon legalább 500 karakter szöveg van,
- és van SPA-jel: egy mount-elem vagy egy ismert keretrendszer nyoma a HTML-ben.

A SPA-jel nélküli eset (például rövid nyitólap, amelyre egy süti-sáv vagy widget rak szöveget) nem számít CSR-nek, mert arra a "renderelj szerveroldalon" rossz tanács lenne. Ha az oldal SaaS-platformon fut (például Shopify, Wix), a kártya más szöveget ad: ott a renderelést a platform végzi, kód és szerveroldali beállítás nélkül, és az ügyfélszolgálatot érdemes kérdezni.

## Miért számít

A Google a JavaScriptes oldalakat három lépésben dolgozza fel: feltérképezés, renderelés, indexelés. A renderelés várólistára kerül, és a Google szerint "néhány másodpercet", esetleg többet is várhat. A Google a szerveroldali vagy előrenderelést kifejezetten jó ötletnek nevezi, mert nem minden bot futtat JavaScriptet. A web.dev szerint a szerveroldali renderelés általában gyors első megjelenítést ad, a CSR viszont mobilon nehezen tartható gyorsnak, és a növekvő JavaScript az INP-t is ronthatja. Ez az LCP-t is érinti: [Labor-LCP](https://hub.hellowp.io/hu/report/teljesitmeny/labor-lcp/).

## Hogyan javítsd

1. **Ellenőrizd, mit lát a szerver.** A `curl` kimenete a szerver HTML-jét mutatja JavaScript nélkül; a böngészőben a "Forrás megtekintése" ugyanezt.
2. **Válaszd ki a megoldást a keretrendszeredhez:**
   - **SSR (szerveroldali renderelés):** a szerver minden kérésnél kész HTML-t állít elő. Gyors első megjelenítés, de a szerver terhelése és a TTFB nőhet.
   - **Statikus renderelés (SSG):** a HTML előre elkészül, és CDN-ről is kiszolgálható. Állandóan gyors TTFB, de oldalanként külön HTML-fájl kell, és személyre szabott oldalakhoz nem illik.
   - **Előrenderelés (prerendering):** a kliensoldali alkalmazás kezdeti állapotát HTML-ként rögzíti. Javítja az első megjelenítést, de az oldal addig mozdulatlan, amíg a JavaScript be nem töltődik.
3. **Kapcsold be a keretrendszered erre szolgáló módját** (a keretrendszer dokumentációja mondja meg, hogyan), majd építsd újra és telepítsd.
4. **Figyelj a hidratálásra:** SSR-nél az oldal látszhat késznek, miközben még nem reagál, ha a JavaScript későn fut le. Tartsd kicsin a kliensoldali JavaScriptet.
5. **WordPress:** a WordPress alapból szerveroldalon állítja elő a HTML-t, így a kártya többnyire egy oldalépítőből, fejetlen (headless) kialakításból vagy egy JavaScriptes beágyazásból ered. Nézd meg, melyik elem rakja ki a tartalmat.

Ehhez a kártyához a riport nem ad általános kódrészletet, mert a megoldás teljesen a használt keretrendszertől függ.

## Hogyan ellenőrizd

- Futtasd újra a riportot: a kártya eltűnik, ha a szerver HTML-je már tartalmazza a szöveget.
- Parancs a szerver által küldött HTML megnézésére:

```bash title="Terminál"
curl -s https://pelda.hu/ | head -c 2000
```

- A Google Search Console URL-vizsgálat és a Rich Results Test megmutatja, mit lát a Google a renderelt oldalból.
- Nézd meg a Labor-LCP értékét is: [A fő tartalom betöltése előbb (LCP)](https://hub.hellowp.io/hu/report/teljesitmeny/a-fo-tartalom-betoltese-elobb-lcp/).