Was ist Prerendering?

Was ist Prerendering?

Prerendering ist die Technik, vollständig gerendertes HTML für spezifische URLs im Voraus zu generieren — zur Build-Zeit, on-demand zur Request-Zeit oder geplant — sodass der Browser oder Crawler beim Anfordern der Seite fertig-paint-bereites Markup statt einer leeren SPA-Shell erhält, die JavaScript zum Bevölkern braucht. Prerendering sitzt zwischen vollem Server-Side-Rendering (SSR, das bei jeder Anfrage rendert) und reinem Client-Side-Rendering (CSR, das nur im Browser rendert). Es löst das SEO- + First-Paint-Problem von Single-Page-Anwendungen, ohne die operative Komplexität von SSR auf sich zu nehmen.

Die Technik hat mehrere Geschmäcker, die im Gespräch verwechselt werden. Statisches Prerendering (Build-Zeit, auch SSG genannt) generiert eine HTML-Datei pro Route während der Build-Pipeline — Outputs gehen zu einem CDN. Dynamisches Prerendering (Request-Zeit, oft via Services wie Prerender.io oder Rendertron) erkennt Bot-Traffic und serviert einen vor-gerenderten Cache, während reguläre Nutzer die SPA bekommen. Hybrides Prerendering mischt beides — pre-rendere die meistbesuchten Routen statisch, falle zurück auf SSR oder CSR für Long-Tail-Routen.

Die drei Prerendering-Strategien

1. Statisches Prerendering / SSG (Build-Zeit)

HTML für jede Route während des Deployments generieren. Tools: Next.js getStaticProps, Gatsby, Astro, SvelteKits Static-Adapter, Nuxts Static-Generate. Am besten für Content, der sich nicht pro Request ändert: Marketing-Seiten, Blogs, Docs, E-Commerce-Kategorie-Listings. Begrenzung: Rebuild für Content-Änderungen erforderlich.

2. Dynamisches Prerendering (Request-Zeit, Bot-targetiert)

Server erkennt User-Agent (Googlebot, Bingbot, Social-Crawler) und routet sie zu einem Headless-Chrome-gerenderten Cache. Reguläre Nutzer bekommen weiterhin die SPA. Tools: Prerender.io, Rendertron, Custom-Puppeteer + Cache. Am besten für: Legacy-SPAs, die du nicht zu SSR refactoren kannst, aber SEO brauchst. Begrenzung: verstößt gegen Googles Präferenz für Parität (Menschen vs. Crawler sollten den gleichen Content sehen).

3. Incremental Static Regeneration (ISR)

Hybrid: Seiten sind statisch, regenerieren aber im Hintergrund nach einem TTL oder on-demand. Next.js, Astro und Nuxt 3 unterstützen das. Am besten für: Content, der sich gelegentlich ändert (Produktseiten, News-Artikel, Listings). Kombiniert SSG-Geschwindigkeit mit SSR-Frische.

Prerendering vs. SSR vs. CSR — wann was nutzen

Warum Prerendering für Performance + SEO zählt

• Schnelleres TTFB / LCP. Vor-gerendertes HTML trifft den Browser paint-bereit. Kein JS-Download + Execute + Fetch + Render-Zyklus.
• Bessere Core-Web-Vitals-Scores. LCP misst den größten above-fold-Paint. Vor-gerenderter Content paint normalerweise schneller als SPA-mounted Content. Direkter Ranking-Signal-Vorteil.
• Crawlbares HTML. Suchmaschinen parsen Content aus dem initialen HTML, nicht nachdem JavaScript ausgeführt wurde. Entfernt das Rendering-Bottleneck-Risiko in Googlebots Zwei-Pass-Crawl.
• Cache-freundlich. Statisches HTML cacht überall — CDN-Edges, Browser, Zwischen-Proxies. SSR-Antworten sind meist pro Nutzer, können nicht so aggressiv gecacht werden.
• Offline-freundlich. Vor-gerenderte Seiten können von Service-Workern für Offline-Zugang gecacht werden.

Häufige Prerendering-Fehler

• Personalisierten Content vorgenerieren. Nutzerspezifische Daten (Name, Prefs, Cart) sollten nicht im statischen HTML sein. Hydriere sie client-seitig nach dem Mount.
• Veralteter vor-gerenderter Content. Wenn dein TTL zu lang ist, sehen Nutzer veraltete Info. Tune ISR / Cache-Control aggressiv.
• Cloaking via dynamischem Prerendering. Googlebot eine vollständig-gerenderte Version zu servieren, während Nutzer eine langsame Shell bekommen, kann gegen Googles Cloaking-Richtlinien verstoßen, wenn der Content unterscheidet.
• Hydration-Mismatches. Vor-gerendertes HTML und Client-seitiges Render müssen exakt übereinstimmen, sonst wirft React/Vue Warnings + re-rendert. Prüfe nicht-deterministischen Content (Date, zufällige IDs, locale-spezifische Formatierung).
• Build-Zeit-Bloat. Statisches Prerendering von 100.000 Routen kann Stunden dauern. Nutze ISR für den Long-Tail; statisch für die Top-5.000.
• Metadaten vergessen. Prerendering sollte Title, Meta-Description, og:image, JSON-LD bevölkern — nicht nur Body-Content.

FAQ: Prerendering

Ist Prerendering dasselbe wie SSR?

Nein. SSR rendert bei jeder Anfrage (server-seitig), Prerendering rendert im Voraus (Build oder geplant). Beide produzieren HTML für den Browser, aber mit verschiedenen Caching- + Frische-Tradeoffs.

Braucht Google 2026 noch Prerendering?

Weniger als zuvor — Googlebot führt jetzt JavaScript aus. Aber: Rendering ist die Engpass-Phase von Googles Crawl; vor-gerendertes HTML wird schneller und zuverlässiger indexiert. Andere Crawler (Bingbot, Social Media, LLM-Training-Scraper) handhaben JS schlechter, sodass Prerendering sich weiterhin auszahlt.

Was ist der Unterschied zwischen Prerendering und Static Site Generation (SSG)?

SSG ist eine Form des Prerenderings — speziell die Build-Zeit-Variante. Prerendering ist das breitere Konzept, das auch dynamische und inkrementelle Ansätze abdeckt.

Sollte ich Prerender.io nutzen oder mit SSG neu bauen?

Prerender.io ist eine Stopgap-Lösung für Legacy-SPAs, die nicht refactored werden können. Wenn du auf Next.js, Astro oder SvelteKit mit ihrem nativen SSG/ISR neu bauen kannst, ist das fast immer die bessere Langzeit-Antwort.

Wie wirkt sich Prerendering auf Deploy-Zeit aus?

Für SSG mit Tausenden von Routen kann die Build-Zeit explodieren (Stunden). Strategien: parallele Builds, Build-Artefakte cachen, ISR für den Long-Tail (nur Top-Routen statisch bauen + Rest on-demand regenerieren).

Kann ich authentifizierte Seiten vorrendern?

Tu's nicht — Auth-State ist pro Nutzer, und das gleiche statische HTML an alle Nutzer zu servieren, leakt Informationen oder bricht Personalisierung. Nutze SSR oder CSR für Auth-gated Content.

Wie LoadFocus zu Prerendering steht

Prerendering verbessert LCP und TTFB, aber die Gewinne zeigen sich nur, wenn dein CDN- + Caching-Setup das vor-gerenderte HTML korrekt serviert. LoadFocus-Website-Speed-Testing validiert, dass vor-gerenderte Routen tatsächlich Core-Web-Vitals-Ziele (LCP ≤2,5s, INP ≤200ms, CLS ≤0,1) in Production treffen. Lasttest validiert, dass der Regenerations-Workflow (ISR, dynamisches Prerender) unter Traffic durchhält — häufiger Fehlermodus ist, dass der Regenerator während Cache-Stampede-Szenarien überlastet wird.