Programista Next.js

Co dostarczam

Next.js 15 z App Router i React 19 Server Components jako warstwa frontendu. WordPress 6.7+ jako redakcyjny backend, komunikujący się przez REST lub GraphQL. Cloudflare Workers i Pages jako środowisko uruchomieniowe i cache na edge. TypeScript przez cały stos. Tailwind CSS jako system designu. Anthropic Claude i Model Context Protocol, gdy funkcje AI realnie zarabiają na siebie.

To nie jest lista technologii z ogłoszenia o pracę, tylko stos, który utrzymuję we własnej produkcji. Każdy element ma uzasadnienie: App Router daje renderowanie per trasa, RSC tnie JavaScript wysyłany do klienta, Workers eliminują zimne starty i utrzymują dane w zasięgu regulacji europejskich. Gdy któryś element przestaje bronić się w praktyce, wypada ze stosu, co dokumentuję kwartalnie w Tech Radar.

Kiedy Next.js jest właściwym wyborem

Strony spersonalizowane, ścieżki sesyjne, doświadczenia z testami A/B, transakcyjny checkout, dashboardy w czasie rzeczywistym i uwierzytelnione przestrzenie pracy zyskują na modelu streaming SSR + RSC. Model myślowy brzmi: "renderuj blisko danych, streamuj to, co gotowe, hydruj to, co interaktywne". Dla stron, które tu pasują, Next.js daje UX nieosiągalny dla klasycznego SSR czy statyki.

Dla stron, które nie pasują, mówię to wprost. Serwisy treściowe, blogi i dokumentacja zwykle wygrywają na Astro ze statyką + ISR przy niższym koszcie. Decyzja o frameworku jest częścią scopingu, a nie ustawieniem domyślnym. Jeśli po discovery okaże się, że twój serwis nie potrzebuje Next.js, usłyszysz to razem z tańszą rekomendacją.

Architektura: WordPress jako backend, Next.js jako frontend

W układzie headless WordPress przestaje renderować strony i zostaje tym, w czym jest naprawdę dobry: systemem redakcyjnym. Zespół contentowy pracuje w znanym panelu, z tymi samymi rolami, workflow i wtyczkami redakcyjnymi. Next.js pobiera treść przez REST albo WPGraphQL i renderuje ją według strategii dobranej do trasy: strona główna i landingi jako statyczne z rewalidacją, katalog produktowy jako ISR z inwalidacją przez webhooki, checkout i panel klienta jako SSR z pełną sesją.

Trzy elementy decydują o tym, czy taka architektura działa w praktyce, i wszystkie trzy są częścią wdrożenia. Podgląd redakcyjny: redaktor musi widzieć szkic przed publikacją, więc konfiguruję draft mode spięty z WordPressem, a nie tłumaczę zespołowi, że "tak się teraz nie da". Inwalidacja cache: publikacja w WordPressie wysyła webhook, który rewaliduje dokładnie te trasy, których dotyczy zmiana, zamiast czyścić cały cache. Obsługa mediów: obrazy przechodzą przez pipeline Next.js z automatycznym AVIF i responsywnymi rozmiarami, niezależnie od tego, co wgrał redaktor.

Wydajność i Core Web Vitals

Wydajność w Next.js nie bierze się z frameworku, tylko z decyzji architektonicznych, które framework umożliwia. Streaming SSR wysyła pierwszy bajt zanim serwer skończy renderować całość, co bezpośrednio obniża TTFB i LCP. Server Components utrzymują logikę pobierania danych po stronie serwera, więc klient dostaje mniej JavaScriptu, a INP przestaje cierpieć na hydratacji wszystkiego naraz. Cache na Cloudflare edge odpowiada użytkownikowi z najbliższego punktu sieci zamiast z jednego serwera origin.

Każdy projekt zaczyna się od baseline: TTFB, LCP, INP i CLS mierzone na realnych użytkownikach przed zmianą, nie w laboratorium. Po wdrożeniu te same metryki są zbierane przez RUM i porównywane w oknie pomiarów równoległych. Wynik projektu to różnica w danych polowych, nie zrzut ekranu z Lighthouse. Publiczny protokół pomiarowy Astro vs Next.js na WooCommerce, z metodologią do wglądu, znajdziesz w sekcji materiałów referencyjnych na dole strony.

WooCommerce headless na Next.js

Sklep to najbardziej wymagający wariant headless, bo łączy treść statyczną z transakcją na żywo. Karty produktów i kategorie renderuję jako ISR: szybkie jak statyka, aktualizowane webhookiem przy zmianie ceny lub stanu magazynowego. Koszyk, checkout i konto klienta działają jako SSR z sesją, spięte ze Store API WooCommerce. Ceny per klient, progi rabatowe B2B i katalogi ukryte za logowaniem, typowe wymagania hurtowni, przestają wymuszać rezygnację z cache na całym sklepie, bo decyzja o renderowaniu zapada na poziomie trasy.

Do tego dochodzi warstwa, o którą coraz częściej pytają sklepy: gotowość na agentów zakupowych AI. Czysty, serwerowo renderowany HTML z poprawnym schema Product i Offer to warunek wejścia, żeby agent w ogóle widział katalog. To ta sama architektura, która serwuje szybkie strony ludziom, więc nie płacisz za nią drugi raz.

SEO, GEO i AEO w Next.js

Serwerowe renderowanie to fundament widoczności, którego kliencki React nigdy nie zapewni: crawlery AI takie jak GPTBot, ClaudeBot czy PerplexityBot nie wykonują JavaScriptu, a Googlebot wykonuje go z opóźnieniem i budżetem. Next.js z SSR i RSC oddaje pełną treść w pierwszej odpowiedzi HTML, więc to, co widzi użytkownik, widzi też bot.

Na tym fundamencie buduję warstwę techniczną: metadata API per trasa, canonical i hreflang przez metadata.alternates, sitemap przez generateSitemaps, dane strukturalne jako JSON-LD dopasowane do typu strony (Product, Article, FAQPage, HowTo), Open Graph z obrazami generowanymi per strona. Dla widoczności w wyszukiwarkach generatywnych dokładam elementy GEO: sekcje z bezpośrednimi odpowiedziami, FAQ z danymi strukturalnymi, llms.txt i negocjację treści dla agentów. Każdy projekt przechodzi 30-punktową checklistę SEO przed przełączeniem DNS.

Bezpieczeństwo i jurysdykcja UE

Headless zmniejsza powierzchnię ataku w sposób, który da się wyjaśnić zarządowi jednym zdaniem: WordPress znika z publicznego internetu. Panel logowania, XML-RPC i pliki wtyczek przestają być osiągalne dla skanerów, bo frontend serwuje Next.js, a origin jest dostępny wyłącznie dla niego. Do tego dochodzą nagłówki bezpieczeństwa konfigurowane centralnie, walidacja danych wejściowych po stronie serwera i sekrety trzymane poza repozytorium.

Dla firm objętych RODO, NIS2 lub DORA liczy się też geografia danych: runtime na Cloudflare z przetwarzaniem w UE, umowy powierzenia po polsku lub angielsku, dokumentacja przepływów danych do rejestru czynności przetwarzania. Kontrakt B2B w jurysdykcji europejskiej, nie regulamin platformy spoza niej.

Dla kogo to jest

• Sklepy WooCommerce z niestandardowym procesem zakupowym lub cenami per użytkownik
• Dashboardy SaaS i uwierzytelnione przestrzenie pracy z WordPressem jako warstwą treści
• Marki wieloregionalne potrzebujące ISR z inwalidacją przez webhooki
• Wydawnictwa redakcyjne z kanałami danych live, komentarzami lub powierzchniami analityki w czasie rzeczywistym
• Hurtownie B2B z katalogami za logowaniem i cennikami negocjowanymi per kontrahent

Model współpracy

Seniorskie kontrakty B2B w jurysdykcji UE. Cztery fazy: discovery z audytem treści i baseline wydajności, scoping z decyzjami o renderowaniu per trasa, iteracyjna budowa z cotygodniowymi demami i oknem pomiarów równoległych, wreszcie strojenie i opieka z obserwowalnością oraz kwartalnymi przeglądami stosu. Współpraca o stałym zakresie lub time-and-materials. Wycena indywidualna, harmonogram per etap z punktami decyzyjnymi.