Next.js 15 w produkcji — co naprawdę się liczy

Co naprawdę liczy się w Next.js 15 na produkcji?

Na produkcji w Next.js 15 liczy się nie sama wersja frameworka, tylko model renderowania, strategia cache i przewidywalność zachowania po deployu. App Router z React Server Components pozwala serwować HTML z danymi po stronie serwera, co wspiera SEO i skraca czas do pierwszego sensownego contentu — pod warunkiem, że nie owijasz całej strony dyrektywą use client. Kluczowe decyzje to podział na treść statyczną, ISR z revalidate, segmenty dynamiczne przez cookies lub auth oraz invalidacja cache tagami po zmianie w CMS albo panelu admina. Równie ważne są obserwowalność: logi, odsetek odpowiedzi 5xx, czas TTFB oraz parity środowisk, czyli te same zmienne i ten sam runtime co w lokalnym smoke teście. Next.js 15 w produkcji to dyscyplina granic serwer–klient i świadomy cache, a nie checklista nowinek z changelogu. Bez tego „nowy Next” tylko drożej hostuje te same problemy.

Jak dzielić RSC i client islands, żeby nie spalić wydajności?

Domyślnie trzymaj komponenty jako Server Components i schodź do klienta tylko tam, gdzie potrzebna jest interakcja przeglądarki: kontrolowane formularze, gesty, animacje zależne od scrolla albo Web API. Wyspy klienckie powinny być małe i liściaste — na przykład filtr portfolio albo accordion FAQ — zamiast jednego ClientLayout obejmującego całą stronę i nawigację. Dane pobieraj blisko serwera w RSC lub route handlerach, a do klienta przekazuj już gotowe, serializowalne propsy; unikaj wodospadu fetchy w useEffect dla treści krytycznych pod SEO. Po buildzie analizuj bundle: każdy zbędny import w pliku oznaczonym use client ciągnie zależności do przeglądarki użytkownika. Jeśli sekcja jest czysto prezentacyjna, zostaw ją na serwerze — zyskujesz mniejszy JavaScript i prostszy model bezpieczeństwa, bo sekrety nie trafiają do klienta. Ta granica serwer–klient to najtańsza dźwignia wydajności w App Routerze i najczęstsze źródło regresji po „szybkim fixie”.

Jak ustawić cache i revalidację, żeby treść była świeża bez pełnego rebuildu?

Świeżość bez pełnego rebuildu daje połączenie generowania statycznego z rewalidacją czasową albo tagowaną. Strony typu usługi, cennik czy case study mogą żyć z revalidate rzędu minut lub godzin; po edycji w adminie wywołujesz revalidatePath albo revalidateTag, żeby unieważnić tylko właściwy fragment cache. Unikaj globalnego force-dynamic na wszelki wypadek — to podnosi koszt hostingu i TTFB bez korzyści dla stron w pełni publicznych. Personalizacja i sesja wymagają segmentów dynamicznych, ale publiczne listingi zwykle nie. Po deployu sprawdź nagłówki cache i zachowanie CDN: czy HTML nie zostaje przyklejony ze starą listą wpisów. Dobry test to zmiana treści w CMS, odświeżenie URL i pomiar, czy zmiana wchodzi w zadeklarowanym oknie; jeśli nie, problem leży w tagach albo warstwie edge, nie w samym frameworku. Dopiero gdy ten test przechodzi, warto dokładać kolejną warstwę złożoności cache’u albo edge rules.