Server-Side Rendering (SSR) — co to i kiedy używać

01Server-Side Rendering (SSR) — strona renderowana na serwerze per request. Każdy użytkownik dostaje świeży HTML wygenerowany w momencie wejścia. Plus: dynamic content (zalogowany user, real-time data). Minus: wolniejsze niż statyczne, wymaga origin server (koszt).

02Client-Side Rendering (CSR) — strona renderowana w przeglądarce. Serwer wysyła HTML+JS, JS uruchamia React, renderuje content. Plus: bogata interaktywność. Minus: pusta strona przed JS (SEO killer), wolny pierwszy paint.

03Static Site Generation (SSG) — strona renderowana raz przy build. HTML statyczny na CDN. Plus: najszybszy LCP, najtańszy hosting (CDN), bezpieczne (brak DB query). Minus: dane się starzeją bez rebuild.

04Incremental Static Regeneration (ISR) — hybryda SSG + SSR. Strona statyczna na CDN, ale regeneruje się on-demand po update content (webhook z CMS). Plus: szybkość statyki + świeżość dynamicznej. Minus: trochę bardziej skomplikowane.

05Wybór per route w Next.js (App Router):

06**SSG (default)** dla: marketing pages, dokumentacja, blog posts, static product catalogs.

07**ISR** dla: e-commerce z często zmieniającymi się cenami, blog z dużym wolumenem, sites z user-generated content (komentarze).

08**SSR** dla: dashboardy z user-specific data, A/B testing, geo-targeting, real-time data (giełda, sport).

09**CSR (Client Components)** dla: heavy interactivity (formularze, edytory), animacje WebGL, real-time chats (WebSocket).

10Praktyczna rada: zacznij od SSG/ISR (90% przypadków), dodawaj SSR tylko tam gdzie naprawdę potrzeba (per-user data). Nadużywanie SSR oznacza 5-10x droższy hosting i wolniejszą stronę.

11Vercel automatically optimizuje. App Router decyduje per route na podstawie czy używasz dynamic functions (cookies, headers, params). Sprawdź `next build` output żeby zobaczyć która strona jest λ (SSR), ○ (SSG), ◐ (ISR).