Miért Számít Ma Ez a Döntés
A legtöbb ajánlatkérés ugyanazzal a félreértéssel indul: „statikus az, amit HTML-ben írnak, dinamikus az, ami WordPress”.
Ez 2010-ben is pontatlan volt.
2026-ban pedig kifejezetten félrevezető.
A mai webes projektek nagy része valahol a két véglet között él. Egy static-first architektúra előre legenerált oldalakat szolgál ki, de közben bejelentkezést, fizetést és személyre szabott adatokat is kezel API-kon keresztül.
A hibrid webarchitektúra ma nem kivétel, hanem alapeset.
Ez a cikk annak szól, aki most dönt: bemutatkozó oldalt, landing page-et, blogot, webáruházat vagy egyedi webalkalmazást tervez, és nem szeretne két év múlva nulláról újraépíteni mindent.
Az ígéret egyszerű.
A végére lesz egy használható döntési keretrendszered, amely négy kérdésre épül: milyen gyakran frissül a tartalom, kell-e személyre szabás, vannak-e tranzakciók, és hova akarod fejleszteni az oldalt.
Miért nem technikai apróság ez?
Mert a választás közvetlen üzleti következményekkel jár. Befolyásolja a betöltési sebességet és ezen keresztül a konverziót, meghatározza a havi karbantartási terhet és a hosting költséget, és eldönti, hogy egy későbbi webalkalmazás funkció ráépíthető-e a meglévő rendszerre vagy sem.
A rossz architektúra ritkán azonnal fáj. Általában akkor derül ki, amikor a harmadik új funkciót kérnéd, és a fejlesztő azt mondja: ezt így nem lehet.
A Két Működési Modell
A különbség egyetlen kérdésben dől el: mikor készül el a HTML, amit a böngésző megkap?
Build időben, előre?
Vagy abban a másodpercben, amikor a látogató rákattint?
Hogyan Épül Fel egy Statikus Oldal
A statikus oldal esetében a HTML, CSS és JavaScript fájlok már készen állnak, mielőtt bárki megnyitná az oldalt. Egy statikus site generator (Astro, Hugo, Eleventy, Next.js statikus módban) a tartalomból és a sablonokból lefordítja a teljes oldalstruktúrát.
Ez a build lépés.
Utána jön a deploy: a kész fájlok felkerülnek egy CDN-re, amely világszerte több tucat helyszínről szolgálja ki őket.
Nincs adatbázis-lekérdezés.
Nincs szerveroldali feldolgozás kérésenként.
A látogató gyakorlatilag egy fájlt tölt le a hozzá legközelebbi szerverről.
A tartalom szerkesztése ettől még nem programozói feladat.
Egy headless CMS (Sanity, Strapi, Contentful vagy akár egy Git-alapú szerkesztő) adja a felületet, és minden mentés után automatikusan lefut egy új build.
Hogyan Működik egy Dinamikus Oldal
A dinamikus oldal minden egyes kérésre összerakja a választ. A szerver lekérdezi az adatbázist, ellenőrzi a session adatokat, megnézi, ki a bejelentkezett felhasználó, majd legenerálja a személyre szabott HTML-t.
Ez a szerveroldali renderelés klasszikus modellje. PHP, Node.js, Python vagy Ruby fut a háttérben, és minden oldalletöltés egy kis számítási munka.
Cserébe olyasmit tud, amit egy előre legyártott fájl soha: megmutatja a felhasználó kosarát, a rendelési előzményeit, a neki szóló árat, a készleten lévő termékeket valós időben.
Ennek ára van.
Szerverkapacitás, adatbázis-karbantartás, biztonsági frissítések, és minden kérésnél egy kis késleltetés, amit gyorsítótárazással lehet csökkenteni.
Hol Áll a WordPress Valójában
A WordPress alapértelmezésben dinamikus CMS tartalomkezelő rendszer. PHP fut, MySQL adatbázisból jön a tartalom, minden látogatás szerveroldali munkával jár.
De ez csak a kiindulópont.
Egy jól beállított oldal cache réteggel (LiteSpeed, WP Rocket, Varnish) gyakorlatilag statikus HTML-t szolgál ki a legtöbb látogatónak, és csak a bejelentkezett felhasználók kapnak friss renderelést.
Lehet még tovább menni.
Statikus exporttal vagy headless módban a WordPress csak adminfelületként és API-ként működik, a frontendet pedig egy generátor építi fel.
Ugyanaz a szoftver, teljesen más üzemeltetési modell.
És még egy tévhitet érdemes eltemetni: a statikus nem egyenlő az élettelennel.
Űrlap, élő kereső, animáció, szűrhető terméklista, térkép, foglalási naptár, chat.
Mindez működik statikus oldalon is, mert a kliensoldali renderelés és a külső API-hívások a böngészőben futnak.
Sebesség, Biztonság és SEO Valósága
Itt szokott elcsúszni a szakmai vita.
„A statikus gyors, a dinamikus lassú.” A valóságban láttam már 4 másodperces LCP-vel küzdő statikus oldalt és 0,9 másodperces WooCommerce shopot is.
Melyik Tölt Be Gyorsabban
Az architektúra csak az egyik változó.
A tényleges betöltési időt sokkal inkább a képméretek, a JavaScript-csomag mérete, a CDN és gyorsítótárazás minősége, valamint a harmadik féltől betöltött scriptek száma határozza meg.
Egy statikus oldal, amire ráraknak öt marketing pixelt, három betűtípus-családot és egy 2 MB-os hero videót, simán lassabb lesz, mint egy szigorúan optimalizált dinamikus rendszer.
Ami viszont igaz: a statikus modell alapból jobb kiindulási helyzetet ad. Nincs szerveroldali gondolkodási idő, a TTFB tipikusan 50 milliszekundum alatt marad CDN-ről, és nincs adatbázis, ami forgalmi csúcsban elakadhatna.
A Core Web Vitals három mutatója (LCP, INP, CLS) közül egyedül az LCP-re hat erősen a kiszolgálási modell. Az INP szinte teljes egészében a JavaScript minőségén múlik, a CLS pedig a CSS és a képméretek deklarálásán.
Melyiket Törhetik Fel Könnyebben
A weboldal-biztonság kérdésében a két modell tényleg eltér, de nem úgy, ahogy sokan gondolják.
A dinamikus rendszerek nagyobb támadási felületet kínálnak: van adminfelület jelszóval, van adatbázis SQL injection kockázattal, vannak bővítmények, amelyek elavulhatnak. A WordPress sérülékenységek túlnyomó többsége nem a magban, hanem a pluginekben van.
A statikus oldalnál nincs mit feltörni a szerveren, mert nincs futó alkalmazáslogika.
Ez valós előny.
Viszont a kockázat nem tűnik el, csak átköltözik.
A build folyamat függőségei (npm csomagok), a külső API-kulcsok kezelése, az űrlap-végpontok védelme és a kliensoldali JavaScript mind támadható.
Egy kompromittált npm csomag ugyanolyan kárt okoz, mint egy fertőzött plugin.
Mit Lát Valójában a Google
A Google a kész HTML-t szereti.
Amikor a robot megérkezik, és azonnal megkapja a teljes tartalmat, a SEO és feltérképezhetőség kérdése lényegében megoldott.
Amikor a tartalom csak JavaScript lefutása után jelenik meg, az indexelés egy második, késleltetett renderelési sorba kerül. Ez működik, de lassabb, törékenyebb, és nagyobb oldalaknál pazarolja a crawl budgetet.
Ebből a szempontból mind az előre generált statikus HTML, mind a szerveroldali renderelés jól teljesít.
A tiszta kliensoldali renderelés az, ami kockázatot hordoz.
A többi tényező architektúrafüggetlen: feltérképezhető belső linkstruktúra valódi href attribútumokkal, rendezett sitemap, strukturált adatok (Schema.org), és mért, nem becsült Core Web Vitals értékek a Search Console-ból.
A Modern Renderelési Térkép
Négy renderelési stratégia létezik, és a legtöbb komoly projekt egyszerre kettőt vagy hármat használ.
Nem vagy-vagy kérdés, hanem oldalankénti döntés.
| Modell | Mikor készül a HTML | Tipikus technológia | Erőssége | Mire nem jó |
|---|---|---|---|---|
| SSG (statikus generálás) | Build időben, előre az összes oldalra | Astro, Hugo, Eleventy, Next.js export | Maximális sebesség, minimális hosting költség, kiváló feltérképezhetőség | Percenként változó adat, felhasználónként eltérő tartalom |
| SSR (szerveroldali renderelés) | Minden egyes kérésre, a szerveren | Next.js, Nuxt, Laravel, WordPress, Rails | Személyre szabott és valós idejű tartalom kész HTML-ben | Nagy forgalomnál drága, szerverfüggő, cache nélkül lassú |
| CSR (kliensoldali renderelés) | A böngészőben, JavaScript futtatásával | React, Vue, Angular SPA | Alkalmazásszerű élmény, oldalfrissítés nélküli navigáció | Publikus marketingtartalom, SEO-kritikus aloldalak |
| Hibrid / server islands | Váz build időben, egyes részek kérésre | Astro islands, Next.js ISR, Nuxt hybrid | Statikus sebesség dinamikus szigetekkel ugyanazon az oldalon | Összetettebb üzemeltetés, átgondolt cache-stratégiát igényel |
| ISR (időzített újragenerálás) | Build időben, majd háttérben frissítve | Next.js, Astro adapterekkel | Nagy katalógusok naprakészen tartása teljes build nélkül | Valós idejű készlet- vagy árfolyamadatok |
Az SSG az alapértelmezett választás mindenre, ami ritkábban változik: szolgáltatásoldalak, referenciák, blogcikkek, dokumentáció. A tartalom a build pillanatában befagy, és onnantól csak fájlkiszolgálás történik.
Az SSR ott nélkülözhetetlen, ahol a tartalom felhasználónként vagy percenként más. Kosár, ügyfélportál, élő készletadat, személyre szabott ajánlatok.
A CSR nem ellenség, csak rossz helyen alkalmazva okoz bajt. Admin felületre, kalkulátorra, összetett szűrőrendszerre tökéletes.
Egy publikus szolgáltatásoldalra nem az.
A hibrid megközelítés, más néven islands architecture, ma a legelterjedtebb static-first modell. Az oldal váza statikus HTML, és csak a ténylegesen interaktív komponensek (kereső, kosár ikon, foglalási űrlap) töltenek be JavaScriptet vagy kérnek szerveroldali adatot.
Ennek a haszna mérhető.
Kevesebb kiszállított JavaScript, jobb INP, ugyanakkor teljes értékű funkcionalitás ott, ahol tényleg szükség van rá.
Döntési Keretrendszer Vállalkozásoknak
Elég az elméletből.
Az alábbi keretrendszer üzleti esetekből indul ki, nem technológiából, mert a fejlesztőnek is így érdemes átadni a feladatot.
Üzleti Esetek Gyors Áttekintése
A legtöbb magyar kkv projekt öt kategória valamelyikébe esik. Íme a gyakorlatban bevált hozzárendelés:
- Bemutatkozó oldal és landing page: tiszta statikus vagy static-first. Öt-húsz aloldal, havonta néhány módosítás, nulla személyre szabás. Itt a dinamikus rendszer csak felesleges karbantartási terhet és biztonsági felületet hoz. Egy statikus generátor plusz egyszerű űrlapkezelés bőven elég.
- Blog és tartalomközpontú oldal: statikus generátor plusz headless CMS. Az ügyfél kényelmes szerkesztőfelületen ír, mentés után automatikus build fut, a látogató pedig CDN-ről kapja a kész HTML-t. Többnyelvű oldalnál ez különösen erős, mert a nyelvi verziók build időben generálódnak, külön útvonalakon, tiszta hreflang struktúrával.
- Webáruház: hibrid modell. A kategória- és termékoldalak statikusan vagy ISR-rel generálódnak a sebesség és a SEO miatt, a kosár, a készletellenőrzés és a checkout viszont dinamikus, szerveroldali folyamat. Kis katalógusnál (50-200 termék) ez akár teljesen egyedi stackre is épülhet Stripe fizetéssel.
- Ügyfélportál és foglalási rendszer: dinamikus backend kötelező. Ahol bejelentkezés, jogosultságkezelés és felhasználónként eltérő adat van, ott nincs mit statikusan legenerálni. A publikus marketingoldal viszont ilyenkor is lehet statikus, külön deployolva.
- Egyedi webalkalmazás: teljesen dinamikus architektúra, jellemzően CSR frontenddel és API backenddel. Itt a SEO másodlagos, mert a funkció a termék, nem a tartalom.
Hogyan Bővíthető egy Statikus Oldal
A leggyakoribb félelem: „ha most statikusat csinálunk, később nem tudunk fejleszteni.”
Ez ma már egyszerűen nem igaz.
A statikus frontend API-kon keresztül gyakorlatilag bármilyen dinamikus funkcióval összeköthető:
- Űrlap- és CRM-integráció: a kapcsolatfelvételi űrlap egy szerverless függvénybe vagy külső szolgáltatásba küldi az adatot, onnan pedig automatikusan a CRM-be, e-mail listába vagy Slack csatornába kerül.
- Kereső:
- Kereső és szűrés: kliensoldali indexszel (Pagefind, Fuse.js) vagy külső kereső API-val azonnali eredményt ad, szerver nélkül.
- Felhasználói fiók és adatbázis: Firebase vagy Supabase biztosít authentikációt, valós idejű adatbázist és jogosultságkezelést, miközben a frontend statikus marad.
- Fizetés: Stripe checkout vagy payment link integrálható közvetlenül, saját fizetési infrastruktúra üzemeltetése nélkül.
- Analitika és mérés: könnyű, süti nélküli megoldásokkal, amelyek nem rontják a Core Web Vitals értékeket.
A CompletApp gyakorlatában ez a felállás visszatérő minta: gyors Astro frontend, mögötte Firebase vagy Supabase backend és API réteg, szükség esetén Stripe fizetéssel. Az Apartmanom foglalási logikája és a Tudatosság Klub tagsági funkciói is így épülnek fel, statikus vázra kapcsolt dinamikus szigetekkel.
A lényeg: a statikus alap nem zsákutca, hanem kiindulópont.
Az új funkció nem újraépítést igényel, hanem egy újabb API-kapcsolatot.
Mit Adj Át a Fejlesztőnek
Ha ezt az öt pontot tisztázod az első egyeztetésen, az ajánlat pontosabb lesz, és nem lesz meglepetés a projekt közepén:
- Tartalomfrissítés gyakorisága. Naponta, hetente, negyedévente? A napi többszöri frissítés más architektúrát kíván, mint a negyedéves.
- Ki frissít és hogyan. Marketinges kollégának kell szerkesztőfelület, előnézet és verziókövetés? Vagy a fejlesztő nyúl hozzá? Kérdezd meg, hogyan működik a build, a deploy, az előnézet és a visszaállítás hiba esetén.
- Várható forgalom és csúcsterhelés. Havi 2000 látogató vagy egy kampánynap alatt 50 000? A statikus kiszolgálás terhelésnél alig drágul, a dinamikus viszont igen.
- Személyre szabási igény. Lát-e minden látogató ugyanazt? Ha igen, a kérdés nagy része eldőlt.
- Jövőbeli bővítési tervek. Tervezel bejelentkezést, fizetést, tagsági területet vagy webapp funkciót a következő két évben? Mondd el most, ne a launch után.
Mit Tegyél Most
Ha a tartalmad havonta vagy ritkábban változik, minden látogató ugyanazt látja, és nincs tranzakció az oldalon, a static-first megoldás elegendő. Gyorsabb, olcsóbb üzemeltetni, és lényegesen kevesebb figyelmet igényel.
Ha viszont napi tartalomfrissítés, felhasználói fiók, fizetés vagy személyre szabás szerepel a tervben, dinamikus backend vagy hibrid architektúra kell. Nem érdemes erőltetni a statikus megoldást ott, ahol a funkció megköveteli az ellenkezőjét.
A legjobb stratégia a legtöbb vállalkozásnak: indulj kicsiben, static-first alapon, API-kkal bővíthető módon. Így az első verzió gyorsan élesedik, a költség alacsony marad, és amikor jön az igény a bejelentkezésre vagy a fizetésre, egy réteget adsz hozzá a rendszerhez, nem egy új weboldalt rendelsz.
Amit ma eldöntesz, azt két év múlva vagy áldani fogod, vagy fizeted az árát.
A különbség általában egyetlen jól feltett kérdésen múlik… azon, hogy hova tart a vállalkozásod.
Ha bizonytalan vagy, melyik modell illik a projektedhez, egy rövid szakértői konzultáció tisztázza. Átnézzük a céljaidat, a frissítési igényt és a bővítési terveket, és kapsz egy konkrét ajánlást.
Eladási nyomás nélkül, akkor is, ha a végén az derül ki, hogy a jelenlegi megoldásod tökéletesen megfelel.
