React i Next.js — wydajne aplikacje webowe
W platformie 4myevents używamy React 18 i Next.js 15 (App Router): w stronie prezentacyjnej i w panelu zespołu organizatorów, z wydarzeniami, typami biletów, uczestnikami, check-inem, agendą i raportami. Kod to ścisły TypeScript, testy są zautomatyzowane, a wdrożenia odbywają się bez przestojów.
Dlaczego Next.js w naszych projektach
Next.js 15 z App Routerem oferuje unikalny model hybrydowy: strony statyczne (SSG) są serwowane natychmiast z CDN, strony dynamiczne działają jako Server Components, które nie wysyłają do przeglądarki zbędnego JavaScriptu, a strony czasu rzeczywistego korzystają z izolowanych Client Components. Efekt to wynik Lighthouse 95+ od razu po wdrożeniu, bez sztuczek.
Obrazy są automatycznie optymalizowane przez komponent `<Image>` (WebP/AVIF, responsywny srcSet, lazy-loading), fonty są osadzane w krytycznym CSS za pomocą `next/font`, a skrypty zewnętrzne ładują się według strategii priorytetów. Łącznie te optymalizacje obniżają LCP poniżej 2,5 sekundy w rzeczywistych sieciach 4G.
- Server Components dla stron serwisu prezentacyjnego — zero JS po stronie klienta, natychmiastowe crawlowanie
- Streaming SSR z Suspense dla ekranów z danymi ładowanymi progresywnie
- Incremental Static Regeneration (ISR) dla artykułów bloga i stron z treścią — bez przebudowy
- Route Groups i Parallel Routes dla złożonych układów bez ponownego renderowania
Ścisły TypeScript — bez cichych błędów
Wszystkie nasze projekty używają TypeScriptu z `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` i `noUncheckedIndexedAccess`. Te ustawienia blokują całe kategorie błędów runtime już na etapie kompilacji: dostęp do wartości undefined, niekompletne typy odpowiedzi API, błędne porównania. Typowy projekt ma 0 błędów TypeScriptu w CI przed uruchomieniem jakiegokolwiek testu.
Do zarządzania stanem używamy Zustand (lekki, bez boilerplate’u) lub React Context dla stanu lokalnego. Pobieranie danych obsługuje TanStack Query (automatyczny cache, inteligentna inwalidacja, stale-while-revalidate). Formularze to React Hook Form + walidacja schematów Zod — walidacja synchroniczna i asynchroniczna bez duplikowania kodu.
- ESLint z własnymi regułami dla zakazanych wzorców (any, console.log, magic strings)
- Prettier z jednolitą konfiguracją — żaden PR nie jest odrzucany z powodu formatowania
- Zod do walidacji w runtime danych z zewnętrznych API
- Aliasy ścieżek (`@/components/...`) — czyste importy bez `../../..`
Testy automatyczne i CI/CD
Testy jednostkowe w Vitest (szybki, zgodny z API Jesta), testy komponentów w React Testing Library, E2E w Playwright na 3 przeglądarkach (Chromium, Firefox, WebKit). Pipeline GitHub Actions uruchamia wszystkie testy przy każdym PR; scalenie jest zablokowane, jeśli którykolwiek nie przejdzie. Minimum 80% pokrycia logiki biznesowej.
- Lighthouse CI — wynik <90 blokuje wdrożenie na staging
- Automatyczny analizator bundle’a — alert, gdy bundle rośnie o >5% względem main
- Storybook dla komponentów UI — żywa dokumentacja wizualna
Zalety i ograniczenia
Zalety
- Lighthouse 95+ od pierwszego dnia, bez ręcznego strojenia.
- Natywne SSR i SSG — pełny HTML dla Google i silników AI.
- Ścisły TypeScript wyłapuje błędy podczas kompilacji, a nie na produkcji.
- Dojrzały ekosystem: Vercel, tysiące pakietów, ogromna społeczność.
Ograniczenia
- Krzywa uczenia się App Routera i Server Components jest stroma.
- Częste zmiany łamiące kompatybilność między wersjami głównymi — wymaga utrzymania.
- Dla prostej strony statycznej Next.js może być przesadą w porównaniu ze zwykłym HTML.
- Duże buildy wydłużają czas kompilacji i zwiększają koszt CI.
Krótki werdykt
Wybierz React i Next.js dla stron i aplikacji webowych, które muszą być szybkie, indeksowalne i skalowalne. Dla pojedynczego statycznego landing page’a bez interaktywności wystarczy prostsze narzędzie.
Tabela specyfikacji
| Możliwość | Limit / próg | Typowe zastosowanie | |
|---|---|---|---|
| Renderowanie | SSR, SSG, ISR, CSR | Server Components ograniczają API przeglądarki | Statyczny marketing + dynamiczny dashboard |
| Wydajność | LCP < 2.5s, Lighthouse 95+ | JS hydratacji rośnie wraz z interaktywnością | Serwisy o dużym ruchu, krytyczne dla SEO |
| Skalowanie | Dziesiątki tysięcy użytkowników, edge CDN | Wymaga hostingu Node lub serverless | SaaS, portale, platformy do zarządzania wydarzeniami |
| Typowy koszt | Open source, hosting od ~€0 | Funkcje serverless rozliczane za użycie | Od małych projektów po enterprise |
Next.js a alternatywy
| Kryterium | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG w jednym frameworku | Tak, natywnie | Częściowo (Nuxt tak, Vite nie) |
| Ekosystem React | Pełny | Vue (Nuxt) lub wiele frameworków (Astro) |
| Najlepszy do czysto statycznej strony | Dobry | Astro jest lżejsze |
Najczęstsze pytania
Dlaczego Next.js, a nie zwykły React (Vite)?
React z Vite renderuje tylko po stronie klienta, więc początkowy HTML jest pusty — to słabe rozwiązanie dla SEO i GEO. Next.js dodaje SSR i SSG, dostarczając pełny HTML, który Google i silniki AI odczytują natychmiast.
Czy Next.js jest dobry dla SEO?
Tak. SSR/SSG dostarcza indeksowalny HTML, metadane i JSON-LD są generowane na serwerze, a Core Web Vitals są zielone z założenia — to wszystko silne sygnały rankingowe.
Czy mogę zmigrować istniejącą stronę do Next.js?
Tak, stopniowo: strony są przenoszone jedna po drugiej, z zachowaniem adresów URL i przekierowań 301, dzięki czemu pozycje w Google nie przepadają.
Jakiego hostingu potrzebuje Next.js?
Strony statyczne działają na dowolnym CDN. Funkcje dynamiczne (SSR, API routes) wymagają Node.js lub środowiska serverless, takiego jak Vercel, Netlify albo kontener Docker.