Kiedy Next.js jest właściwym wyborem, a kiedy nie
Next.js powstał do budowy aplikacji i w tej roli jest trudny do zastąpienia. Logowanie, panel użytkownika, koszyk, dashboard, treści zależne od zalogowanej osoby - wszędzie tam renderowanie po stronie serwera i pełny model Reacta mają realne uzasadnienie.
Strona firmowa, blog, landing page czy serwis contentowy działają inaczej. Ich treść jest taka sama dla każdego odwiedzającego i zmienia się rzadko, a mimo to każda odsłona przechodzi przez ten sam mechanizm renderowania i hydratacji.
Migracja do Astro ma sens dokładnie w tym drugim przypadku - nie dlatego, że Next.js jest zły, tylko dlatego, że strona contentowa płaci za możliwości, z których nie korzysta. Sami budujemy aplikacje w Next.js i robimy to dalej, więc rekomendacja zależy od tego, czym Twój projekt naprawdę jest.
Co z komponentami React?
Astro uruchamia komponenty React natywnie, więc istniejący kod nie trafia do kosza. Podczas audytu dzielimy komponenty na dwie grupy: te, które tylko renderują treść, i te, które naprawdę potrzebują interaktywności w przeglądarce.
Pierwsza grupa zostaje wyrenderowana do HTML-a na etapie builda i nie wysyła do przeglądarki ani linijki JavaScriptu. Druga zostaje komponentem React, ale ładuje się jako osobna wyspa - wtedy, kiedy jest potrzebna, a nie razem z całą stroną.
W praktyce największą częścią pracy nie jest przepisywanie komponentów, tylko rozstrzygnięcie, który z nich należy do której grupy.
Jak wygląda architektura po migracji?
W Next.js widok, routing, renderowanie i warstwa danych są częścią jednej aplikacji, a hosting musi umieć ją uruchomić. Po migracji te warstwy są rozdzielone.
Treści żyją w headless CMS-ie, zwykle tym samym co dziś, frontend to komponenty Astro i React w repozytorium, a wynik builda to statyczne pliki serwowane z infrastruktury Cloudflare. Fragmenty, które naprawdę muszą działać dynamicznie, zostają na edge - jako świadomy wyjątek, a nie domyślny tryb pracy całej strony.
Formularze i endpointy API przenosimy na funkcje działające na edge, więc żadna z obecnych funkcjonalności nie znika.
Co wpływa na zakres i wycenę?
Każda migracja jest inna, dlatego nie pracujemy na cennikach z sufitu. Zakres zależy przede wszystkim od liczby typów podstron, liczby komponentów i stanu ich kodu, liczby endpointów API oraz integracji i formularzy, które trzeba przenieść.
Znaczenie ma też to, ile fragmentów strony faktycznie wymaga renderowania na żądanie, czy design zostaje bez zmian i gdzie docelowo mają żyć treści.
Po audycie przygotowujemy konkretny zakres, ryzyka, rekomendowaną architekturę, harmonogram i wycenę. Dopiero wtedy podejmujesz decyzję o starcie projektu.
Co dzieje się po uruchomieniu?
Migracja nie kończy się w dniu przełączenia DNS-a. Przez pierwsze tygodnie monitorujemy indeksację, błędy 404 i Core Web Vitals, żeby mieć pewność, że Google poprawnie przepięło się na nową wersję.
Dalszy rozwój strony odbywa się już w kontrolowanym procesie: zmiany przechodzą przez repozytorium, code review i staging, a wdrożenia są automatyczne i odwracalne.
