Jamstack

Tools: Next.js, Gatsby, Hugo. Hosting: Vercel, Netlify. Daten: Headless CMS (Contentful, Strapi). Der Redakteur tippt Text in Contentful. Klick auf "Speichern". Netlify baut die Seite neu (Build Process). 5 Minuten später ist die neue statische Seite online, weltweit verteilt.

1. ISR (Incremental Static Regeneration)

Das Problem: Wenn du 100.000 Seiten hast (Amazon), dauert "Alles neu bauen" Stunden. ISR erlaubt es, eine einzelne Seite neu zu bauen, wenn ein User sie besucht. Der erste User sieht die alte Seite (stale). Im Hintergrund wird gebaut. Der zweite User sieht die neue. Kombiniert Speed von Static mit Flexibilität von Dynamic.

2. Servercomponnets (RSC)

Der neueste Trend (React). Wir gehen einen Schritt zurück zum Server. Komponenten werden auf dem Server gerendert (aber ohne PHP, sondern mit JS) und als fertiges HTML + Daten-Stream geschickt. Jamstack entwickelt sich weiter zu "Composable Web".

1. Hydration und TTI (Time-to-Interactive)

Eine gravierende Krankheit des JAMstack Frontends (React / Next.js) ist das Hydration-Problem. Der Browser lädt sofort Millisekunden schnelles, pre-rendered HTML zur Anzeige. TFP (First Paint) ist glorreich. Aber das HTML ist komplett "tot". Alle Klick-Handler (onClick) sind funktionslos, bis das gigantische, aufgeblasene JavaScript-Bundle nachgeladen, geparst und im DOM execution-ready angebunden ist. Dieser reanimierende Brute-Force Prozess heißt Hydration. Die Differenz vom Bildaufbau bis das UI wirklich nutzbar ist, nannten Tester die unheimliche Talsohle (Time-To-Interactive Lücke). User klicken Menüs, und das Webinterface ignoriert es eiskalt 2 Sekunden lang. Frameworks wie Astro oder Qwik kämpfen exakt nur gegen diese Hydration-Triebwerke via "Resumability" anstatt Full-Hydration (Sie laden nur JS auf exakt den einen Button, der geklickt wird).

2. Next.js App Router und React Server Components (RSC)

Das Jahr 2023 sprengte die alte SSG Definition. SSG (Static Site Generation/Jamstack) baute fertiges HTML beim Build auf dem Vercel Compiler-Host. Mit React Server Components wandern Komponenten (fetch() Datenbanken, File-I/O) permanent auf die Serverseite zurück (als Serverausführung). Dieses Setup reist gar nicht mehr als JavaScript Paket auf den Client, es schickt einen rohen JSON-Baum-Stream (React Payload Pattern), das der Client inkrementell in DOM pflanzt. Es eliminiert restlos 90% der Client-Libraries als Dead-Code (zero-bundle size impact). Das radikale Resultat: Das "JS" im Jamstack existiert für das Web-Client Backend praktisch kaum noch.

3. Edge Compute Middleware (Cloudflare Workers / Vercel Edge)

Statische Dateien in Bukets auf CDNs waren super – besaßen aber keine Möglichkeit für komplexe Header-Manipulationen oder dynamisches Geoblocking, ohne in ein Backend im Origin-Rechenzentrum abzurufen. Die Edge Compute API drückt die Middleware-Code direkt in die V8 Cache-Knoten auf der Weltkugel (Frankfurt, Tokio, New York). Das Framework schießt bei einem Seitenaufruf in $< 50\text{ms}$ (ohne Node.js / Container Kaltstart!) einen extrem limitierten V8 Isolate-Prozess ab, der dem User auf L7 das Header Token checkt (request.geo.country), ihm dynamische AB-Test Split-Cookies setzt, und ihn nahtlos in einen statischen Route-Bucket schubst. Performance blieb maximal bei maximaler Intelligenz. Jamstack mutierte von "prebuild everything" in "Edge-dynamic routing for prebuilt assets".