Alkalmazás-érzés weboldalon: View Transitions és a Next.js 16.3 Instant Navigations

Ismered azt a pillanatot, amikor egy jó mobilalkalmazásban rábök az ember egy termékképre, az pedig finoman megnő és átúszik a részletes nézetbe, miközben egy átlagos céges weboldalon minden kattintás után jön egy villanásnyi fehér képernyő, majd nulláról épül fel az új oldal? Ma, 2026-ban ez a különbség sokkal inkább tervezési döntés, mint technológiai korlát. A böngészők beépített View Transitions funkciója (magyarul nagyjából nézetátmenet) ma már a külön oldalak közötti váltást is képes animálni, a Vercel pedig 2026. augusztus 3-án kiadta a Next.js 16.3-at, amelynek Instant Navigations nevű eszközcsomagja azt ígéri, hogy a szerveren renderelt oldalak is azonnal reagálnak a kattintásra, ahogy egy alkalmazás.

A weboldal és az alkalmazás közötti határ tehát gyorsan kopik, ami egy cégvezetőnek két kérdést vet fel: érdemes-e ezzel a saját oldalán foglalkozni, illetve ha igen, mennyi munkával és pénzzel jár. Az alábbiakban 2026. szeptember 22-i állapot szerint végigvesszük, mi az a view transition és miért érzi tőle az ügyfél gyorsabbnak az oldalt, mit hozott a Chrome 146 és 147, mit tud a Next.js 16.3 a memóriafogyasztástól a build-időn át az azonnali navigációig, végül egyenes ítéletet mondunk arról, milyen oldalnál éri meg a befektetés és hol marad felesleges csillogás.

Röviden

• A View Transitions a böngészők beépített funkciója, amely két nézet vagy két oldal között animált átmenetet rajzol, így a látogató végig látja, honnan hová jutott, a váltás pedig rövidebbnek és gördülékenyebbnek érződik.
• A dokumentumok közötti (külön oldalak közötti) átmeneteket a Chrome fejlesztői dokumentációja szerint a Chrome és az Edge a 126-os, a Safari a 18.2-es verziótól támogatja, a Firefox még nem, a Chrome 147 pedig bevezette az elemre szűkített átmeneteket, amelyeknél csak az oldal egy része animálódik, a többi közben használható marad.
• A Next.js 16.3 a 2026. augusztus 3-i bejelentés szerint fejlesztés közben akár 90%-kal kevesebb memóriát használ, a gyorsítótárazott build egyes projekteknél 5,5-szer gyorsabb, szerveroldali rendereléskor pedig terhelés alatt akár 22%-kal több kérést szolgál ki.
• Az Instant Navigations a Next.js 16.3 bekapcsolható eszközcsomagja, amely útvonalanként előre letölt egy újrahasznosítható oldalvázat, így a kattintás pillanatában azonnal megjelenik valami, a tartalom többi része pedig fokozatosan érkezik a szerverről.
• Egy 5 és 10 oldal közötti bemutatkozó webhelyen a dokumentumok közötti áttűnés néhány sor CSS, ezért szinte ingyen van, egy meglévő Next.js-alkalmazás átállítása az Instant Navigationsre viszont napokban vagy hetekben mérhető munka, amely leginkább webshopnál, ügyfélportálnál és foglalási rendszernél térül meg.

Mi az a view transition és miért érzi az ügyfél gyorsabbnak az oldalt?

A view transition (magyarul nézetátmenet) a böngésző beépített mechanizmusa, amely két állapot vagy két oldal között animált átmenetet rajzol: pillanatképet készít a régi nézetről, felépíti az újat, majd a kettő között áttűnést vagy mozgást játszik le. Az ügyfél azért érzi gyorsabbnak az oldalt, mert a mozgás kitölti a várakozást és megmutatja, mi hová került.

A hagyományos webes oldalváltás a látogató szemszögéből egy apró megszakítás. Rákattint egy linkre, a képernyő egy pillanatra kiürül vagy megdermed, aztán az új oldal a semmiből rajzolódik ki, a szemnek pedig újra meg kell keresnie, hol van a cím, a kép vagy a gomb. Ezt a mikroszakadást a legtöbben tudatosan észre sem veszik, a hatása mégis összeadódik, hiszen egy tízkattintásos vásárlási folyamatban tíz ilyen apró „újraindulás” van.

A mobilalkalmazások ezt régóta máshogy csinálják. Ott a kiválasztott elem nem tűnik el, hanem átalakul: a listában látott kis kép megnő és a részletes nézet tetejére úszik, a vissza gomb megnyomásakor pedig ugyanez az út visszafelé is lejátszódik. A felhasználó agya így végig tudja, hol jár, ezért kevesebb energiát fordít a tájékozódásra és többet a tartalomra. Ezt nevezi a szakma alkalmazás-érzésnek (app-like experience), a View Transitions pedig most a hagyományos, többoldalas weboldalakra is elhozza.

Vegyünk egy képzeletbeli balatoni panziót, amelynek szobalistájában a vendég rákattint a „Tóra néző franciaágyas szoba” kártyájára. Nézetátmenet nélkül a lista eltűnik, fehér lesz a képernyő, majd megjelenik a szobaoldal, ahol a vendégnek újra meg kell találnia, hogy ez ugyanaz a szoba, amelyiket kinézte. Nézetátmenettel a kártyán lévő fotó a kattintás után felnagyobbodik és a szobaoldal fejlécébe úszik, a szöveg közben finoman áttűnik, a vissza gomb pedig ugyanezt visszafelé játssza le. Ugyanaz a tartalom, ugyanaz a szerver, mégis egészen más az élmény.

Két fogalmat itt jól el kell választani egymástól: a mért és az észlelt sebességet. A mért sebesség az, amit a műszerek rögzítenek, például hogy hány ezredmásodperc alatt jelenik meg a legnagyobb tartalmi elem (Largest Contentful Paint, LCP), vagy mennyi idő telik el egy kattintás és a képernyő reakciója között (Interaction to Next Paint, INP). Az észlelt sebesség (perceived performance) viszont az, amilyen gyorsnak a felhasználó érzi az oldalt, függetlenül attól, mit mutat a stopper. A kettő összefügg, de nem azonos: egy várakozás, amely alatt semmi sem mozdul, jellemzően hosszabbnak tűnik, mint egy ugyanilyen hosszú, amely alatt a kattintott elem látható módon halad az új helye felé.

Mennyit ér a sebesség forintban?

Hogy a sebesség nem csak esztétikai kérdés, azt a Google megbízásából a Deloitte és az 55 nevű ügynökség által 2019-ben készített „Milliseconds Make Millions” tanulmány mutatja a legismertebben. A kutatók 37 európai és amerikai márka oldalán több mint 30 millió felhasználói munkamenetet elemeztek. A web.dev összefoglalója szerint ha a mobil oldalsebesség több mérőszáma egyaránt 0,1 másodperccel javult, a kiskereskedelmi oldalakon 8,4%-kal, az utazási oldalakon 10,1%-kal nőtt a konverziós arány, a kiskereskedelmi átlagos kosárérték 9,2%-kal emelkedett, a leadgeneráló oldalak űrlapküldéseiben pedig 21,6%-os javulást mértek.

Van azonban egy lényeges csavar, amelyről ritkán esik szó az ügyféltárgyalásokon. A tanulmány valódi, mért sebességjavulást vizsgált, nem animációt, egy szép átmenet pedig önmagában egyetlen ezredmásodperccel sem gyorsítja a szervert. Ha az új oldal három másodpercig töltődik, azt semmilyen animáció nem fedi el, sőt a Chrome fejlesztői dokumentációja szerint a böngésző négy másodperc után egyszerűen kihagyja a dokumentumok közötti átmenetet.

A helyes gondolkodás ezért az, hogy a View Transitions a már elég gyors oldalt teszi kellemesebbé és érthetőbbé, a Next.js 16.3 Instant Navigations viszont a tényleges várakozási időn is farag, mert a kattintás pillanatában már van mit megmutatni. A kettő együtt adja azt az élményt, amelyet a látogató alkalmazásszerűnek érez, egyik a másikat nem helyettesíti.

Mitől lesz alkalmazás-érzése egy weboldalnak?

Ha szétszedjük az alkalmazás-érzést, négy összetevőt találunk, amelyeket más-más eszköz szolgál ki:

• Azonnali visszajelzés: a kattintásra még azelőtt történik valami a képernyőn, hogy a szerver válaszolna, például megjelenik az új oldal váza vagy egy betöltésjelző.
• Folytonosság: az elemek nem tűnnek el és bukkannak fel újra, hanem a régi helyükről az új helyükre mozognak, így a szem követni tudja őket.
• Megőrzött állapot: oldalváltáskor nem vész el, ami már megvolt: a zene szól tovább, a kitöltött mező kitöltve marad, a görgetési pozíció pedig a helyén van.
• Optimista frissítés: a kedvencnek jelölés vagy a kosárba tétel azonnal látszik a képernyőn, a szerver visszaigazolása csak utána érkezik meg.

A View Transitions elsősorban a folytonosságért felel, a Next.js 16.3 eszközei pedig főleg a másik háromért, ezért a folytatásban mindkettőt külön is megnézzük.

Hogyan működik a View Transitions a böngészőben?

A View Transitions úgy működik, hogy a böngésző a váltás előtt pillanatképet készít a régi nézetről, felépíti az újat, majd a kettő között CSS-animációt futtat. Alapesetben egyszerű áttűnés történik, a view-transition-name tulajdonsággal megjelölt elemek (például egy termékfotó) viszont külön animálódnak: a régi helyükről az új helyükre úsznak.

Az MDN (a Mozilla fejlesztői dokumentációja) meghatározása szerint a View Transition API olyan mechanizmus, amely animált átmenetet biztosít a weboldal különböző nézetei között, egyoldalas alkalmazásban (single-page app, SPA) a DOM-állapotok, többoldalas webhelyen (multi-page app, MPA) pedig a dokumentumok között. A gyakorlatban ez két jól elkülönülő felhasználási módot jelent.

Egy oldalon belüli átmenet

Az egyik eset az, amikor az oldal nem töltődik újra, csak a tartalma változik, például a terméklista szűrésekor vagy egy fül átváltásakor. Ilyenkor a fejlesztő JavaScriptből hívja meg a document.startViewTransition() függvényt, a változtatást pedig ebbe csomagolja. A böngésző lefotózza a kiinduló állapotot, végrehajtja a módosítást, majd a kettő között lejátssza az animációt.

Két külön oldal közötti átmenet

A másik, a céges weboldalak szempontjából izgalmasabb eset a dokumentumok közötti (cross-document) átmenet, amikor a látogató valóban új oldalra lép, például a „Szolgáltatások” menüpontról a „Kapcsolat” oldalra. Ehhez nem kell JavaScript, elég, ha mindkét oldal stíluslapjában szerepel egy rövid CSS-szabály, amellyel az oldal jelzi, hogy részt vesz az átmenetben. Hogy a mozgásra érzékeny látogatók se szédüljenek, a CSS-Tricks 2026. májusi útmutatója azt javasolja, hogy ezt a szabályt eleve a prefers-reduced-motion médiafeltételbe csomagold:

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Nem fejlesztői nyelvre fordítva ez annyit jelent: „ha a látogató nem kérte a rendszerében a mozgás csökkentését, akkor az oldalváltások legyenek animáltak”. Ennyi elég ahhoz, hogy a támogató böngészőkben a fehér villanás helyett finom áttűnés jelenjen meg az oldalak között. Ha pedig egy konkrét elemet, például egy termékfotót szeretnél „átvinni” az egyik oldalról a másikra, azt mindkét oldalon ugyanazzal a névvel kell megjelölni:

/* Listaoldal: a 42-es termék kártyaképe */
.termekkartya-42 img {
  view-transition-name: termek-42;
}
/* Termékoldal: ugyanennek a terméknek a főképe */
.termek-fokep {
  view-transition-name: termek-42;
}

A névnek egy oldalon belül egyedinek kell lennie, ezért egy terméklistában minden kártya saját nevet kap, amelyet a gyakorlatban a sablon generál a termékazonosítóból. A böngésző a két oldal azonos nevű elemeit párosítja, majd kiszámolja közöttük a pozíció- és méretkülönbséget, így a kis kártyakép simán a nagy termékfotó helyére nő. A háttérben a régi és az új állapotról is kép készül, ezeket a ::view-transition-old() és a ::view-transition-new() álelemeken keresztül lehet CSS-sel tovább formázni. Mivel ezek lényegében képernyőfotók, nem pedig élő elemek, egy hosszú animáció alatt nem frissül a tartalmuk, ezért a jó átmenet mindig rövid.

Mikor indul el az átmenet és mikor nem?

A Chrome fejlesztői dokumentációja szerint a navigation: auto beállítás csak azonos eredetű oldalak között működik, vagyis a protokollnak, a domainnek és a portnak is egyeznie kell, így a saját webhelyedről egy külső oldalra mutató link nem animálódik. Az átmenet elindul a sima linkkattintásnál és a böngésző vissza-előre gombjainál, a címsorba beírt cím, a könyvjelző és az oldal újratöltése viszont nem váltja ki. A CSS-Tricks cikke ehhez hozzáteszi, hogy az űrlapok POST-kérései sem kapnak animációt, a korábbi, meta címkés bekapcsolási mód pedig már nem működik, noha sok régi útmutató még ma is azt mutatja.

Üzleti szempontból a legjobb hír az, hogy a funkció fokozatos fejlesztés (progressive enhancement). Ahol a böngésző nem ismeri, ott a látogató egyszerűen a megszokott oldalváltást látja, hibaüzenetet vagy szétesett oldalt nem, így a bevezetés kockázata szinte nulla.

Dokumentumok közötti és elemre szűkített átmenetek: mit hozott a Chrome 146 és 147?

A dokumentumok közötti átmenetek alapfunkcióként már a Chrome 126 óta működnek, a Google I/O 2026-os webes összefoglalója pedig a Chrome 146-nál sorolja fel őket az idei felületi újdonságok között. A Chrome 147 hozta el az elemre szűkített átmeneteket, amelyeknél csak az oldal egy kijelölt része animálódik, a többi közben kattintható marad.

A verziószámok a hírekben gyakran összemosódnak. A Chrome fejlesztői dokumentációjának támogatási táblázata szerint a dokumentumok közötti átmeneteket a Chrome és az Edge a 126-os, a Safari a 18.2-es verziótól kezeli, a Firefox viszont még nem, bár a CSS-Tricks 2026. májusi cikke szerint ott is fejlesztés alatt áll a támogatás. Ha tehát valahol azt olvasod, hogy ez a funkció a Chrome 146-tal érkezett, az a Google I/O 2026 alkalmából megjelent „New in web UI” összefoglaló kiemelésére utal, maga az alapfunkció ennél régebbi.

Egy magyar cégnek ebből egyetlen gyakorlati kérdés következik: a saját látogatói közül hányan használnak támogató böngészőt. Ezt két perc alatt megnézheted a Google Analytics 4 technológiai jelentéseiben, ahol böngészők szerint bontva látod a forgalmat. Ha a Chrome, az Edge és a Safari együtt a látogatóid nagy többségét adja, a befektetés a legtöbb vásárlónál látszani fog, a többiek pedig semmit sem veszítenek, mert nekik a megszokott oldalváltás marad.

A táblázat a Chrome for Developers dokumentációja, a Google I/O 2026-os összefoglaló és a CSS-Tricks cikke alapján készült, 2026. szeptember 22-i állapot szerint.

Mit tud az elemre szűkített átmenet?

Az elemre szűkített átmenet (element-scoped view transition) a Chrome 147-ben megjelent változat, amely a nézetátmenetet egyetlen oldalrészre korlátozza. A Google I/O 2026-os összefoglalója szerint a fejlesztő egy konkrét elemen hívja meg a startViewTransition() függvényt, a böngésző pedig csak ezen az elemen belül keresi a megnevezett részeket, az átmenet rétegét is erre az elemre helyezi, az oldal többi része pedig közben aktív és használható marad. Több ilyen átmenet futhat egyszerre, akár egymásba ágyazva is.

Hogy ez miért jó, azt egy képzeletbeli debreceni webshopon lehet a legjobban megmutatni. A vásárló a jobb oldali kosársávban töröl egy tételt, miközben a bal oldalon görgeti a terméklistát, a sarokban pedig nyitva van az élő chat ablak. Az elemre szűkített átmenettel csak a kosár tételei rendeződnek át animálva, a terméklista görgethető marad, a chatbe is lehet tovább gépelni, sőt ha közben a szűrőpanel is átrendeződik, a két animáció egymás zavarása nélkül futhat.

const kosar = document.querySelector('.kosar-lista');
function tetelTorlese(tetel) {
  const frissites = () => tetel.remove();
  // Chrome 147-től csak a kosár animálódik, máshol animáció nélkül törlünk
  if (kosar.startViewTransition) {
    kosar.startViewTransition(frissites);
  } else {
    frissites();
  }
}

Egy nem fejlesztőnek a kód lényege ennyi: ha a böngésző ismeri az új funkciót, a kosár animálva rendeződik át, ha nem ismeri, a tétel ugyanúgy eltűnik, csak mozgás nélkül. Ez a „ha van, használd, ha nincs, ne törj el” szemlélet az, amitől az ilyen fejlesztések kockázata alacsony marad.

Mi érkezett még a Chrome 146 és 147 körül?

A Google I/O 2026-os összefoglalója több rokon újdonságot is felsorol. A görgetésre induló animációk (scroll-triggered animations) a Chrome 146 óta JavaScript nélkül indítanak el egy CSS-animációt, amikor a látogató egy adott görgetési ponton túljut, a @starting-style szabállyal pedig egy felugró ablak vagy lenyíló menü is finoman úszhat be. Ezekről és a többi új CSS-funkcióról külön cikkünkben írunk részletesen, itt elég annyi, hogy a böngésző egyre több mozgást old meg olcsón, szkript nélkül.

Mit hoz a Next.js 16.3 Instant Navigations?

Az Instant Navigations a Next.js 16.3 bekapcsolható eszközcsomagja, amely a szerveren renderelt oldalakat is azonnal reagálóvá teszi: útvonalanként előre letölt egy újrahasznosítható oldalvázat, a lassabb részeket pedig fokozatosan tölti be. A Vercel célja, hogy a Next.js-oldalak úgy reagáljanak, mint egy egyoldalas alkalmazás, miközben megmaradnak a szerveroldali renderelés előnyei.

A Next.js a Vercel által fejlesztett, React-alapú webes keretrendszer, amelyre világszerte rengeteg webshop, SaaS-termék és céges portál épül. Az Instant Navigations mögötti problémát Andrew Clark és Josh Story, a Next.js fejlesztői, a 2026. június 25-i előzetes bejelentésben elég őszintén írták le. Egy szerveroldali alkalmazásban a navigáció három lépés: rákattintasz egy linkre, nem történik semmi, majd a szerver válaszol és megjelenik az új oldal. A szerzők szerint ez hírportálnál és blognál jól működhet, csak éppen „weboldal-érzése” van, nem pörgős. Az egyoldalas alkalmazásban ezzel szemben a kattintás után azonnal látszik a következő oldal váza, a tartalom pedig utána tölt be. A 16.3 augusztus 3-i bejelentése azt is elismeri, hogy a Server Components (a szerveren futó React-komponensek) kevesebb JavaScriptet küldenek a böngészőbe, cserébe viszont lassúnak érződő navigációt hoztak.

Stream, Cache vagy Block: három döntés útvonalanként

Az új modellben a fejlesztőnek minden olyan útvonalnál, amely a szerveren adatra vár, döntenie kell a három lehetőség közül. A Stream azt jelenti, hogy a lassú részt egy Suspense-határ (React-mechanizmus a töltési állapotok kezelésére) veszi körül, így a látogató azonnal lát egy betöltési állapotot, a tartalom pedig utána folyik be. A Cache esetén a 'use cache' direktíva egy korábban eltárolt változatot tesz azonnal elérhetővé. A Block a tudatos lemondás: az export const instant = false sorral a fejlesztő jelzi, hogy ezen az útvonalon inkább megvárja a szervert, mert például egy blogbejegyzésnél nem akar üres vázat mutatni.

A fontos újdonság az, hogy a döntés már nem maradhat el. Az Instant Insights nevű új fejlesztői eszköz fejlesztés közben hibaként jelez minden olyan navigációt, amely nem azonnali, mindegyikhez pedig kész utasítást is ad, amellyel egy AI-kódoló ügynök elvégezheti a javítást. A lassú oldal így nem tud észrevétlenül bekerülni az éles rendszerbe.

Útvonalanként egy oldalváz: a Partial Prefetching

A korábbi Next.js a képernyőn látható minden linkhez külön előtöltési (prefetch) kérést küldött a szervernek, ami görgetéskor valóságos kérésáradatot okozott. A júniusi bejelentésben a csapat saját fordításunkban így kommentálta a közösség visszajelzéseit: „Sokan jeleztétek, hogy ez nevetségesen fest. Őszintén szólva mi is így látjuk.” A 16.3 megoldása a Partial Prefetching, amely linkenként egy teljes oldal helyett útvonalanként egyetlen újrahasznosítható vázat tölt le előre, ezt pedig a böngésző a munkamenet végéig megőrzi.

A Vercel példája szerint ha egy oldalsávban húsz csevegésre mutató link van, a régi rendszer húsz külön kérést küldött, az új viszont egyetlen vázat kér le a teljes csevegés-útvonalhoz. Ha egy linknél ennél több tartalomra van szükség, a prefetch={true} beállítással linkenként is kérhető mélyebb előtöltés. A Next.js augusztus 18-i útmutatója viszont figyelmeztet, hogy ilyenkor a link már a képernyőre érkezéskor a szerverhez fordul, ezért csak ott érdemes használni, ahol a kész tartalom tényleg megéri a plusz kérést. A két új viselkedést a projekt beállításaiban két kapcsolóval lehet bekapcsolni:

// next.config.js
const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};
module.exports = nextConfig;

A Vercel szerint mindkét kapcsoló egy későbbi főverzióban alapértelmezett lesz, vagyis aki most áll át, az a keretrendszer jövőbeli irányába lép, nem egy mellékvágányra.

Fejlesztői eszközök, amelyek megőrzik a sebességet

Az Instant Insights mellett két további eszköz segít abban, hogy az azonnali navigáció később se romoljon el. A Navigation Inspector megállítja a navigációt a váz állapotában, így a fejlesztő pontosan látja, mit fog a látogató a kattintás utáni első pillanatban kapni. A Playwright nevű tesztelőeszközhöz készült instant() segédfüggvénnyel pedig olyan automatikus teszt írható, amely elbukik, ha egy módosítás után egy korábban azonnal megjelenő elem már csak késve jön. A Next.js 16.3 bejelentése konkrét példát is hoz: ha valaki a közös fejlécbe egy sütiket olvasó komponenst tesz, az egész útvonal kérésidejű renderelésre vált, a teszt pedig ezt azonnal kiszúrja.

Üzleti nyelvre fordítva ez minőségbiztosítás. Az oldalak sebessége jellemzően nem egyetlen rossz döntéstől romlik el, hanem apránként, sok kis módosítás összegeként, az ilyen tesztek pedig pont ezt a lassú kopást állítják meg. Hasonlóan hasznos a továbbfejlesztett inkrementális statikus újragenerálás (Incremental Static Regeneration, ISR): az a lap, amelyet a build során nem rendereltek előre, az első látogatónak is azonnali vázat mutat, majd a háttérben elkészül a teljes változat, amelyet a későbbi látogatók már a gyorsítótárból kapnak.

Optimista frissítés, megőrzött állapot és React-átmenetek

Aurora Scharff 2026. augusztus 18-i írása a Next.js blogján négy nyílt forráskódú mintaalkalmazáson mutatja be, hogyan áll össze mindez valódi alkalmazás-érzéssé. A Next Beats zenelejátszóban a lejátszás oldalváltáskor is folytatódik, mert a lejátszó állapota a közös elrendezésben (layout) él, amely navigáció közben nem töltődik újra. A kedvenc gomb optimista frissítéssel működik: a React useOptimistic funkciója azonnal átállítja a gombot, a mentés csak utána fut le, ha pedig a szerver hibát jelez, a React visszaáll az utolsó megerősített értékre és hibaüzenet jeleníthető meg.

Tegyük fel, hogy a debreceni webshopunk kívánságlistájánál ugyanez történik: a szív ikon a kattintás pillanatában kitöltődik, pedig a szerver még csak dolgozik a mentésen. A vásárló nem vár, nem kattint kétszer, nem gondolja, hogy „nem működik”. A ritka hibás esetben a szív visszaáll és megjelenik egy rövid üzenet, ami még mindig jobb élmény, mint minden egyes kattintásnál fél másodpercig bámulni egy mozdulatlan gombot.

Ugyanez az írás mutatja be a React saját ViewTransition komponensét is, amely a böngésző nézetátmeneteire épül. A mintaalkalmazásokban a betöltődő tartalom finom áttűnéssel váltja a helyőrzőt, egy kedvenc törlésekor a lista többi eleme simán csúszik a helyére, a Flow nevű naptáralkalmazás pedig irány szerint animál: előre lapozáskor a régi nézet balra, az új jobbról érkezik, visszafelé pedig fordítva. A példakód mindehhez 200 ezredmásodperces, 60 képpontos csúszást használ, ami jól mutatja, hogy a jó átmenet rövid és visszafogott.

Next.js 16.3: 90%-kal kevesebb memória fejlesztéskor, gyorsabb build

A Next.js 16.3 Turbopack-fordítója a Vercel szerint a next dev parancs futtatásakor akár 90%-kal kevesebb memóriát használ, mert alapból bekapcsolt lemezes gyorsítótárral és memóriakiürítéssel (memory eviction) dolgozik. A lemezes gyorsítótár a next build parancsnál is alapértelmezett lett, amitől egyes projektek buildje a folyamatos integrációs (CI) szervereken 5,5-szer gyorsabb.

A 2026. augusztus 3-i bejelentés szerint ez a keretrendszer legnagyobb frissítése a tavaly novemberi 16.0 óta, a teljesítményjavulások többsége pedig a meglévő alkalmazásokban is kódmódosítás nélkül jelentkezik. A Vercel saját mérései a következők:

A memóriaadat első ránézésre csak a fejlesztőket érdekli, pedig közvetlen üzleti hatása van. Egy 21,5 GB memóriát igénylő fejlesztői környezet egy átlagos, 16 GB-os laptopon egyszerűen nem fut kényelmesen, a gép lassul, a fejlesztő vár vagy újraindít. Ha ugyanez a projekt 2 GB-ból elvan, a fejlesztés gördülékenyebb lesz, a projekt miatt pedig nem kell a géppark cseréjén gondolkodni.

Mit ér a gyorsabb build egy céges projektnél?

A build az a folyamat, amely minden módosítás után a forráskódból előállítja az élesíthető weboldalt. Tegyük fel, hogy egy közepes céges Next.js-projekt buildje a CI-szerveren 4 percig tart, naponta pedig 12 alkalommal fut le (minden jóváhagyott módosításnál és előnézetnél), ez napi 48 perc. A nextjs.org 2,3-szoros arányával számolva egy build nagyjából 1,7 percre rövidül, a napi összeg 21 percre, így naponta kb. 27 perc, havi 21 munkanappal kb. 9,5 óra buildidő szabadul fel. A szerényebb, 1,4-szeres vercel.com/home aránnyal a megtakarítás napi kb. 14 perc. Ez saját becslés, a tényleges érték a projekt szerkezetétől függ.

Két helyen jelenik meg ez pénzként. Egyrészt a felhőalapú tárhelyek egy része a buildidő után számláz, a Vercel például a 2026. szeptember 21-i frissítése óta a telepítéseknél kiírja a számlázható időt és a CPU-perceket, így a rövidebb build közvetlenül a számlán látszik. Másrészt ha egy webshopban hibás ár kerül ki egy akció indulásakor, a javítás percekkel hamarabb lesz élő, ami egy forgalmas estén konkrét rendelésekben mérhető.

Apróbb újdonságok, amelyek a mindennapokban számítanak

A natív Node.js streamekre váltás miatt a Vercel mérései szerint az alkalmazások terhelés alatt akár 22%-kal több kérést szolgálnak ki, ami egy kampánycsúcsnál vagy egy hírlevél utáni rohamnál ugyanazon a szerveren több kiszolgált látogatót jelenthet. A next build a TypeScript 7-es verziójával is tud típusellenőrzést futtatni, amelyet a Next.js bejelentése a TypeScript tízszer gyorsabb natív átiratának nevez.

A 16.3 az AI-alapú fejlesztést is kiszolgálja. A next dev parancs a projektbe egy verzióhoz illő AGENTS.md blokkot ír, amely a kódoló ügynököket a telepített Next.js-verzió saját dokumentációjához irányítja, így kisebb az esély, hogy egy AI-asszisztens elavult megoldást javasoljon. Az új catchError funkcióval egyedi hibakezelő rész készíthető „Próbáld újra” gombbal, amely a hibás szerveroldali részt is újra le tudja kérni, a root params pedig egyszerűbbé teszi a nyelvi paraméter elérését, ami a magyar és angol nyelvű céges oldalaknál jól jön.

Ha frissítesz, ne a 16.3.0-s verziónál állj meg. A Next.js 2026. szeptember 22-én soron kívüli, kritikus biztonsági frissítést adott ki (16.3.6 és 15.5.26) egy külső függőség hibája miatt, a 16.3 pedig jelenleg az aktív hosszú távú támogatású (LTS) ág. A biztonsági kiadások részleteivel külön cikkünk foglalkozik.

Mennyi munka és mennyi pénz bevezetni?

A költség a kiinduló technológián múlik. Egy egyszerű, CSS-alapú áttűnés bármilyen weboldalon néhány fejlesztői óra, a termékképeket és fejléceket összekötő átmenetek egy-két nap, egy meglévő Next.js-alkalmazás átállítása az Instant Navigationsre viszont napoktól hetekig terjedő munka, mert közben a gyorsítótárazást is újra kell gondolni.

Az alábbi táblázat saját, durva becslés egy átlagos állapotú projektre, teszteléssel együtt, 10 000 Ft-os feltételezett fejlesztői óradíjjal számolva. Egy elhanyagolt, régi kódbázisnál a felső érték is kevés lehet, egy frissen épült oldalnál viszont gyakran az alsó sáv is elég.

Megtérül? Egy képzeletbeli webshop számai

Vegyünk egy képzeletbeli debreceni webshopot havi 25 000 látogatással, 1,6%-os konverziós aránnyal és 16 000 Ft-os átlagkosárral. Ez havi 400 rendelés és 6 400 000 Ft forgalom. Tegyük fel, hogy a termékkártyák és a termékoldalak közötti átmenetek, valamint az animált kosár a konverziót relatívan 2%-kal javítják, ami szándékosan jóval kevesebb a Deloitte-tanulmány 8,4%-ánál, hiszen az valódi sebességjavulást mért, nem animációt. Így havonta 408 rendelés lesz, a 8 plusz rendelés 128 000 Ft többletforgalmat hoz, ami 30%-os árrés mellett kb. 38 400 Ft havi fedezet.

A 120 000 Ft-os közös elemes átmenetprojekt ezzel a becsléssel nagyjából három hónap alatt térül meg, ami vállalható befektetés. Egy 800 000 Ft-os Instant Navigations-átállás viszont ugyanennél a forgalomnál kb. 21 hónap alatt hozná vissza az árát, tehát önmagában nem éri meg. Tízszeres forgalomnál, havi 250 000 látogatásnál már két hónap körüli a megtérülés, ezért a nagyobb átállás elsősorban a forgalmas webshopoknál és a naponta használt ügyfélportáloknál indokolt, a kisebbeknél pedig akkor, ha úgyis esedékes egy nagyobb átépítés.

WordPress, Webflow vagy Next.js: hol mennyi a munka?

A dokumentumok közötti átmenet ott a legolcsóbb, ahol egyetlen közös stíluslap szolgálja ki az összes oldalt, legyen szó WordPress-témáról, Webflow-webhelyről vagy egy Laravel-alapú egyedi tartalomkezelő közös sablonjáról. A Next.js App Routerre épülő oldalakon a React ViewTransition komponense és a 16.3 eszközei adják a természetes utat, ami több tervezést kíván, cserébe finomabban hangolható.

Bevezetés lépésről lépésre egy céges weboldalon

Az alábbi sorrend egy átlagos céges weboldalra vagy webshopra érvényes, a Next.js-specifikus lépéseket más rendszereknél egyszerűen átugorhatod.

• Mérd fel a kiindulást. Nézd meg a Google Search Console Core Web Vitals jelentését és a PageSpeed Insights eredményét, a Google Analytics 4-ben pedig a böngészők arányát és a jelenlegi konverziós arányt, mert később ehhez hasonlítasz.
• Előbb a sebesség, aztán az animáció. Ha a mobilos LCP több másodperc, a képek tömörítése, a betűtípusok és a tárhely rendbetétele többet hoz bármilyen átmenetnél, ráadásul a lassú oldalon a Chrome négy másodperc után úgyis kihagyja az animációt.
• Válaszd ki a két-három legfontosabb átmenetet. Olyan váltásokat keress, ahol a mozgás információt hordoz: terméklista és termékoldal, szobalista és szobaoldal, egy többlépéses ajánlatkérő űrlap lépései.
• Kezdd az egyszerű áttűnéssel. A fent bemutatott @view-transition szabályt a prefers-reduced-motion feltétellel együtt tedd be minden oldal közös stíluslapjába.
• Add hozzá a közös elemeket. A kiválasztott képek és fejlécek kapjanak view-transition-name nevet, amelyet a sablon generál, egy oldalon belül pedig egyik név se ismétlődjön.
• Tartsd rövidre. A Next.js mintaalkalmazásai 200 ezredmásodperces csúszást használnak, egy céges oldalon ennél sokkal hosszabb animációra ritkán van szükség.
• Next.js esetén előbb frissíts, aztán kapcsolj. Frissíts a 16.3 legfrissebb javítókiadására, egy tesztkörnyezetben kapcsold be a cacheComponents és a partialPrefetching beállítást, majd az Instant Insights jelzései alapján döntsd el útvonalanként, hogy Stream, Cache vagy Block legyen.
• Írj regressziós tesztet. A legfontosabb útvonalakra (főoldal, kategória, termék, kosár) készüljön instant() teszt, hogy egy későbbi módosítás ne lassíthassa le őket észrevétlenül.
• Tesztelj több böngészőben és lassú hálózaton. Nézd meg az oldalt Chrome-ban, Safariban és Firefoxban, mobilon, a fejlesztői eszközökben lassított hálózaton, valamint bekapcsolt mozgáscsökkentéssel is.
• Mérj legalább négy hétig. Hasonlítsd össze a konverziót, a munkamenetenkénti oldalszámot és a visszafordulási arányt a kiinduló számokkal, lehetőleg A/B teszttel. Az átmeneteket csak a mért eredmény alapján terjeszd ki további oldalakra.

Buktatók, amelyekbe a legtöbb projekt belefut

A nézetátmenetek hibái ritkán látványosak, inkább csendesek: az animáció egyszerűen elmarad, vagy a kelleténél furcsábban néz ki, a látogató pedig nem panaszkodik, csak kevésbé érzi profinak az oldalt. A leggyakoribb csapdák a következők:

• Csak az egyik oldal kapcsolta be. A CSS-Tricks szerint mindkét oldalnak jeleznie kell a részvételt, így ha a blog vagy a webshop külön sablonjából kimarad a szabály, az adott váltásnál nem lesz átmenet.
• Csendes időtúllépés. A Chrome négy másodperc után TimeoutError hibával kihagyja az átmenetet, a CSS-Tricks szerint erről a fejlesztő ritkán kap látható figyelmeztetést, ezért a lassú aloldalakon a hiba sokáig rejtve maradhat.
• Renderelést blokkoló trükkök. A Chrome dokumentációja szerint a blocking=render megoldást csak akkor szabad használni, ha a hatását mérik is, mert késleltetheti az első megjelenést, ez pedig az LCP-t is ronthatja.
• Torzuló képek. Mivel az átmenet képernyőfotókkal dolgozik, az eltérő képarányú képek megnyúlhatnak, amin a CSS-Tricks szerint az object-fit: cover beállítás segít az átmeneti álelemeken.
• Ismétlődő nevek. Ha egy oldalon két elem ugyanazt a view-transition-name nevet kapja, a böngésző nem tudja párosítani őket, az átmenet pedig elmarad.
• Túlanimálás. Ha minden elem repül és forog, a látogató elveszíti a fonalat, a CSS-Tricks szerzője szerint pedig a túlzott mozgás egyeseknél szó szerint rosszullétet okozhat.
• Túl agresszív előtöltés. Ha a Next.js-ben minden linkre bekapcsolják a prefetch={true} beállítást, az felesleges szerverterhelést okoz, ezért csak a valóban fontos linkeknél érdemes használni.
• Elcsúszó analitika. A Next.js-ben az oldalváltás eleve a böngészőn belül történik, ezért ellenőrizd, hogy a Google Analytics 4 és a hirdetési pixelek minden oldalmegtekintést rögzítenek-e, mert az egyedi követőkódoknál ez gyakori hiba.

Mikor éri meg egy céges oldalnál és mikor felesleges?

Akkor éri meg, ha a látogató sokat navigál ugyanazon a folyamaton belül, például terméklistából termékoldalra, szobáról szobára vagy lépésről lépésre egy foglalásban. Egy néhány oldalas bemutatkozó webhelyen csak az olcsó CSS-áttűnés indokolt, egy lassú oldalon pedig előbb a sebességet kell rendbe tenni, az animáció csak utána jöhet.

Az ítélet egyik lényeges következménye, hogy egy jól működő WordPress-oldalt nem érdemes pusztán az alkalmazás-érzés kedvéért Next.js-re átírni. A dokumentumok közötti CSS-átmenet a látható hatás jelentős részét töredék áron hozza, a keretrendszerváltás költségét pedig egy animáció soha nem fogja visszahozni. Aki viszont most tervez új webshopot, foglalási rendszert vagy ügyfélportált Next.js-re, annak az Instant Navigationst és a nézetátmeneteket eleve bele kell vennie a tervbe, mert utólag ugyanez jóval drágább.

A második következmény az, hogy az átmenet sosem pótolja a jó tartalmat és a világos szerkezetet. Ha a látogató nem találja meg a telefonszámot vagy az árakat, egy elegáns áttűnés csak szépen animálja a tanácstalanságát, ezért a sorrend mindig ugyanaz: érthető oldal, gyors oldal, csak utána gördülékeny oldal.

Hat a View Transitions a SEO-ra és a Core Web Vitals mutatókra?

Közvetlenül nem: a View Transitions nem rangsorolási tényező, az átmenet pedig nem változtat az oldal HTML-tartalmán, amelyet a Google és az AI-keresők feldolgoznak. Közvetve hathat, ha a hozzá tartozó trükkök lassítják az első megjelenést, a Next.js 16.3 valódi sebességjavulásai viszont a Core Web Vitals mutatóknak is jót tehetnek.

A Googlebot minden URL-t külön tölt le és dolgoz fel, így az oldalak közötti animációt sosem „látja”, csak a kész tartalmat. Ez a dokumentumok közötti átmenetek nagy előnye a régi, teljesen JavaScriptből renderelt egyoldalas alkalmazásokkal szemben, ahol a tartalom sokszor csak a szkript lefutása után jelent meg. A Next.js 16.3 szerveroldali megközelítése ugyanezt a biztonságot adja: az oldal tartalma a szerverről érkező HTML-ben van, ami a klasszikus keresőknek és a nagy nyelvi modelleket használó AI-keresőknek egyaránt jó hír.

A Core Web Vitals három mutatója közül az LCP a legérzékenyebb a rossz megvalósításra, ha a fejlesztő a szebb átmenet kedvéért visszatartja az első megjelenést. Az INP (a kattintásra adott reakcióidő) romolhat, ha egy gyenge telefonon nehéz JavaScript-animációk futnak, a CLS (a váratlan elcsúszások mértéke) pedig a rosszul sorrendezett betöltéstől. A Next.js augusztus 18-i útmutatója ezért azt javasolja, hogy az egymás alá kerülő, fokozatosan betöltődő részeket egymásba ágyazott Suspense-határokkal kezeld, így az oldal felülről lefelé, ugrálás nélkül rendeződik el. A változás hatását a Search Console Core Web Vitals jelentésében követheted, amely valós felhasználói adatokból dolgozik, ezért a javulás vagy romlás néhány hét alatt válik láthatóvá.

Miben segít a Convergo?

A Convergónál úgy építünk weboldalakat, hogy gyorsak és gördülékenyek legyenek, animációt pedig csak ott használunk, ahol az a látogatónak és a konverziónak is hasznos. Webdesign és weboldalkészítés szolgáltatásunkban (honlapkészítés 299 000 Ft/weboldal) a nézetátmeneteket már a tervezéskor beépítjük, webshop és online értékesítés projektjeinknél a termék- és kosárfolyamatra koncentrálunk, a programozás és egyedi fejlesztés keretében pedig meglévő Next.js-alkalmazások frissítését és Instant Navigationsre állítását is vállaljuk. Egy egyszerű oldalváltási áttűnés akár a 30 000 Ft/hó-s Support csomag három fejlesztői órájába is beférhet. Az első lépés egy ingyenes egyeztetés, ahol átnézzük az oldalad mostani sebességét és megmondjuk, melyik átmenet érné meg nálad.