Utilizziamo i cookie per migliorare la tua esperienza sul sito
CodeWorlds

Renderowanie w Next.js - przegląd strategii

W Metropolii Quantum informacje docierają do mieszkańców na różne sposoby - holograficzne ekrany na ulicach wyświetlają treści w czasie rzeczywistym, tablice informacyjne generują zawartość z wyprzedzeniem, a osobiste terminale pobierają dane na żądanie. Podobnie, Next.js oferuje kilka strategii renderowania stron, z których każda ma swoje zastosowanie.

W tym rozdziale poznasz cztery główne strategie renderowania w Next.js. Nie będziemy wchodzić w głębokie szczegóły techniczne - to temat na moduł 5. Na razie chcemy, żebyś rozumiał, że te strategie istnieją i wiedział, kiedy każda z nich ma sens.

Czym jest renderowanie?

Renderowanie to proces zamiany kodu React (JSX) na HTML, który przeglądarka może wyświetlić użytkownikowi. Kluczowe pytanie brzmi: gdzie i kiedy ten proces się odbywa?

1// Ten komponent React...
2export default function Hello() {
3  return <h1>Witaj w Metropolii Quantum!</h1>;
4}
5
6// ...zostaje zamieniony na HTML:
7// <h1>Witaj w Metropolii Quantum!</h1>

W zależności od wybranej strategii, ta zamiana może nastąpić:

  • Na serwerze - zanim strona dotrze do przeglądarki
  • W przeglądarce - po pobraniu kodu JavaScript
  • Podczas budowania - jeszcze przed uruchomieniem serwera

SSR - Server-Side Rendering (renderowanie po stronie serwera)

Wyobraź sobie, że w Metropolii Quantum holograficzny ekran generuje obraz w centrum sterowania i przesyła gotowy hologram do wyświetlenia. Użytkownik widzi kompletny obraz natychmiast po otwarciu transmisji.

SSR oznacza, że serwer renderuje stronę HTML przy każdym żądaniu użytkownika. Gdy ktoś wchodzi na stronę, serwer:

  1. Pobiera potrzebne dane (z bazy danych, API)
  2. Generuje kompletny HTML
  3. Wysyła gotową stronę do przeglądarki
1// Server Component w Next.js - domyślnie renderowany na serwerze
2export default async function DashboardPage() {
3  // Dane pobierane przy KAŻDYM żądaniu
4  const stats = await fetch('https://api.quantum.com/stats');
5  const data = await stats.json();
6
7  return (
8    <div>
9      <h1>Panel Quantum</h1>
10      <p>Aktywni użytkownicy: {data.activeUsers}</p>
11      <p>Ostatnia aktualizacja: {data.timestamp}</p>
12    </div>
13  );
14}

Kiedy używać SSR?

  • Gdy dane zmieniają się często (np. panel użytkownika, koszyk zakupów)
  • Gdy treść musi być aktualna przy każdym odświeżeniu
  • Gdy potrzebujesz SEO dla dynamicznych treści

SSG - Static Site Generation (generowanie statycznych stron)

W Metropolii Quantum tablice informacyjne z rozkładem jazdy są drukowane raz dziennie i wywieszane na przystankach. Nie zmieniają się co sekundę - są przygotowane z wyprzedzeniem.

SSG oznacza, że strony HTML są generowane podczas budowania aplikacji (`next build`), a nie przy każdym żądaniu. Gotowe strony są serwowane natychmiast z CDN.

1// Strona generowana statycznie podczas build
2export default function AboutPage() {
3  return (
4    <div>
5      <h1>O Metropolii Quantum</h1>
6      <p>Założona w 2150 roku jako centrum technologii przyszłości.</p>
7      <p>Populacja: 12 milionów mieszkańców.</p>
8    </div>
9  );
10}
11// Ta strona nie wymaga danych dynamicznych
12// Next.js wygeneruje ją raz podczas 'next build'

Kiedy używać SSG?

  • Blog, dokumentacja, strona "O nas"
  • Treści, które rzadko się zmieniają
  • Gdy priorytetem jest maksymalna szybkość ładowania

CSR - Client-Side Rendering (renderowanie po stronie klienta)

Osobiste terminale mieszkańców Metropolii Quantum pobierają surowe dane i renderują interfejs lokalnie - każdy terminal sam tworzy obraz na swoim ekranie.

CSR oznacza, że przeglądarka pobiera kod JavaScript i sama renderuje stronę. Serwer wysyła pusty HTML z dołączonym skryptem JS.

1"use client";
2
3import { useState, useEffect } from 'react';
4
5export default function LiveChat() {
6  const [messages, setMessages] = useState([]);
7
8  useEffect(() => {
9    // Dane pobierane w przeglądarce po załadowaniu komponentu
10    fetch('/api/messages')
11      .then(res => res.json())
12      .then(data => setMessages(data));
13  }, []);
14
15  return (
16    <div>
17      <h2>Quantum Chat</h2>
18      {messages.map(msg => (
19        <p key={msg.id}>{msg.text}</p>
20      ))}
21    </div>
22  );
23}

Kiedy używać CSR?

  • Interaktywne elementy (czat, formularze, dashboardy real-time)
  • Gdy SEO nie jest potrzebne dla danej sekcji
  • Gdy komponent wymaga dostępu do API przeglądarki (localStorage, geolokalizacja)

ISR - Incremental Static Regeneration (przyrostowa regeneracja statyczna)

W Metropolii Quantum tablice informacyjne mają tryb automatycznej aktualizacji - są statyczne, ale co określony czas (np. co godzinę) system sprawdza, czy nie ma nowych danych i generuje zaktualizowaną wersję.

ISR łączy zalety SSG (szybkość) z SSR (aktualność). Strona jest generowana statycznie, ale automatycznie regenerowana po określonym czasie.

1// Strona z ISR - statyczna, ale regenerowana co 60 sekund
2export default async function ProductsPage() {
3  const res = await fetch('https://api.quantum.com/products', {
4    next: { revalidate: 60 } // Regeneruj co 60 sekund
5  });
6  const products = await res.json();
7
8  return (
9    <div>
10      <h1>Produkty Quantum Store</h1>
11      {products.map(p => (
12        <div key={p.id}>
13          <h3>{p.name}</h3>
14          <p>{p.price} kredytów</p>
15        </div>
16      ))}
17    </div>
18  );
19}

Kiedy używać ISR?

  • Sklep internetowy (produkty zmieniają się, ale nie co sekundę)
  • Strona z artykułami/newsami
  • Gdy chcesz szybkość SSG, ale z aktualizacjami

Prosty diagram mentalny - którą strategię wybrać?

Oto prosty schemat decyzyjny, który pomoże ci wybrać odpowiednią strategię:

1Czy treść zmienia się przy każdym żądaniu?
2  TAK → Czy potrzebujesz SEO?
3          TAK → SSR (renderowanie na serwerze)
4          NIE → CSR (renderowanie w przeglądarce)
5  NIE → Czy treść zmienia się co jakiś czas?
6          TAK → ISR (statyczna z regeneracją)
7          NIE → SSG (w pełni statyczna)

| Strategia | Szybkość | Aktualność danych | SEO | Przykład użycia | |-----------|----------|-------------------|-----|-----------------| | SSG | Najszybsza | Dane z momentu budowania | Tak | Blog, dokumentacja | | ISR | Bardzo szybka | Odświeżane co X sekund | Tak | Sklep, newsy | | SSR | Szybka | Zawsze aktualne | Tak | Dashboard, profil | | CSR | Zależy od klienta | Pobierane na żywo | Nie | Czat, formularze |

Co dalej?

W module 5 tego kursu zagłębimy się w szczegóły techniczne każdej strategii renderowania. Nauczysz się:

  • Jak dokładnie konfigurować SSR i ISR w App Router
  • Jak optymalizować wydajność renderowania
  • Jak łączyć różne strategie w jednej aplikacji
  • Zaawansowane wzorce z React Server Components

Na razie najważniejsze jest, żebyś zapamiętał, że Next.js daje ci wybór - nie musisz renderować wszystkiego w jeden sposób. Każda strona, a nawet każdy komponent, może używać innej strategii.

Podsumowanie

Metropolia Quantum pokazuje nam, że różne systemy dostarczania informacji mają różne zastosowania. Podobnie w Next.js:

  1. SSR - serwer renderuje stronę przy każdym żądaniu (dane zawsze aktualne)
  2. SSG - strona generowana raz podczas budowania (najszybsza)
  3. CSR - przeglądarka renderuje stronę po pobraniu JS (interaktywność)
  4. ISR - statyczna strona z automatyczną regeneracją (kompromis szybkości i aktualności)

Zrozumienie tych strategii to fundament pracy z Next.js. W kolejnych modułach będziesz je stosować w praktyce, budując coraz bardziej zaawansowane aplikacje w Metropolii Quantum.

Vai a CodeWorlds