Teljesítmény: hydration, payload, bundle

15.1A három front

15.2Hydration — és a késleltetett hidratálás

A 2. modulból: minden komponens lefut a szerveren, majd újra a kliensen. A hydration az a fázis, amikor a böngésző „ráköti” a JS-t a már megjelenített HTML-re. Nagy oldalon ez a legdrágább kliensoldali tétel — és a felhasználó ezt úgy éli meg, hogy látszik az oldal, de nem reagál.

A Nuxt erre két, egymásra épülő eszközt ad:

Lazy prefix — a kód később töltődik

<template>
  <!-- csak akkor tölti le a komponens kódját, amikor tényleg kell -->
  <LazyExportDialog v-if="dialogNyitva" />
</template>

Hidratálási stratégiák — ez a lényeg

<template>
  <!-- a hajtás alatti tartalom: csak amikor a nézetbe kerül -->
  <LazyActivityFeed hydrate-on-visible />

  <!-- másodlagos widget: amikor a böngésző ráér -->
  <LazyUsageChart hydrate-on-idle />

  <!-- nehéz szerkesztő: csak ha a felhasználó odamegy -->
  <LazyRichTextEditor hydrate-on-interaction="mouseover" />

  <!-- mobilon nem is kell -->
  <LazySidePanel hydrate-on-media-query="(min-width: 1024px)" />

  <!-- feltételhez kötve -->
  <LazyAdminTools :hydrate-when="isAdmin" />

  <!-- statikus tartalom: SOSEM hidratálódik — csak HTML marad -->
  <LazyMarketingFooter hydrate-never />
</template>

A stratégiák egymást kizárják (egy komponensre egy), és a komponens @hydrated eseményt bocsát ki, amikor aktiválódott — hasznos, ha mérni akarod.

A harmadik eszköz: kevesebb interaktív komponens

• <ClientOnly> fallbackkel (3. modul) — de emlékeztetőül: ez elveszi az SSR-t, tehát nem hydration-optimalizáció, hanem kompromisszum.
• ssr: false egész útvonalcsoportra (7. modul) — ahol nincs SEO-igény.
• Kevesebb reaktív adat. Egy 2000 soros táblázatot ne tegyél reaktívvá, ha csak megjeleníted: shallowRef vagy sima adat is elég.

15.3Payload

Az 5. modulból tudjuk, mi ez: a szerveroldali lekérések eredménye a HTML-be ágyazva. Két szempontból számít — méret (hálózat) és tartalom (szivárgás). A méretet így nézd meg:

curl -s https://app.pelda.hu/dashboard | wc -c
curl -s https://app.pelda.hu/dashboard | grep -o '__NUXT_DATA__.*' | wc -c

15.4Bundle — a Workers-limit

Itt jön a rész, ami Node-szerveren nem létezik. A Workernek mérethatára van, és a Nuxt-appok szerverkódja nem kicsi:

Mérés

# ① gyors méret-ellenőrzés, deploy nélkül
npx wrangler deploy --outdir bundled/ --dry-run
# Total Upload: 4231.61 KiB / gzip: 1180.23 KiB

# ② méret ÉS hidegindítási profil egyben (a 11.3-as CI-kapu)
npx wrangler check startup --config .output/server/wrangler.json \
  --outfile startup.cpuprofile

# ③ a KLIENS-bundle összetétele — mi hízott meg és miért
npx nuxi analyze

Mi fogyasztja el a Worker-bundle-t

Ha közelítesz a limithez

1. Nézd meg, mi van benne. A --dry-run --outdir kimenete elemezhető: a legnagyobb modulok általában azonnal látszanak.
2. Dinamikus import a ritka útvonalakra. A PDF-export, a CSV-generátor, az admin-eszközök nem kellenek minden kérésnél.
3. Cseréld a nehéz függőséget. A legtöbb nagy csomagnak van kisebb alternatívája, vagy kiváltható egy platform-képességgel (kép → Cloudflare Images, 13. modul).
4. Vágd szét több Workerre. Ha tényleg nem fér, a nehéz háttérmunka külön Workerbe kerülhet, és service bindinggel hívod. Ez egyben architekturális tisztulás is (9. modul „hagyd kint” listája).

15.5Hidegindítás

A Worker indulásakor lefut a globális scope: minden top-level import, minden modul-szintű kifejezés. Erre 1 másodperc a keret (2025 októberétől — korábban 400 ms volt). Ha ezt átléped, a deploy nem megy át.

// ✗ ez indulási időt fogyaszt, minden izolátum-indításnál
const nagyTablazat = buildLookupTable()          // modul-szinten fut le
const regexek = SZABALYOK.map(s => new RegExp(s))

// ✓ halaszd az első használatig
let _tabla: Lookup | null = null
function getTabla() { return _tabla ??= buildLookupTable() }

A wrangler check startup által kiírt .cpuprofile megnyitható a Chrome DevTools „Performance” fülén — ott látod, melyik modul kiértékelése mennyi időt vitt el. Ha az indulás gyanúsan magas, ez az egyetlen eszköz, ami megmondja, miért.

15.6SSR CPU-idő — Workers-en ez számla

A kérésenkénti CPU-idő nem csak limit, hanem árazási tényező. Ami belefér:

15.7Core Web Vitals — reális célok

15.8Teljesítmény-költségvetés

A számok akkor érnek valamit, ha a build elbukik, amikor átlépted őket. Kiindulási javaslat — igazítsd a saját appodhoz, de legyen:

# CI-lépés: méret + indulás + titok-keresés egyben (12.3)
npm run build
node scripts/verify-bundle.mjs          # wrangler check startup + 80%-os guard
grep -ril "sk_live\|SESSION_PASSWORD" .output/public/ && exit 1
echo "OK"

15.9Ellenőrizd magad