Przepisanie strony na Next.js z App Router — co zyskuje firma na tej zmianie
Next.js z App Routerem i React Server Components to nie jest moda — to realna zmiana w tym, jak szybko strona dociera do użytkownika i robota Google.
Kiedy Next.js wypuścił App Router jako stabilny, wiedziałem że to zmienia reguły gry. Nie dlatego, że to nowość — ale dlatego, że architektura frontendu zaczęła wreszcie odzwierciedlać to, jak naprawdę działa biznes: jedne dane potrzebują być świeże w czasie rzeczywistym, inne mogą być zakeszowane na godziny lub dni. App Router i React Server Components dają tę kontrolę na poziomie pojedynczego komponentu.
Dlaczego Next.js, a nie inne frameworki?
Pytano mnie o Astro, Remix, Nuxt. Każdy ma swoje miejsce. Ale dla stron firmowych i portfolio z ambicjami na wydajność Next.js wygrywa kombinacją: ekosystem React jako największy na rynku, wsparcie Vercela, sprawdzony routing, ISR oraz image optimization wbudowane out of the box. Nie wybieram go z przyzwyczajenia — wybieram bo jest produkcyjnie sprawdzony w projektach każdej skali.
App Router i React Server Components — na czym polega przełom?
Przed App Routerem wszystko renderowane po stronie klienta oznaczało: użytkownik dostaje pustą stronę, przeglądarka pobiera JavaScript, wykonuje go, robi zapytanie do API, i dopiero wtedy widzi treść. Przy React Server Components zapytanie do bazy danych wykonuje się na serwerze, a HTML trafia do przeglądarki już z gotową treścią. Zero waterfallów zapytań. Zero niepotrzebnego JS w bundle. Strona wyświetla się szybciej i lepiej radzi sobie z robotami Google.
- Mniejszy bundle JavaScript — do klienta trafia tylko to, co musi być interaktywne
- Brak waterfallów zapytań API — dane pobierane na serwerze przed wysłaniem HTML
- Lepszy LCP (Largest Contentful Paint) — kluczowa metryka Core Web Vitals
- Streaming SSR — strona ładuje się etapami, użytkownik widzi treść natychmiast
- Bezpośredni dostęp do bazy danych z komponentów — bez zbędnej warstwy API
- Granularne keszowanie — kontrola co i kiedy się odświeża, na poziomie komponentu
Konkretne korzyści biznesowe dla firmy
- Szybsze ładowanie przekłada się bezpośrednio na niższy bounce rate i wyższe konwersje
- Lepsze wyniki Core Web Vitals to wyższe pozycje w wynikach Google
- Mniejsze koszty hostingu — mniej obliczeń po stronie klienta, więcej z CDN
- Łatwiejsze skalowanie — statyczne strony mogą być serwowane globalnie z edge
- Bezpieczniejszy kod — logika biznesowa zostaje na serwerze, niewidoczna dla użytkownika
- Lepsze indeksowanie przez Google — treść dostępna bez konieczności wykonania JavaScript
Jak wygląda przepisanie strony na Next.js?
Nie przepisuję całej strony od razu — dzielę na moduły i zaczynam od stron z największym ruchem. Równolegle buduję nową wersję i porównuję wyniki w tle. Przy ostatnim przepisaniu ze starego Create React App na Next.js z App Routerem PageSpeed na mobile skoczył z 42 do 91 punktów. Czas do First Contentful Paint spadł o 2,8 sekundy. To przekłada się bezpośrednio na konwersje — nie jest to tylko metryka dla deweloperów.
Kiedy przepisanie ma sens, a kiedy nie?
Jeśli strona jest statyczna lub prawie statyczna, a PageSpeed spada poniżej 70 punktów — tak, warto. Blog, portfolio, strona firmowa bez skomplikowanej logiki dynamicznej — zdecydowanie. Sklep z setkami produktów i dynamicznym filtrowaniem — też tak, ale to bardziej złożony projekt wymagający głębszej analizy.
Przepisanie ma sens wtedy, gdy koszt utrzymania starej strony — w czasie deweloperskim, w utraconych pozycjach SEO, w frustracjach użytkowników — przekracza jednorazowy koszt migracji. W mojej praktyce ten próg jest osiągany wcześniej niż klienci myślą. Warto to policzyć zanim zdecydujemy, że 'jeszcze poczekamy'.
