SSR or Pre-Rendering? What We Evaluated for Mykeythai vs. Our Default Approach

Context: On May 13th, Lovable released Discoverability – including real server-side rendering via TanStack Start. Right after, we sat down with the Mykeythai team and asked: do we switch? Here's the answer.

The Starting Point

Mykeythai is a curated villa platform for Thailand: villa detail pages, destination hubs, things-to-do, a journal, SEO landing pages, agent PDFs. A classic content-heavy travel setup with selective dynamics (availability, inquiries, pricing).

So far the site runs – like all our builds – on our Playwright SSG pipeline: React SPA, rendered to static HTML per route at build time, JSON-LD and meta tags injected, deployed to the edge network.

With the Lovable release, a real SSR path suddenly became available. So: evaluate.

The Quick Comparison

	Pre-Rendering / SSG	Server-Side Rendering (SSR)
Speed	Very fast	Often slower
Hosting cost	Low	Higher
Scaling	Easy	More complex
SEO	Very good	Very good
Core Web Vitals	Usually better	More variable
Dynamic content	Worse	Excellent
Cacheability	Excellent	More complex
Failure modes	Few	More
TTFB	Very low	Higher
Hydration issues	Fewer	More common

On paper this looks like a clear-cut decision. In practice it depends entirely on the use case.

Why Mykeythai Is SSG-Friendly

Let's look at what makes the site:

• Villa detail pages – change maybe weekly
• Journal articles – one publish event per piece
• Destination hubs – curated content, rarely updated
• Things-to-do – editorially maintained
• Areas / regions – static content
• SEO landing pages – optimized for search intent, stable
• About / Brand – changes quarterly

This is textbook content for pre-rendering. Content doesn't change by the second, SEO and performance matter more than real-time data, every single page has a clear URL and a clear search intent.

That's exactly why references like Plum Guide, Le Collectionist or Airbnb's SEO landing pages feel so fast: aggressive static rendering plus a global CDN. Nobody renders a villa detail page live on a Node server when the content is identical 99% of the time.

Where SSR Still Makes Sense

There are areas where static rendering isn't enough:

• Authenticated dashboards – different per user
• Personalized content – e.g. "Recommended for you"
• Live availability – calendars, booking slots
• Search & filter with many combinations
• Dynamic pricing – season, occupancy, promotion
• User-specific data – agent portals, saved favorites

For Mykeythai this concretely means: availability calendar, inquiry forms, pricing requests, agent portal, search/filter, possibly live weather data.

The Architecture We Chose

Instead of "all SSR" or "all SSG", we split the site into two zones:

Pre-Rendered (SSG)

/                       → Home
/villas/[slug]          → Villa Detail
/journal/[slug]         → Journal articles
/destinations/[slug]    → Destination hubs
/things-to-do/[slug]    → Activities
/areas/[slug]           → Regions
/lp/[slug]              → SEO landing pages
/agents/pdf/[id]        → Agent PDFs
/about, /brand          → Brand pages

→ Build-time rendering, JSON-LD injected, delivered from the edge. TTFB < 50ms globally.

Dynamic (SSR / Edge Functions / Client)

/api/availability       → Calendar, edge function
/api/inquiry            → Inquiry form, serverless
/api/pricing            → Pricing request, edge
/agent/portal/*         → SSR (auth-gated)
/search                 → Client-side against edge search

→ Only these routes need a live server. The rest stays static.

This is the dynamic islands logic: 95% of the site is static, small interactive islands (calendar, pricing box) fetch their data client-side. No reason to SSR-render an entire villa detail page just because there's an availability calendar at the bottom.

The Typical Mistake in the Lovable/Vercel/Supabase Stack

In audits we regularly see the same pattern: projects render way too much via SSR. The symptoms are always the same:

• higher TTFB
• white screens on load
• duplicate requests (SSR + client refetch)
• "page disappears and reloads" after hydration
• inconsistent Cache-Control headers
• worse Lighthouse scores despite strong hardware

This matches observations the Mykeythai team had already made on other platforms: temporary white screen, reload, inconsistent caching headers. Classic symptoms of SSR + client hydration mismatches, unnecessary runtime requests, or streaming/edge mismatches.

With the Lovable release, SSR is now easy to enable – but that doesn't make it the right choice automatically.

Why This Matters for GEO / AI Search Too

LLMs and AI crawlers (ChatGPT, Perplexity, Claude, Google AI Overviews) prefer stable, fast, immediately available HTML content. They don't wait for hydration. They don't follow useEffect chains. They see what's in the first response.

Pre-rendering is structurally favored here: complete HTML, deterministic, with JSON-LD in <head>. Exactly what we treat as the default in our SEO master strategy and what we describe in detail in the Vibe Coding SEO guide.

The Decision for Mykeythai

We stick with the pre-rendering default and add selectively:

1. All content routes stay on Playwright SSG (unchanged)
2. Availability / pricing as edge functions called client-side
3. Agent portal as an isolated SSR route (auth-gated, separate bundle)
4. Search client-side against an edge search index (Typesense / Algolia / Cloudflare)

This keeps Core Web Vitals high, hosting costs low, and crawler output clean – without giving up dynamic features where they're actually needed.

Takeaways for Other Projects

• SSR is not an upgrade. It's a trade-off. More dynamism, more complexity, higher cost, more failure modes.
• The default should be SSG. Only add SSR when a concrete use case breaks static rendering.
• Think in zones, not in "the whole app". Most pages are 95% static.
• Lovable makes both easy. The release is great – but you still have to make the architecture decision yourself.

If you're facing the same question right now: we'll show the pipeline live at TokenMade in Hamburg – including the Mykeythai architecture as a case.

👉 Free SEO audit for your Vibe Coding app →