SSR oder Pre-Rendering? Was wir für Mykeythai gegen unseren Standard-Ansatz geprüft haben

Kontext: Am 13. Mai hat Lovable Discoverability released – inklusive echtem Server-Side-Rendering über TanStack Start. Direkt danach haben wir uns mit dem Mykeythai-Team zusammengesetzt und die Frage gestellt: Stellen wir um? Hier ist die Antwort.

Die Ausgangslage

Mykeythai ist eine kuratierte Villa-Plattform für Thailand: Villa-Detailseiten, Destination-Hubs, Things-to-do, ein Journal, SEO-Landingpages, Agent-PDFs. Klassisches Content-lastiges Travel-Setup mit punktueller Dynamik (Verfügbarkeit, Anfragen, Preisabfragen).

Bisher läuft die Seite – wie alle unsere Builds – auf unserer Playwright-SSG-Pipeline: React-SPA, zur Build-Zeit pro Route zu statischem HTML gerendert, JSON-LD und Meta-Tags injiziert, auf das Edge-Netz deployed.

Mit dem Lovable-Release stand plötzlich ein echter SSR-Pfad zur Verfügung. Also: prüfen.

Der Kurzvergleich

	Pre-Rendering / SSG	Server-Side Rendering (SSR)
Geschwindigkeit	Sehr schnell	Oft langsamer
Hosting-Kosten	Gering	Höher
Skalierung	Einfach	Aufwendiger
SEO	Sehr gut	Sehr gut
Core Web Vitals	Meist besser	Schwankender
Dynamische Inhalte	Schlechter	Sehr gut
Cachebarkeit	Exzellent	Komplexer
Fehleranfälligkeit	Gering	Höher
TTFB	Sehr niedrig	Höher
Hydration-Probleme	Weniger	Häufiger

Auf dem Papier liest sich das wie eine klare Sache. In der Praxis hängt es komplett am Use-Case.

Warum Mykeythai SSG-affin ist

Schauen wir uns an, was die Seite ausmacht:

• Villa-Detailseiten – ändern sich vielleicht wöchentlich
• Journal-Artikel – pro Artikel ein Publish-Event
• Destination-Hubs – kuratierte Inhalte, selten geupdatet
• Things-to-do – redaktionell gepflegt
• Areas / Regionen – statische Inhalte
• SEO-Landingpages – auf Suchintention optimiert, stabil
• About / Brand – ändert sich quartalsweise

Das ist Lehrbuch-Content für Pre-Rendering. Inhalte ändern sich nicht sekündlich, SEO und Performance sind wichtiger als Echtzeit-Daten, jede einzelne Seite hat eine klare URL und eine klare Suchintention.

Genau deshalb wirken Referenzen wie Plum Guide, Le Collectionist oder Airbnbs SEO-Landingpages so schnell: aggressives Static Rendering plus globales CDN. Niemand rendert eine Villa-Detailseite live auf einem Node-Server, wenn der Inhalt 99 % der Zeit identisch ist.

Wo SSR trotzdem Sinn ergibt

Es gibt Bereiche, in denen statisches Rendering nicht reicht:

• Eingeloggte Dashboards – pro Nutzer unterschiedlich
• Personalisierte Inhalte – z. B. „Empfohlen für dich"
• Live-Verfügbarkeiten – Kalender, Buchungsslots
• Suche & Filter mit vielen Kombinationen
• Dynamische Preise – Saison, Belegung, Promotion
• User-spezifische Daten – Agent-Portale, gespeicherte Favoriten

Für Mykeythai betrifft das konkret: Verfügbarkeitskalender, Anfrageformulare, Preisabfragen, Agent-Portal, Suche/Filter, eventuell Live-Wetterdaten.

Die Architektur, für die wir uns entschieden haben

Statt „alles SSR" oder „alles SSG" haben wir die Seite in zwei Zonen aufgeteilt:

Pre-Rendered (SSG)

/                       → Home
/villas/[slug]          → Villa Detail
/journal/[slug]         → Journal-Artikel
/destinations/[slug]    → Destination Hubs
/things-to-do/[slug]    → Aktivitäten
/areas/[slug]           → Regionen
/lp/[slug]              → SEO-Landingpages
/agents/pdf/[id]        → Agent-PDFs
/about, /brand          → Brand-Seiten

→ Build-Time-Rendering, JSON-LD injiziert, auf Edge ausgeliefert. TTFB < 50 ms weltweit.

Dynamisch (SSR / Edge-Functions / Client)

/api/availability       → Kalender, Edge-Function
/api/inquiry            → Anfrageformular, serverless
/api/pricing            → Preisabfrage, Edge
/agent/portal/*         → SSR (Auth-gated)
/search                 → Client-side mit Edge-Suche

→ Nur diese Routen brauchen einen lebenden Server. Der Rest bleibt statisch.

Das ist die Dynamic-Islands-Logik: 95 % der Seite ist statisch, kleine interaktive Inseln (Kalender, Preisbox) laden ihre Daten clientseitig nach. Kein Grund, eine komplette Villa-Detailseite per SSR zu rendern, nur weil unten ein Verfügbarkeitskalender hängt.

Der typische Fehler im Lovable/Vercel/Supabase-Stack

Wir sehen in Audits regelmäßig das gleiche Muster: Projekte rendern unnötig viel per SSR. Die Symptome sind immer dieselben:

• höhere TTFB
• weiße Screens beim Laden
• doppelte Requests (SSR + Client-Refetch)
• „Page disappears and reloads" nach Hydration
• inkonsistente Cache-Control-Header
• schlechtere Lighthouse-Werte trotz starker Hardware

Das deckt sich mit Beobachtungen, die das Mykeythai-Team auf anderen Plattformen schon gemacht hatte: kurzfristig weiße Seite, erneutes Laden, inkonsistente Caching-Header. Klassische Symptome für SSR + Client-Hydration-Mismatches, unnötige Runtime-Requests oder Streaming-Edge-Mismatches.

Mit dem Lovable-Release ist SSR jetzt zwar einfach verfügbar – aber das macht es nicht automatisch zur richtigen Wahl.

Warum das auch für GEO / AI-Search zählt

LLMs und AI-Crawler (ChatGPT, Perplexity, Claude, Google AI Overviews) bevorzugen stabile, schnelle, sofort verfügbare HTML-Inhalte. Sie warten nicht auf Hydration. Sie folgen keinen useEffect-Ketten. Sie sehen, was im ersten Response steht.

Wir haben das mit Log-Evidenz untermauert: drei Monate Edge-Logs zeigen, dass GPTBot, ClaudeBot und PerplexityBot praktisch kein JavaScript ausführen – sie lesen ausschließlich das initiale HTML. Die vollständige Auswertung steht in GPTBot, ClaudeBot, PerplexityBot: Was AI-Crawler bei Prerendering wirklich sehen.

Pre-Rendering ist hier strukturell im Vorteil: vollständiges HTML, deterministisch, mit JSON-LD im <head>. Genau das, was wir in unserer SEO-Master-Strategy als Default behandeln und was wir auch im Vibe Coding SEO Guide ausführlich beschreiben.

Die Entscheidung für Mykeythai

Wir bleiben beim Pre-Rendering-Default und ergänzen punktuell:

1. Alle Content-Routen weiterhin via Playwright-SSG (unverändert)
2. Verfügbarkeit / Preise als Edge-Function mit clientseitigem Aufruf
3. Agent-Portal als isolierte SSR-Route (Auth-gated, separater Bundle)
4. Suche clientseitig gegen eine Edge-Suche (Typesense / Algolia / Cloudflare)

Damit halten wir Core Web Vitals oben, Hosting-Kosten unten und Crawler-Output sauber – ohne auf dynamische Funktionen zu verzichten, wo sie wirklich gebraucht werden.

Take-aways für andere Projekte

• SSR ist kein Upgrade. Es ist ein Trade-off. Mehr Dynamik, mehr Komplexität, höhere Kosten, mehr Fehlerquellen.
• Default sollte SSG sein. Erst wenn ein konkreter Use-Case statisches Rendering bricht, SSR ergänzen.
• Denk in Zonen, nicht in „die ganze App". Die meisten Seiten sind zu 95 % statisch.
• Lovable macht beides einfach. Das Release ist gut – aber die Architektur-Entscheidung musst du trotzdem treffen.

Wer gerade vor der gleichen Frage steht: Wir zeigen die Pipeline live bei TokenMade in Hamburg – inklusive der Mykeythai-Architektur als Case.

👉 Kostenloses SEO-Audit für deine Vibe-Coding-App →