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

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 →