Performance sprzedaje. Każde 100 ms opóźnienia to realna strata konwersji. Next.js 16 daje Ci pełną kontrolę nad cache — pytanie brzmi: czy wiesz, co robisz?

Źle ustawiony cache = stare dane, bugi i nerwy klientów.

Jak działa caching w Next.js 16?

Next.js cache’uje:

fetch()
Server Components
Routes (ISR)

Domyślnie działa tryb force-cache — fetch raz, zapamiętane, serwowane wszystkim.

3 tryby fetch()

force-cache (default)

await fetch('https://api.example.com/posts');

Używaj gdy:

blog
landing page
dokumentacja

Nie używaj gdy:

dane użytkownika
ceny
stany magazynowe

no-store

await fetch('https://api.example.com/user', {
  cache: 'no-store',
});

Zawsze świeże dane. Wolniej. Poprawnie.

revalidate

await fetch('https://api.example.com/products', {
  next: { revalidate: 60 },
});

Idealne dla ofert, rankingów i produktów.

Globalne sterowanie renderingiem

Wymuś SSR

export const dynamic = 'force-dynamic';

Wymuś SSG

export const dynamic = 'force-static';

ISR na poziomie strony

export const revalidate = 120;

Cache tags – game changer

Fetch z tagiem

await fetch('https://api.example.com/products', {
  next: { tags: ['products'] },
});

Revalidacja cache

import { revalidateTag } from 'next/cache';

revalidateTag('products');

Efekt:
CMS update → cache czyszczony → performance zostaje.

Najczęstsze błędy

❌ Cache danych użytkownika
❌ no-store wszędzie
❌ Brak strategii cache

Recommended setup

Blog → force-cache
CMS → revalidate
Produkty → revalidate + tags
User data → no-store
Auth → force-dynamic

TL;DR

Cache to przewaga.
Źle użyty — sabotaż.

W Netova cache planujemy zanim zaczniemy kodować.

Darmowa wycena twojej strony

Next.js 16 Caching & Revalidation - Jak NIE zabić performance