W 2018 Jamstack był nową rzeczą, którą wszyscy wieszczyli jako przyszłość webu. Gatsby, Netlify, Contentful. “Statyczne strony są martwe”, “WordPress umiera”, “headless to przyszłość”.

Cześć tych przepowiedni się spełniła. Cześć była przesadzona. W 2026 mam jasny obraz tego, co z Jamstack zostało i co nadal stosuję w agencji.

Ten post to mój uczciwy przegląd Jamstack po 6 latach. Co stawiam dziś dla klientów, czego unikam, i dlaczego ten paradygmat (z modyfikacjami) nadal wygrywa dla 80% projektów.

Krótko: czym jest Jamstack dziś

Definicja z 2018 była: JavaScript + APIs + Markup. Statyczny HTML wygenerowany w build time, z hydratacją JS w przeglądarce, dane z zewnętrznych API.

Definicja dziś jest szersza: architektura, która rozdziela frontend (statyczny lub SSR/ISR) od backendu (API albo headless CMS), z optymalizacjami pod performance i SEO.

Jamstack 2026 nie jest tylko statycznym HTML. To pełne spectrum: SSG (static), SSR (server-side), ISR (incremental), edge functions, hybrydy. Wszystko spina się w jednym modelu mentalnym.

Co umarło z Jamstack 2018

Gatsby. Lider epoki, dziś marginalny. Powody: wolne buildy, niewdolność do dynamicznego contentu, słabe DX w stosunku do nowszej konkurencji. Vercel kupił Gatsby w 2023, faktycznie zamykając rozwój.

Pure static-only myślenie. “Wszystko renderujemy w buildzie” działało dla blogów. Dla e-commerce, dashboardów, aplikacji z user state to było absurdalne. Industria przeszła na hybrid (SSG + SSR + ISR).

Tradycyjne SPA-y bez SSR. Create React App, czysty React Router. SEO nie działa, initial load wolny. Jamstack zepchnął te paradygmaty na obrzeża.

Niektóre wczesne headless CMS-y. Contentful nadal istnieje, ale tanieje na korzyść Sanity, Payload, Strapi. Vendor lock-in i pricing structures wykończyły wielu graczy.

Plain Markdown blogi. Nie umarły, ale przeszły z “trend” do “specyficznego use case”. Mój digital garden to Jekyll plus Markdown, ale dziś robię to świadomie, nie z trendu.

Co przeżyło i co dzisiaj stawiam

Next.js. King of Jamstack 2026. Pages plus App Router, SSG plus SSR plus ISR. Wszystko, czego potrzebujesz w jednym frameworku. Pisałem o tym w osobnym poście.

Astro. Świetny dla content-heavy stron (blogi, dokumentacja, marketing sites). Mniej JS, więcej HTML. Wybór dla projektów, gdzie SEO i performance są wszystkim.

Headless CMS-y. Strapi (mój default), Payload (uprawiania alternatywa), Sanity (świetny dla content-heavy), Directus.

Vercel. Standard deployment dla Next.js. Edge functions, ISR, image optimization out of the box.

Cloudflare Pages. Tańsza alternatywa Vercela dla static-heavy projektów.

Tailwind CSS. CSS approach pasujący do Jamstack philosophy. Pisałem o nim w osobnym poście.

MDX. Markdown plus React components. Świetny dla blogów, dokumentacji, marketing pages z dynamiczną zawartością.

Mój default stack dla projektów

Dla 80% projektów klienta:

  • Frontend: Next.js 15 z App Router
  • CMS: Strapi v5 dla contentu, dynamic data
  • Database: PostgreSQL (pisałem o tym w wyborze bazy)
  • Styling: Tailwind CSS plus shadcn/ui
  • Hosting: Vercel dla front, DigitalOcean dla Strapi
  • Monorepo: TurboRepo (zobacz post)
  • CI/CD: GitHub Actions

Ten stack pokrywa 90% potrzeb. Marketing site, e-commerce, SaaS, dashboard, blog. Wszystko z tego samego pudełka.

Dla content-heavy projektów (blog, dokumentacja, marketing)

Czasem Next.js to overkill. Wtedy:

  • Frontend: Astro
  • Content: Markdown (jeśli statyczny) albo headless CMS (jeśli klient chce edytować)
  • Hosting: Cloudflare Pages albo Netlify

Astro generuje HTML z mniejszą ilością JS. Lighthouse score 100/100/100/100 out of the box. Świetny dla SEO, świetny dla performance.

Dla mojego bloga (i podobnych)

Mój digital garden stoi na Jekyll. Brak Reacta, brak Node.js, surowy Markdown.

Powody:

  • 100% statyczny, deployment przez GitHub Pages (free)
  • Markdown writeable w Obsidianie
  • Zero dependency management, zero build issues
  • Działa za 5 lat tak samo, jak działa dziś

Astro byłby równie dobry. Jekyll wybrałem dla nostalgii i prostoty.

Gdzie Jamstack nie ma sensu

Nie wszystko musi być Jamstack.

Aplikacje z mocną interaktywnością (Figma, Linear, Notion). Tu trzeba pełne SPA z aggressive client-side rendering. Jamstack z SSR to overhead.

Aplikacje real-time (chat, kolaborator). WebSockets, server state. Jamstack jest dla content-driven, nie real-time.

Aplikacje enterprise z complex auth/permissions. Czasem łatwiej z klasycznym Rails, Django, .NET, gdzie auth jest battle-tested.

Prostotę-pierwsze CMS-y (klient chce klikać, nie kodować). WordPress nadal ma swoje miejsce dla mali biznes plus marketer. Lepsza dla nich niż headless.

W mojej praktyce: Jamstack dla 80% projektów, alternatywy dla 20%.

Headless CMS: który wybrać

Krótki przewodnik.

Strapi: open source, self-hosted (lub Strapi Cloud), Node.js. Mój default. Pisałem o nim szczegółowo w osobnym poście.

Payload: open source, self-hosted, TypeScript-first, świetne admin UI. Konkurencja dla Strapi. Wybierz Payload, jeśli chcesz mocniej typesafe content modeling.

Sanity: cloud, structured content. Świetny dla zespołów contentowych z complex workflows. Kosztowny przy skali.

Contentful: cloud, enterprise-grade. Standardowy wybór korporacji. Drogi, ale stabilny.

Directus: open source, self-hosted, oparty na SQL database. Wybierz, jeśli masz istniejącą bazę danych i chcesz dorzucić UI dla edytorów.

Sanity vs Strapi vs Payload to dziś główne wybory. Wybór zależy od:

  • Cloud (Sanity) vs self-host (Strapi, Payload)
  • Pricing modelu
  • Wymaganej elastyczności content modeling
  • Stacka technologicznego

Performance: dlaczego Jamstack wygrywa

Konkretne numbery z projektów klienta.

Pre-Jamstack (WordPress + plugins):

  • Lighthouse Performance: 40-60
  • First Contentful Paint: 2-4 sek
  • Largest Contentful Paint: 4-7 sek
  • Time to Interactive: 5-10 sek

Po migracji na Next.js + Strapi:

  • Lighthouse Performance: 90-100
  • First Contentful Paint: 0.5-1 sek
  • Largest Contentful Paint: 1-2 sek
  • Time to Interactive: 1-3 sek

To realne wartości z mojej praktyki, nie demo benchmarków. Klient widzi:

  • Niższy bounce rate
  • Lepszy ranking w Google (Core Web Vitals)
  • Wyższa conversion rate w e-commerce

Performance to nie tylko tech vanity. To biznes metric.

ISR: killer feature dla Jamstack 2026

Incremental Static Regeneration (z Next.js) to mostek między SSG a SSR.

Stara dychotomia:

  • SSG: szybkie, ale rebuild na każdą zmianę treści
  • SSR: dynamiczne, ale wolniejsze

ISR rozwiązuje:

  • Strona generowana statycznie przy pierwszym requeście
  • Cache na N sekund/minut
  • Po expiry następny user dostaje cached, w tle regeneracja
  • Eventual consistency, bardzo szybkie dla 99% users

W praktyce: blog z 10 000 postami nie buildujesz wszystkich naraz. Pierwsze odwiedziny generują na żądanie, cache, przyszłe odwiedziny są instant.

ISR plus on-demand revalidation (po update treści w CMS) to mój standard 2026.

Edge functions: gdzie warto

Edge functions to JavaScript wykonywany na CDN, blisko usera. Vercel, Cloudflare, Netlify, każdy ma swoje.

Gdzie warto:

  • Personalizacja per user (A/B testing, country-based redirect)
  • Auth checks (validacja JWT przed serwerem)
  • Image transformations (resize na fly)
  • Real-time API gateways

Gdzie nie warto:

  • Heavy compute (limit czasu na edge to zwykle 30 sek)
  • Database connections (latency, connection pool issues)
  • Long-running operations

Edge to specyficzny tool. Większość projektów dobrze obejdzie się bez. Ale jak potrzebujesz, dramatycznie polepsza UX.

SEO w Jamstack: lepiej niż w SPA

Jamstack jest natywnie dobry dla SEO:

  • HTML serwowany na żądanie (SSG albo SSR), Google scrapuje od razu
  • Meta tagi, OG images generowane per page
  • Sitemap, robots.txt generowane automatycznie
  • Structured data (JSON-LD) łatwo dodać
  • Performance = lepszy ranking (Core Web Vitals)

W SPA Google musi czekać na hydratację, czasem nie czeka. Indeksacja jest gorsza. Jamstack to rozwiązuje.

Dla projektów, gdzie SEO ma znaczenie (marketing, e-commerce, blog), Jamstack to default wybór.

Najczęstsze błędy w Jamstack

Wybieranie technologii na podstawie hype’u. “Gatsby is dead, must migrate to Next”. Może. Ale migrate, kiedy boli, nie zanim.

Over-engineering małych projektów. Klient ma blog z 30 artykułami i nigdy go nie aktualizuje. Stawia WordPress, sterty pluginów. Wystarczy statyczny HTML albo prosty Astro.

Brak ISR strategy. Build dla 10 000 produktów trwa godzinę. Powinieneś używać ISR z fallback i revalidate. Inaczej deploys umierają.

Mocne client-side state w Jamstack. Zustand, Redux, complex state managers w statycznej stronie. Trzymaj state minimalny po stronie klienta. Server state to lepiej w server components (Next.js 15).

Brak caching strategy. Każdy request idzie do origin servera, CDN nie cache’uje. Skonfiguruj cache headers porządnie.

Vendor lock-in. Łatwo na Vercelu, łatwo eksportować poza Vercel. Z Cloudflare Pages łatwo. Z Netlify łatwo. Z proprietary platform (np. Webflow) nie. Wybieraj platformy z portability.

Co czytać dalej

  • jamstack.org. Oficjalna strona, ekosystem links.
  • Vercel blog. Najlepsze praktyki Next.js i Jamstack.
  • Astro Docs. Najczystsza dokumentacja w ekosystemie.

Nie czytaj książek o Jamstack z 2019-2020. Połowa zaleceń już nieaktualna.

Od czego zacząć

Jeśli budujesz nowy projekt i myślisz o stacku:

  1. Content-heavy strona (blog, docs, marketing)? → Astro
  2. Aplikacja z dynamicznymi danymi (e-commerce, SaaS, dashboard)? → Next.js + Strapi
  3. Prosty blog osobisty? → Jekyll lub Astro plus Markdown
  4. Aplikacja real-time? → Może nie Jamstack, rozważ klasyczny stack z WebSockets
  5. Enterprise z complex permissions? → Może klasyczne (Rails, Django) zamiast Jamstack

Jamstack 2026 to nie ortodoksja. To toolbox z dobrymi narzędziami. Wybieraj świadomie pod konkretny projekt.

Hype z 2018 się skończył. Solidna baza została. Dla agencji robiącej projekty dla klientów Jamstack stack (Next.js + Strapi + Vercel) to dziś najmniej ryzykowny wybór. Działa szybko, klient widzi rezultat, performance jest świetny, SEO działa.

To nie sexy, ale działa. Idealna definicja dobrej technologii dla agencji.