---
title: "Next.js 16 teljesítmény csapdák, amibe minden Vercel projekt belesétál"
description: "Öt konkrét Next.js 16 csapda, amit minden auditunkban látunk. Mind a 5 mérhető (LCP, TTFB, INP), és mind kódszintű hiba, nem konfig. Példák, javítás, előtte/utána számok."
date: 2026-04-26T14:00:00.000Z
updated: 2026-04-26T14:00:00.000Z
author: "Mező Dezső"
tags: "Next.js, Performance, Vercel, Web Vitals, React"
slug: nextjs-16-teljesitmeny-csapdak
canonical: https://dfieldsolutions.hu/blog/nextjs-16-teljesitmeny-csapdak
---
# Next.js 16 teljesítmény csapdák, amibe minden Vercel projekt belesétál
5 csapda, kódszintű, nem konfig. Mind benne volt minden auditban az utóbbi 4 hónapban. Konkrét javítás kódban.
Next.js 16 ban (2026 elején GA) sok új koncepció van, és az `useState` használat egy része ami működött 14 ben, 16 ban szétdől. Az utóbbi négy hónapban hat különböző Vercel projekt audit ját csináltuk meg, és mindenhol ott volt ugyanaz az 5 csapda. Ezek nem konfig dolgok, kódszintű hibák, és mind mérhető.
Mielőtt elkezdesz olvasni: a hivatalos `node_modules/next/dist/docs/` t mindig nézd át, mert a Next.js 16 ban a 14 es API ról a 15 ön át a 16 ig sok minden megváltozott. A példák itt 16 specifikusak.
## 1. `use cache` és Suspense interakció · az LCP gyilkos
A `use cache` direktíva 16 ban hivatalos. A csapda: ha egy `use cache` jelölt komponensen belül `Suspense` boundary van, a cache nem terjed le, és a stream két külön részre szakad. Ez fizikailag jó (a felső rész gyors), de az LCP elem gyakran a Suspense boundary mögött van · az eredmény: cached oldal, nem cached LCP.
```tsx
// Rossz · 16 ban LCP nő, a hero kép a Suspense ben van
async function Page() {
"use cache";
return (
}>
{/* LCP elem · a use cache nem fedi le */}
);
}
// Jó · az LCP elemet kihúzzuk a Suspense ből, a hosszú lekérdezést tesszük be
async function Page() {
"use cache";
const heroData = await fetchHero();
return (
}>
);
}
```
Egy webshop projekten LCP 2.8s ről 1.2s re esett a refaktorral. INP nem változott.
## 2. 'use client' boundary szivárgás · a JS bundle duplázódik
A 14 ben már volt ez a csapda, 16 ban rosszabb, mert a partial prerendering miatt a határok cseppfolyósabbak. Tipikus hiba: egy `'use client'` jelölt komponens importál egy server only modult (pl. egy `db.ts` t), ami megint importál szerver oldali utility ket. Ez a 16 ban nem dob fordítási hibát, hanem a szerver oldali kódot is bekapja a kliens bundle be.
```ts
// lib/db.ts · csak szerver, mert a `pg` import szerver only
import { Pool } from "pg";
export const pool = new Pool();
// components/cart-button.tsx · 'use client'
"use client";
import { pool } from "@/lib/db"; // csendes szivárgás 16 ban
// ...
// Javítás · markold a server only modult
// lib/db.ts
import "server-only"; // most már fordítási hibát dob, ha kliensből importálják
import { Pool } from "pg";
export const pool = new Pool();
```
Egy SaaS dashboard nál a kliens JS bundle 940 kB ról 320 kB ra esett, miután mind a 6 szivárgást megtaláltuk. INP 380 ms ről 120 ms re.
## 3. Partial Prerendering ellen ható `dynamic = 'force-dynamic'`
A PPR (Partial Prerendering) 16 ban opt out, nem opt in. Ha bárhol az route segmentben van `export const dynamic = 'force-dynamic'`, a teljes route kibukik a PPR ből, és minden request szerver oldalon teljesen renderelődik. Sok régi kódbázisban ez ott maradt egy korábbi debug ülésről.
```ts
// Audit script · keresd meg az összes force-dynamic t
// terminálban: grep -r "force-dynamic" src/app | wc -l
// ha > 5, valószínűleg fél tucatban felesleges
```
Egy magyar webshop projekten 14 db `force-dynamic` exportot találtunk. Hét volt indokolt (admin, fiók, kosár), hét felesleges (egy-egy debug ülésen valaki bedobta). A felesleges hét eltávolítása a TTFB t 280 ms ről 90 ms re vitte le a publikus oldalakon, mert a HTML újra cache elhetővé vált a Vercel edge n.
## 4. Képoptimalizálás · az új AVIF/JXL fallback rendje
A 16 ban a `next/image` beépített AVIF támogatást kapott (a 14 csak WebP volt default). A csapda: ha a `next.config.ts` ban a `formats: ['image/webp']` ott maradt egy régebbi beállításból, az AVIF nem generálódik. Az új böngészők (97% lefedettség 2026 ban) AVIF re mennének, és 30-40% kal kisebb képet kapnának.
```ts
// next.config.ts
import type { NextConfig } from "next";
const config: NextConfig = {
images: {
formats: ["image/avif", "image/webp"], // sorrend számít
minimumCacheTTL: 60 * 60 * 24 * 30, // 30 nap
qualities: [40, 60, 80], // 16 új feature
},
};
export default config;
```
Egy hírportál projekten az LCP 1.8s ről 1.1s re esett a fenti egyetlen config változással + a `next/image` `quality={60}` használattal a hero képeken.
## 5. Route segment config félreértés · a `revalidate` öröklődés
Ez a klasszikus, ami a 14 ben még meglepetést okozott, és a 16 ban is. Ha egy szülő layout ban `export const revalidate = 60`, és egy gyerek page ben `export const revalidate = 3600`, a gyerek értéke érvényesül · de csak a `page.tsx` re. A layout maga 60 másodpercen revalidálódik, és a gyerek `page.tsx` is, mert a layout cache invalidálása lehúzza a gyermeket is.
A javítás: ne tegyél `revalidate` t layoutba, ha nem akarod, hogy mindenre érvényes legyen. A pageonkénti finomhangolást a `page.tsx` ben tartsd.
> **WARN:** Mind az 5 csapdát egy `next build && next start` futás közben fail2 grep el meg lehet találni. A bundle analyzer (`@next/bundle-analyzer`) plusz egy lighthouse audit elég. Ha a futási idő nem 2-3 nap, a saját kódbázisod nem ezekre szakad rá, hanem mélyebb dolgokra.
## Mit csinálj most
1. `grep -r "force-dynamic" src/app | wc -l` · ha 5 felett, audit szükséges.
2. `@next/bundle-analyzer` futtatása production buildben, kliens bundle > 350 kB ha · kliens szivárgás van.
3. Lighthouse / WebPageTest a 3 legfontosabb route on, LCP > 2.0s ha · use cache + Suspense interakció.
4. `next.config.ts` ban formats szótár ellenőrzés, AVIF benne van e.
5. Layout fájlokban revalidate audit, csak ott legyen, ahol valóban kell.
---
Source: https://dfieldsolutions.hu/blog/nextjs-16-teljesitmeny-csapdak
Author: Mező Dezső · Alapító, DField Solutions
Site: https://dfieldsolutions.hu