← Wszystkie tematy W 6% ogłoszeń · 3 z 47 ogłoszeń frontend React

Renderowanie po stronie serwera

Kanapka podana gotowa vs składniki do złożenia

Renderowanie po stronie serwera pojawia się w 3 z 47 ogłoszeń wprost, a pośrednio przy każdym Next.js. Pytania dotyczą kompromisów i nowego streamingu z Suspense.

Przerobione Opanowane 0 z 3 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Bardzo dobra znajomość Next.js i doświadczenie z aplikacjami SSR”
GS Services · Frontend Engineer | React + Next.js
„Design and ship production Next.js SSR applications with complex state, high-load scenarios, and real-time AI interactions at scale”
Shelf · Senior Frontend React Developer
„Drive the architecture and delivery of personalized conversion pages and funnels using React, TypeScript, and Next.js, spanning SSR middleware design through to edge-layer caching strategies.”
HelloFresh · Senior Frontend Engineer, Conversions (all genders)

Scena · CSR, SSR i streaming

Kanapka podana gotowa

Zamawiasz kanapkę z czterech warstw: chleb, ser, sałata i sos, który robi się najdłużej. CSR: dostajesz pusty talerz i przepis, i składasz sam. Klasyczny SSR: kucharz składa całą kanapkę i podaje ją dopiero, gdy gotowy jest najwolniejszy sos. Streaming SSR: kucharz od razu podaje chleb z miejscami na resztę (Suspense) i dokłada warstwy, gdy są gotowe. Otwórz stronę w każdym trybie.

Sklep z lizakami

Lizak truskawkowy3 zł · dodaj do koszyka

Opinie„Najlepszy lizak świata” · 5/5

Polecane dla Ciebiecola · mięta · malina

pierwszy widok: –
cała strona: –
można klikać produkt: –

CSR SSR klasyczny streaming SSR

0,0 s

Otwórz stronę w trzech trybach i porównaj czasy.

Porównajmy

Co SSR daje, a co zabiera?

	Co zyskujesz	Za co płacisz
Pierwszy widok	Gość od razu widzi kanapkę.Lepsze FCP i LCP, treść w HTML.	Kucharz musi poczekać na składniki.Wolne dane = wolny TTFB (chyba że streaming).
Wyszukiwarki i linki	Robot Google i podgląd linku widzą treść.SEO, Open Graph, mniej zależności od JS.
Klikanie		Kanapka wygląda gotowa, ale gryźć można dopiero po ożywieniu.Hydratacja kosztuje JS i czas, ryzyko hydration mismatch.
Serwer		Potrzebna kuchnia, która pracuje przy każdym gościu.Koszt i skalowanie serwera Node, cache, cold starty.
Kod		Trzeba pamiętać, gdzie co działa.Brak window/localStorage na serwerze, rozdział danych serwer/klient.

Gotowa kanapka

SSR wysyła gotowy HTML, więc gość widzi treść zanim dojedzie JS.

Najwolniejszy sos

Klasyczny SSR czeka na najwolniejsze dane. Jeden wolny kawałek blokuje całość.

Warstwa po warstwie

Streaming z Suspense wysyła stronę kawałkami, każdy z własnym zamiennikiem.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Jakie problemy rozwiązuje SSR i jakie wprowadza?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Kucharz podaje gotową kanapkę, więc od razu widzisz, co jesz. Ale kucharz musi stać w kuchni przy każdym gościu, a ugryźć można dopiero, gdy kanapka „ożyje”.

Na rozmowę: Rozwiązuje: szybszy pierwszy widok (FCP, LCP), treść w HTML dla SEO i podglądów linków, działanie bez JS dla podstawowej treści. Wprowadza: koszt i skalowanie serwera, TTFB zależny od najwolniejszych danych, hydratację (JS i tak musi dojechać, a strona przez chwilę wygląda na gotową, ale nie reaguje), ryzyko hydration mismatch, ograniczenia kodu (brak window i localStorage na serwerze), trudniejsze cache’owanie spersonalizowanych stron.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Co to streaming SSR i jak pomaga mu Suspense?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Kucharz od razu podaje chleb z pustymi miejscami na resztę i dokłada ser, sałatę i sos, gdy każde jest gotowe. Nie czeka na najwolniejszy sos.

Na rozmowę: Serwer wysyła HTML kawałkami w jednej odpowiedzi (renderToPipeableStream / renderToReadableStream). Granice <Suspense> wyznaczają miejsca, gdzie najpierw idzie fallback (skeleton), a gdy dane async komponentu są gotowe, serwer dosyła jego HTML z małym skryptem, który podmienia fallback. Do tego selektywna hydratacja: kawałki ożywają niezależnie, a React priorytetyzuje ten, w który użytkownik kliknął. W Next.js App Router to loading.tsx i Suspense wokół wolnych Server Components.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Kiedy wybrać SSR, a kiedy wystarczy SPA (CSR) albo generowanie statyczne?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gotową kanapkę z kuchni dajesz gościom z ulicy. Dla domowników, którzy i tak siedzą przy stole cały dzień, wystarczą składniki.

Na rozmowę: SSR: strony publiczne z SEO i danymi zmiennymi lub personalizowanymi (sklep, wyszukiwarka, profil). SSG/ISR: treść wspólna dla wszystkich i rzadko zmienna (blog, landing, dokumentacja, karty produktów z revalidacją). CSR/SPA: aplikacje za logowaniem, gdzie SEO nie ma znaczenia, a użytkownik siedzi długo (panel admina, edytor, dashboard), z prostszym hostingiem statycznym. Często miesza się tryby per trasa, np. w Next.js czy Astro.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

TTFB rośnie z 200 ms do 2 s, gdy rośnie ruch

Serwis informacyjny renderuje każdą stronę na serwerze przy każdym żądaniu. Przy normalnym ruchu TTFB to 200 ms, ale gdy artykuł trafia na Facebooka, rośnie do 2 s, a CPU serwerów Node jest na 100%. Dodawanie maszyn pomaga tylko trochę.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy wiesz, że SSR jest operacją CPU i blokuje event loop
Czy szukasz cache zamiast samego skalowania
Czy umiesz zmierzyć, gdzie idzie czas renderowania

Odpowiedź seniora

renderToString jest synchroniczny i obciąża CPU, a Node ma jeden wątek na proces, więc przy dużej liczbie jednoczesnych renderów żądania stoją w kolejce. Najpierw mierzę: czas pobierania danych a czas renderowania (Server-Timing, profilowanie --cpu-prof, APM).

Artykuł jest taki sam dla wszystkich, więc nie powinien być renderowany przy każdym żądaniu. Cache na CDN z s-maxage i stale-while-revalidate albo ISR z revalidacją na żądanie z CMS-a po publikacji lub edycji. Wtedy serwer renderuje artykuł raz na kilka minut, a nie tysiące razy. Personalizację (zalogowany, licznik powiadomień) dociągam na kliencie albo w osobnym fragmencie, żeby nie psuła cache.

Do tego: streaming (renderToPipeableStream) skraca czas do pierwszego bajtu, cięższe części za Suspense, deduplikacja zapytań do API w obrębie żądania, a gdy skalujemy, to po liczbie żądań, nie tylko CPU. Cel: p95 TTFB poniżej 300 ms przy 10-krotnym ruchu, sprawdzony testem obciążeniowym.

Typowe wpadki

Tylko dokładanie serwerów
Cache całej strony z danymi zalogowanego użytkownika
Brak pomiaru, czy czas idzie w render, czy w API

Dopytają o

Jak unieważnisz cache po poprawce literówki w artykule?
Kiedy SSG byłoby lepsze niż cache SSR?
Jak wykryjesz komponent, który renderuje się najwolniej?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Strategia renderowania dla dużego sklepu

Przebudowujecie sklep z 200 tysiącami produktów na Next.js. Są strony: główna, kategorie z filtrami, produkty, wyszukiwarka, koszyk, konto, blog. Ceny zmieniają się kilka razy dziennie, stany magazynowe co minutę. Masz zaproponować sposób renderowania dla każdego typu strony.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy dobierasz strategię do typu strony, a nie jedną dla wszystkich
Czy uwzględniasz SEO, świeżość danych, koszty i czas budowania
Czy oddzielasz dane szybko zmienne od wolno zmiennych

Odpowiedź seniora

Blog i strony informacyjne: SSG, przebudowa po publikacji. Strona główna i kategorie: ISR z krótkim revalidate albo revalidacją po tagach, bo są ważne dla SEO i takie same dla wszystkich. Filtry w kategorii przez parametry w URL, z cache popularnych kombinacji i noindex dla rzadkich kombinacji, żeby nie produkować milionów stron.

Produkty: 200 tysięcy stron nie zbuduję przy każdym deployu, więc generuję statycznie tylko najpopularniejsze, a resztę na żądanie z ISR (generowanie przy pierwszym wejściu). Opis i zdjęcia z cache, a cena i stan magazynowy jako osobny, szybko odświeżany fragment: streamowany przez Suspense albo dociągany na kliencie z krótkim cache, z revalidacją po tagu przy zmianie ceny.

Wyszukiwarka: SSR bez cache CDN albo CSR, zależnie od SEO. Koszyk i konto: renderowane dynamicznie z danymi użytkownika, bez cache współdzielonego, noindex. Decyzje zapisuję w tabeli z uzasadnieniem i metrykami (TTFB, LCP, koszt, czas buildu).

Typowe wpadki

Jedna strategia dla całego serwisu
Budowanie 200 tysięcy stron przy każdym deployu
Cena z cache sprzed godziny bez mechanizmu odświeżenia

Dopytają o

Jak zapewnisz, że cena w koszyku zgadza się z ceną na stronie produktu?
Jak obsłużysz produkt usunięty z katalogu?
Jak zmierzysz wpływ zmian na pozycje w wyszukiwarce?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Hydration mismatch tylko na produkcji

Po wdrożeniu Sentry pokazuje tysiące błędów „Hydration failed” i „Text content does not match”. Lokalnie nic się nie dzieje. Część użytkowników widzi mignięcie treści, a w jednej przeglądarce przyciski przestają reagować do przeładowania.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz przyczyny różnic między renderem serwera i klienta
Czy umiesz je diagnozować przy różnicach środowisk
Czy wiesz, jakie są konsekwencje mismatchu dla interaktywności

Odpowiedź seniora

Różnice między produkcją a lokalnym środowiskiem to zwykle: strefa czasowa serwera (UTC) wobec użytkownika i formatowanie dat, locale serwera dla toLocaleString, dane zmieniające się między renderem a hydratacją, warunki na window lub localStorage w renderze, losowe id, różne feature flagi lub warianty A/B na serwerze i kliencie, rozszerzenia przeglądarki i tłumacze stron modyfikujące DOM, a także CDN lub proxy zmieniające HTML (np. minifikacja, wstrzykiwanie skryptów).

Diagnoza: React 19 i nowe Next.js pokazują diff w błędzie, więc zbieram go w Sentry z URL i przeglądarką. Porównuję HTML z serwera (curl) z tym, co renderuje klient. Grupuję błędy po przeglądarce, żeby odróżnić rozszerzenia od własnego kodu.

Naprawa: daty formatowane z jawną strefą i locale albo renderowane tylko na kliencie po zamontowaniu, useId zamiast losowych id, wariant eksperymentu ustalany na serwerze i przekazywany do klienta, wartości z przeglądarki czytane w useEffect lub przez useSyncExternalStore z getServerSnapshot. suppressHydrationWarning tylko punktowo dla znaczników czasu.

Typowe wpadki

Masowe suppressHydrationWarning
Wyłączenie SSR dla całej strony
Ignorowanie błędu, bo „strona się wyświetla”

Dopytają o

Jak przetestujesz brak mismatchu w CI?
Co dzieje się z drzewem Reacta, gdy hydratacja się nie powiedzie?
Jak pogodzisz personalizację z cache HTML?

Zapytaj Claude Rozwiń case Zagraj interviewera