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.