React és Next.js — nagy teljesítményű webalkalmazások
Minden frontend projektünk React 18-ra és Next.js 15-re (App Router) épül: a bemutatkozó oldalaktól a több tízezer felhasználót kiszolgáló, összetett SaaS rendszerekig. A kód szigorúan típusos TypeScript, a tesztek automatizáltak, a telepítés pedig CI/CD-folyamaton át történik.
Miért Next.js a projektjeinkhez
A Next.js 15 App Routere egyedülálló hibrid modellt kínál: a statikus oldalak (SSG) a CDN-ről érkeznek, a dinamikus oldalak Server Componentsként futnak, így semmi fölösleges JavaScriptet nem küldenek a böngészőnek, a valós idejű adatokat megjelenítő felületek pedig elszigetelt Client Componentseket használnak.
A képeket az `<Image>` komponens optimalizálja automatikusan (WebP/AVIF, reszponzív srcSet, lazy loading), a betűtípusok a `next/font` révén a kritikus CSS-be kerülnek, a külső szkriptek pedig prioritási stratégia szerint töltődnek be.
- Server Components a marketingoldalakhoz — nulla kliensoldali JS, a HTML a szerveren készül
- Streaming SSR Suspense-szel az élő adatokat mutató vezérlőpultokhoz
- Incremental Static Regeneration (ISR) a félig dinamikus tartalmakhoz
- Route Groups és Parallel Routes az összetett elrendezésekhez, újrarenderelés nélkül
Szigorú TypeScript — néma hibák nélkül
Minden projektünk `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` és `noUncheckedIndexedAccess` beállításokkal használja a TypeScriptet. Ezek már fordításkor kiszűrik a futásidejű hibák egész családjait: az undefined értékek elérését, az API-válaszok hiányos típusait, a hibás összehasonlításokat. Egy tipikus projekt nulla TypeScript-hibával megy át a CI-n, még mielőtt bármelyik teszt elindulna.
Az állapotkezelést Zustanddal (könnyű, sallangmentes) vagy helyi állapot esetén React Contexttel oldjuk meg. Az adatlekérést a TanStack Query végzi (automatikus gyorsítótár, okos érvénytelenítés, stale-while-revalidate). Az űrlapokhoz React Hook Formot és Zod-sémavalidációt használunk — szinkron és aszinkron ellenőrzés kódduplikálás nélkül.
- ESLint saját szabályokkal a tiltott mintákra (any, console.log, mágikus sztringek)
- Prettier egységes beállítással — formázás miatt egyetlen PR sem akad el
- Zod a külső API-kból érkező adatok futásidejű ellenőrzésére
- Path alias (`@/components/...`) — átlátható importok `../../..` nélkül
Automatizált tesztelés és CI/CD
Egységtesztek Vitesttel (gyors, a Jest API-jával kompatibilis), komponenstesztek React Testing Libraryvel, végponttól végpontig tartó tesztek Playwrighttal három böngészőben (Chromium, Firefox, WebKit). A GitHub Actions-folyamat minden PR-nél lefuttatja az összes tesztet; ha bármelyik elbukik, a merge nem engedélyezett. Az üzleti logikán legalább 80% a lefedettség.
- Lighthouse CI — 90 alatti pontszám esetén a staging telepítés leáll
- Automatikus bundle-elemzés — riasztás, ha a csomag több mint 5%-kal nő a mainhez képest
- Storybook a felületi komponensekhez — élő vizuális dokumentáció
Előnyök és korlátok
Előnyök
- Lighthouse CI a telepítés előtt ellenőrzi a teljesítményt.
- Beépített SSR és SSG — a teljes HTML a szerveren készül, a keresőrobotok számára is.
- A szigorú TypeScript fordításkor fogja meg a hibákat, nem élesben.
- Érett ökoszisztéma: Vercel, több ezer csomag, hatalmas közösség.
Korlátok
- Az App Router és a Server Components tanulási görbéje meredek.
- A főverziók között gyakoriak a változások — folyamatos karbantartást igényel.
- Egyszerű statikus oldalhoz a Next.js túlzás lehet a sima HTML-hez képest.
- A nagy buildek megnövelik a fordítási időt és a CI költségeit.
Rövid értékelés
Válaszd a Reactot és a Next.js-t olyan webhelyekhez és alkalmazásokhoz, amelyeknek gyorsnak, indexelhetőnek és skálázhatónak kell lenniük. Egyetlen statikus, interaktivitás nélküli landing oldalhoz egyszerűbb megoldás is elég.
Specifikációs táblázat
| Képesség | Korlát / küszöb | Tipikus felhasználás | |
|---|---|---|---|
| Renderelés | SSR, SSG, ISR, CSR | A Server Components korlátozza a böngésző API-jait | Statikus marketing + dinamikus vezérlőpult |
| Teljesítmény | Core Web Vitals szerinti optimalizálás (LCP, CLS, INP) | A hidratálás JS-e az interaktivitással együtt nő | Nagy forgalmú, SEO-kritikus webhelyek |
| Skálázás | Több tízezer felhasználó, edge CDN | Node-alapú vagy serverless hosting kell hozzá | SaaS, portálok, webáruházak |
| Tipikus költség | Nyílt forráskódú, a hosting kb. 0 €-tól | A serverless függvényeket használat szerint számlázzák | Kis projektektől a nagyvállalatiig |
Next.js az alternatívákhoz képest
| Szempont | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG egyetlen keretrendszerben | Igen, beépítve | Részben (Nuxt igen, Vite nem) |
| React-ökoszisztéma | Teljes | Vue (Nuxt) vagy több keretrendszer (Astro) |
| Tisztán statikus oldalra optimális | Jó | Az Astro könnyedebb |
Gyakori kérdések
Miért Next.js, és miért nem egyszerű React (Vite)?
A React Vitével csak a böngészőben renderel, így a kezdeti HTML üres — ez rossz a SEO és a GEO szempontjából. A Next.js SSR-rel és SSG-vel egészíti ki, és teljes HTML-t szolgál ki, amelyet a keresőrobotok közvetlenül olvashatnak.
Jó a Next.js SEO szempontjából?
Igen. Az SSR/SSG indexelhető HTML-t ad, a metaadatok és a JSON-LD a szerveren készülnek el, a Core Web Vitals optimalizálása pedig a felépítés része — mind erős rangsorolási jelzés.
Átköltöztethetem a meglévő webhelyemet Next.js-re?
Igen, fokozatosan: az oldalak egyesével kerülnek át, miközben az URL-ek és a 301-es átirányítások megmaradnak.
Milyen hosting kell a Next.js-hez?
A statikus oldalak bármelyik CDN-en elfutnak. A dinamikus funkciókhoz (SSR, API Routes) Node.js vagy serverless futtatókörnyezet kell, például Vercel, Netlify vagy egy Docker-konténer.