Home› Blog› React vs. Next.js: Was ist die richtige Wahl für Ihr Webproj…
Webentwicklung

React vs. Next.js: Was ist die richtige Wahl für Ihr Webprojekt?

23. März 2026

Neues Projekt, Technologieentscheidung: React oder Next.js? Die Antwort, die wir fast immer bekommen: "Next.js, weil SSR besser für SEO ist." Das stimmt — aber es ist nur die halbe Wahrheit. Und es führt dazu, dass viele Projekte unnötig komplex werden.

Dieser Artikel erklärt den Unterschied, alle vier Rendering-Strategien in der Tiefe, wann welche Wahl Sinn ergibt — und räumt mit dem "SSR ist immer besser"-Mythos auf.

Der grundlegende Unterschied

React SPA (mit Vite)

Bei einer Single Page Application liefert der Server eine leere HTML-Seite mit einem JavaScript-Bundle. Der Browser lädt das Bundle, führt React aus, und erst dann wird die Seite aufgebaut:

Next.js mit SSR, SSG oder ISR

Next.js rendert Seiten auf dem Server — zur Laufzeit (SSR), beim Build (SSG) oder inkrementell (ISR):

Wenn Ihre App hinter einem Login versteckt ist, ist SEO irrelevant. Dann brauchen Sie kein SSR.

Rendering-Strategien im Detail

Next.js unterstützt vier Rendering-Strategien, die pro Seite unterschiedlich eingesetzt werden:

CSR (Client-Side Rendering): Das klassische React-SPA-Modell. Schlechtes SEO, langsamer Initial Load. In Next.js aktiviert durch 'use client' ohne serverseitigen Fetch.

SSG (Static Site Generation): Seiten werden beim Build statisch generiert. Ultra-schnelle HTML-Dateien per CDN. LCP unter 0,5 Sekunden möglich. Perfekt für Marketing-Seiten, Blog-Posts und Dokumentationen.

SSR (Server-Side Rendering): Für jeden Request frisch generiert. Stets aktuell, gutes SEO, aber höhere Latenz als SSG.

ISR (Incremental Static Regeneration): Der goldene Mittelweg. Seiten werden statisch generiert und nach einer konfigurierbaren Zeit neu generiert.

// SSG: einmal beim Build generiert
export const dynamic = 'force-static';

// ISR: alle 60 Sekunden neu generiert
export const revalidate = 60;

// SSR: jeder Request generiert frisch
export const revalidate = 0;

// Wann was verwenden:
// force-static   → Marketing, Docs, Landing Pages
// revalidate: 60 → Nachrichten, Produktkataloge
// revalidate: 0  → Echtzeit-Daten, auth-sensitive Seiten

App Router vs. Pages Router

Mit Next.js 13 wurde der App Router eingeführt. In 2026 ist er der de-facto-Standard für neue Projekte.

Pages Router (klassisch): Dateibasiertes Routing im pages/-Verzeichnis. Datenfetching über getServerSideProps (SSR) und getStaticProps (SSG).

App Router (neu): Routing im app/-Verzeichnis. Unterstützt React Server Components nativ. Datenfetching direkt in async-Komponenten.

// Pages Router — getServerSideProps für SSR
export async function getServerSideProps({ params }) {
  const product = await fetchProduct(params.id);
  return { props: { product } };
}

// App Router — async Server Component
export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id);
  return <div>{product.name}</div>;
}

Neue Projekte: App Router, kein Wenn und Aber. Migration bestehender Projekte: Nur wenn es einen konkreten Grund gibt.

Entscheidungsmatrix: Wann was wählen?

Wählen Sie React SPA (Vite), wenn:
  ✓ App läuft hinter einem Login
  ✓ SEO ist nicht relevant
  ✓ Sehr dynamische Daten (Real-time)
  ✓ Einfaches Deployment und Hosting

Wählen Sie Next.js, wenn:
  ✓ Öffentliche Seiten brauchen SEO
  ✓ Performance für anonyme Nutzer ist kritisch
  ✓ E-Commerce (Produkt-Listings indiziert)
  ✓ Content-heavy Sites mit statischen Daten

Der Hybrid-Ansatz für komplexe Anwendungen

Viele moderne Anwendungen sind hybrid: öffentliche Marketing-Seiten mit SEO und ein Auth-geschützter App-Bereich.

// Next.js App Router — gemischte Strategien
app/
  (public)/          // SSG: Marketing, Blog
    page.tsx          // export const dynamic = 'force-static'
    blog/
      [slug]/page.tsx
  (auth)/            // CSR: App-Bereich
    dashboard/
      page.tsx        // 'use client' — kein SSR nötig

React Server Components — was wirklich Server gehört

Das Modell: Komponenten laufen standardmäßig auf dem Server, Client-Interaktivität wird explizit mit 'use client' markiert.

Server Components (default): Alles, was Daten fetcht und keine Browser-Interaktion hat. Datenbankzugriffe, API-Calls, große Dependencies. Jede Library nur im Server Component senkt das Client-Bundle erheblich.

'use client' benötigt: useState/useReducer, useEffect, Browser APIs, Event Handler.

// Server Component: Daten fetchen
export default async function ProductsPage() {
  const products = await db.products.findMany();
  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>
          <ProductCard product={p} />
          <AddToCartButton id={p.id} />
        </li>
      ))}
    </ul>
  );
}

// Client Component nur für Interaktivität
'use client';
export function AddToCartButton({ id }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? 'Hinzugefügt' : 'In den Warenkorb'}</button>;
}

Häufige Fehler

State-Management in Next.js 2026

Server Components reduzieren den Bedarf an globalem Client-State erheblich. Für die verbleibenden Fälle (Shopping Cart, User-Preferences):

Faustregel: Fangen Sie ohne globalen State an. React Context für einfache Werte. Zustand wenn Context zu viele Re-Renders verursacht. Redux nur für begründete Ausnahmen.

Performance messen: Core Web Vitals richtig verstehen

Google nutzt Core Web Vitals als Ranking-Signal:

Typische Werte aus unseren Projekten:

Deployment: Kosten, Optionen und Fallstricke

Vercel-Fallstricke: Der Pro-Plan kostet 20 USD/Monat pro Team-Mitglied. Serverless Functions haben ein Timeout-Limit von 300 Sekunden. Cold Starts können 200–500ms Zusatzlatenz bedeuten.

Alternativen: Railway oder Render für containerisierte Next.js-Deployments. Hetzner VPS für maximale Kontrolle.

Fazit: Pragmatisch statt ideologisch

Wählen Sie die Technologie, die zu Ihrem Use Case passt — nicht die, die gerade am meisten Hype hat. Für reine Web-Apps hinter einem Login ist React SPA mit Vite oft die bessere Wahl. Next.js glänzt wenn SEO, Performance für anonyme Nutzer oder statisches Content-Management wichtig sind.

Wenn Sie Next.js wählen: Nutzen Sie den App Router, verstehen Sie die vier Rendering-Strategien, halten Sie 'use client' auf das Notwendige beschränkt, und messen Sie Performance regelmäßig.

Frontend-Entscheidungen mit Weitblick? Kontaktieren Sie uns für eine Technologieberatung.

Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.