Jakie są wady renderowania po stronie serwera (SSR)?

Główne wady SSR:

• Zwiększone obciążenie serwera: Każde żądanie klienta wymaga pełnego renderowania strony na serwerze, co zużywa więcej zasobów (CPU, pamięć) w porównaniu do serwowania plików statycznych lub SPA.
• Złożoność rozwoju: Konieczne jest uwzględnienie izomorfizmu kodu (praca na serwerze i kliencie), zarządzanie stanem między żądaniami, obsługa danych asynchronicznych. Debugowanie może być trudniejsze.
• Przerwy w działaniu przy błędach serwera: Jeśli główny serwer renderujący ulegnie awarii, strona może stać się niedostępna, w przeciwieństwie do SPA, gdzie klient może kontynuować pracę z zasobami w pamięci podręcznej lub stronami fallback.
• Dłuższy czas do interaktywności (TTI): Chociaż pierwszy content pojawia się szybciej (FCP), użytkownik nie może wchodzić w interakcję z aplikacją, dopóki cały JavaScript (hydration) nie zostanie załadowany i wykonany na kliencie. W SPA interaktywność może pojawić się wcześniej na już załadowanych częściach strony.
• Złożoność cache: Cache'owanie dynamicznie generowanego HTML jest trudniejsze niż zasobów statycznych. Wymaga to bardziej wyrafinowanych strategii cache'owania po stronie serwera.
• Wyższy czas pierwszego bajtu (TTFB): Serwer potrzebuje czasu na obsługę żądania, pobranie danych, renderowanie HTML i wysłanie pierwszego bajtu z powrotem do klienta.
• Mogą wystąpić problemy z kodem izomorficznym: Niektóre API klienta (np. window, document) są niedostępne na serwerze, co wymaga pisania kodu warunkowego lub korzystania z bibliotek specjalnych.

// Przykład warunkowego renderowania na serwerze
if (typeof window === 'undefined') {
  // Kod wykonywany tylko na serwerze
  console.log('Renderowanie na serwerze');
} else {
  // Kod wykonywany tylko na kliencie
  console.log('Renderowanie na kliencie');
}