Szerveroldali 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.

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:

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).