Prerendering TCO: Service vs Self-Host vs SSR

Article

Engineering leadership evaluating prerendering options typically compares three alternatives: managed prerendering service, self-hosted DIY Puppeteer, and SSR rewrite of the existing application. The correct comparison is total cost of ownership (TCO) over 3 years — not the monthly infrastructure cost in isolation.

ostr.io is a managed prerendering service that delivers deterministic HTML snapshots to search crawlers and AI retrieval systems through proxy-level middleware, without requiring framework rewrites.

The Three Options

Option A: Managed Prerendering Service (ostr.io)

Implementation cost: 1–3 days of engineering time for middleware configuration, WAF whitelist setup, and Cache Warming API integration. No infrastructure to provision.

Ongoing cost: per-render pricing. No engineering maintenance.

3-year TCO at 100k pages:

• Implementation: 2 engineer-days × $600/day = $1,200 (one-time)
• Monthly service: ~$500/month average (accounting for cache warming and growth)
• 36-month service: $18,000
• Engineering maintenance: ~0 hours/month
• 3-year total: ~$19,200

3-year TCO at 500k pages:

• Implementation: 3 engineer-days = $1,800 (one-time)
• Monthly service: ~$2,000/month average
• 36-month service: $72,000
• Engineering maintenance: ~0 hours/month
• 3-year total: ~$73,800

Option B: Self-Hosted DIY Puppeteer

Implementation cost: 2–4 weeks of engineering time to build: Puppeteer cluster, bot detection middleware, cache layer, WAF whitelist documentation, observability tooling.

Ongoing cost: compute infrastructure + engineering maintenance.

Implementation breakdown:

• Bot detection middleware: 2–3 days
• Puppeteer cluster setup: 3–5 days
• Cache layer (Redis + CDN): 2–3 days
• Observability tooling (Prometheus + Grafana): 3–5 days
• Testing and validation: 3–5 days
• Total: 13–21 engineer-days = $7,800–$12,600

Monthly ongoing costs at 100k pages:

• Compute (EC2 or equivalent for 2-node cluster): $200–400/month
• Engineering maintenance: 3–5 hours/month × $75/hour amortized = $225–375/month
• Total: $425–775/month

Engineering maintenance hours include:

• Memory leak detection and patching: 1–2 hours/month
• Bot UA database updates: 30–60 min/month
• WAF whitelist updates: 30–60 min/month
• Incident response for render failures: 1–2 hours/month average

3-year TCO at 100k pages:

• Implementation: $10,000 (average)
• 36-month operations: $600/month × 36 = $21,600
• 3-year total: ~$31,600

3-year TCO at 500k pages:

• Implementation: $15,000 (larger cluster, more complex config)
• Compute: $800–1,500/month
• Engineering maintenance: 6–10 hours/month = $450–750/month
• 36-month operations: $1,500/month × 36 = $54,000
• 3-year total: ~$69,000

At 500k pages, DIY and managed service have similar 3-year TCO. At 100k pages, DIY costs 65% more than managed service due to the fixed engineering overhead that does not scale down with lower render volume.

Option C: SSR Rewrite

An SSR rewrite converts a client-side React SPA to server-rendered Next.js (or similar). The application renders HTML on the server for every request — no prerendering service needed.

Implementation cost:

This is the largest variable. Scope depends on:

• Application size (number of routes, components, data fetching patterns)
• Existing code quality and test coverage
• Team familiarity with Next.js App Router
• Number of useEffect data fetching hooks to refactor
• Third-party library compatibility with SSR

Rough estimates:

• Small SPA (20–50 routes, clean codebase): 4–8 weeks = $48,000–96,000
• Medium SPA (50–150 routes, typical technical debt): 8–16 weeks = $96,000–192,000
• Large SPA (150+ routes, heavy client-side logic): 16–52 weeks = $192,000–624,000

These are engineering costs only. Add: project management, QA testing, staging environment, rollback planning, and opportunity cost of deferred feature development.

SSR ongoing costs:

Server-side rendering adds compute cost — every user request requires server-side processing (vs. CDN-served static assets). For high-traffic sites:

• 1M page views/month: +$200–800/month in origin compute (vs. CDN-served CSR)
• 10M page views/month: +$2,000–8,000/month in origin compute

3-year TCO for medium SPA (100 routes):

• Implementation: $120,000 (12 weeks × 2 engineers)
• Ongoing compute uplift: $300/month × 36 = $10,800
• Ongoing maintenance (SSR-specific issues: hydration mismatches, streaming bugs): 2–4 hours/month = $5,400–10,800
• 3-year total: ~$136,200–141,600

3-year TCO comparison:

The SSR rewrite consistently costs 4–7× more over 3 years than managed prerendering, even excluding the opportunity cost of blocked feature development during the rewrite.

The Hidden SSR Cost: Hydration Mismatches

SSR rewrites introduce a new class of bugs: hydration mismatches. When the server-rendered HTML differs from what React produces during client-side hydration, React logs errors, visual glitches occur, and navDemotion risk increases.

The categories of hydration mismatch causes:

• Timestamps, random IDs, or nondeterministic values rendered on server vs. client
• Data fetching that produces different results server-side vs. client-side
• Third-party libraries that access window or document during SSR
• Environment variables exposed on client vs. server

Debugging hydration mismatches requires specialized knowledge of the React hydration lifecycle. Teams that are not deeply experienced with Next.js SSR routinely spend 20–40% of the SSR rewrite timeline on hydration debugging.

Managed prerendering bypasses this entirely: the prerendering service executes the application in its natural client-side state, captures the fully hydrated DOM, and serves it as a static snapshot. No hydration mismatch risk for the crawler path.

When Each Option is Correct

Choose managed prerendering (ostr.io) when:

• You need SEO improvements without blocking feature development
• Engineering team is fully allocated to product features
• Timeline requires improvement in weeks, not quarters
• Site has unique rendering requirements (Shadow DOM, Canvas, Web Workers)
• SSR rewrite is technically risky (heavy third-party library dependencies)

Choose DIY Puppeteer when:

• You have platform engineering capacity with Puppeteer expertise
• Unique rendering requirements that no managed service supports
• Data sovereignty requirements prevent sending page content to external services
• Scale is large enough (1M+ renders/month) that managed service cost exceeds DIY at your engineering cost rate

Choose SSR rewrite when:

• Application is being rebuilt for other product reasons anyway
• Framework migration is already planned (e.g., Vue 2 → Vue 3 + Nuxt)
• Server compute cost is negligible relative to engineering capacity
• Long-term platform architecture benefits (SSR-native performance) outweigh short-term cost