---
type: "Comparison"
title: "ostr.io vs Vercel SSR - when to pre-render instead of SSR"
description: "Should crawler traffic hit Vercel SSR or a pre-rendering layer? Function execution cost, cache behaviour, and migration paths for Next.js apps."
resource: "https://prerender.info/compare/vs-vercel-ssr"
tags: [compare, vercel ssr alternative, next.js ssr cost, pre-rendering for next.js, vercel function pricing seo, dynamic rendering vs ssr]
timestamp: 2026-04-21T00:00:00Z
---

# ostr.io vs Vercel SSR - when to pre-render instead of SSR

Should crawler traffic hit Vercel SSR or a pre-rendering layer? Function execution cost, cache behaviour, and migration paths for Next.js apps.

## Server-side rendering on Vercel

Server-side rendering on Vercel runs your Next.js app as a serverless function on every request, generating HTML at the edge. Cost scales with request volume and function duration; it does not deduplicate repeat crawler traffic.

## Verdict

**Choose ostr.io if**

- Your Next.js app has more crawler traffic than user traffic on catalog pages.
- You want to cap Vercel function execution cost without refactoring routes to ISR.
- You run a non-Next.js SPA (Nuxt, SvelteKit, Remix, vanilla React) and need a framework-agnostic layer.
- You want a hybrid model where hot routes stay SSR and the long tail becomes cheap for crawlers.

**Choose Vercel SSR if**

- You are on Vercel Enterprise and already inside their function-execution budget.
- Your Next.js app is new, small (< 1,000 pages), and ISR already covers the content model.
- All content is authenticated and not meant to be indexed.
- Your SEO-critical pages need real-time per-request HTML for both users and bots.

### Feature comparison — April 2026

Feature parity between ostr.io and Vercel SSR. The rows below are the ones engineering teams ask about in vendor due diligence.

| Capability | ostr.io | Competitor |
| --- | --- | --- |
| Framework support | Framework-agnostic (React, Vue, Svelte, vanilla) | Next.js only |
| Crawler cost isolation | Crawler traffic hits cache, not origin | Every crawler hit runs a function |
| Cache TTL granularity | Per-URL TTL + purge API | ISR revalidate per route |
| Cold start | Pre-rendered HTML, no cold start | Lambda cold start 200-600ms |
| Bundle size impact | Zero client bundle changes | SSR requires server runtime |
| Hybrid route control | Per-route bot routing | Possible, but tied to app architecture |
| AI crawler cost isolation | AI bots hit cached HTML | AI bots execute app runtime |
| Migration effort | Middleware layer, no rewrite | Often requires framework commitment |
| Freshness on live-user pages | Cache-policy bounded | Per-request real time |

### Pricing at 10k / 100k / 1M URLs

Pricing verified against each vendor's public page in April 2026. "Not publicly disclosed" appears where Vercel SSR uses custom-only quoting.

| Scale tier | ostr.io | Competitor |
| --- | --- | --- |
| 10,000 URLs, weekly refresh | Starts $49/mo | Pro plan + function execution (~$80/mo) |
| 100,000 URLs, daily refresh | Starts $199/mo | Pro plan + execution (~$500+/mo) |
| 1M URLs, event-driven refresh | Custom, ~$1,200/mo | Enterprise (quote only) |
| Annual cost predictability | Tier-based forecast is stable | Function spikes distort monthly spend |
| Crawler surge resilience | Cost mostly absorbed by cache | Every surge hits execution budget |

Vercel SSR is excellent for small Next.js apps. ostr.io wins for framework-agnostic sites and anywhere crawler traffic exceeds 10% of total hits — the function cost shifts into a flat pre-rendering bill.

## Function execution is the hidden cost on Vercel

Vercel's Pro plan includes a function execution quota, but crawler traffic consumes it quickly. A 100k-URL catalogue with weekly Googlebot crawls routinely triggers 500,000+ function executions per month, which pushes most teams over the Pro quota into Enterprise pricing. If you are already seeing this on high-fanout routes, cross-check the scale assumptions in [large sites (100k+ pages)](/guides/large-sites-100k-pages.md).

Pre-rendering removes this entire workload from Vercel functions. Crawler traffic hits a static HTML cache served from the edge; human traffic continues to hit the SSR function as usual. That split is the practical version of the model described in [dynamic rendering vs SSR](/technology/dynamic-rendering-vs-ssr.md).

The counterintuitive part is that SSR can still feel cheap in development and early production because human traffic is modest. The bill bends upward only after crawler demand compounds across product pages, categories, docs, changelogs, and any long-tail routes that bots revisit more often than humans do.

## ISR is not the same as dynamic rendering

Next.js ISR regenerates HTML on a revalidate timer, but the first request after expiry still pays the full SSR cost. Under crawler fan-out, that means repeated SSR spikes every time Googlebot refreshes a category page; the problem is most obvious on [SaaS marketing and docs surfaces](/use-cases/saas.md) and on large catalogues.

Pre-rendering is scheduled by the render pool, not triggered by the first incoming request. The snapshot is already hot when Googlebot arrives, which flattens the function-execution curve. If your concern is total browser and render spend rather than Vercel alone, read [JavaScript rendering cost](/guides/javascript-rendering-cost.md).

What most guides skip is that ISR solves freshness and build-time pain better than it solves crawler-cost isolation. If the business problem is 'Googlebot keeps re-running expensive routes,' ISR helps less than people expect because the crawler still lands on application infrastructure, not on a dedicated crawler-facing cache.

## The right model is usually route classification, not platform loyalty

A practical route map looks like this: homepage, pricing, and a few flagship landing pages can stay SSR or ISR; large category sets, docs archives, changelogs, and evergreen long-tail content can move to pre-rendered delivery for crawlers; authenticated routes should stay out of the index entirely. That division matches engineering reality better than trying to force one rendering model onto every URL.

In practice, teams that classify routes early spend less time arguing about ideology. They stop asking whether SSR is 'better' and start asking which URLs actually need per-request computation. That is also the point where [pre-render cache headers](/guides/prerender-cache-headers.md) and [crawl budget fundamentals](/guides/crawl-budget.md) become more useful than generic framework discussions.

## The 12-month TCO story matters more than the first invoice

At 10k URLs, the gap between Vercel SSR and a managed pre-rendering layer can look small enough to ignore. Over 12 months, that view gets distorted by two things: crawler spikes after new sitemap launches and engineering time spent tuning route caching, revalidate settings, and origin protection. The spend is not just infrastructure; it is also attention.

ostr.io compresses that operating model into a bounded rendering tier. Vercel SSR remains strong where the same route must be fresh for humans and bots at the same time. The moment you can separate those concerns, the long-tail cost curve usually starts favoring pre-rendering.

## Non-Next.js apps get SSR-equivalent results without the framework lock-in

SvelteKit, Nuxt, Remix and vanilla React apps do not have first-party Vercel SSR semantics. Pre-rendering is framework-agnostic: the snapshot pool consumes the rendered DOM regardless of how your app produced it, which is why it fits mixed estates better than committing the whole organization to one SSR runtime.

Teams running multiple frontend frameworks behind a single domain (for example microfrontend architectures) find a single pre-rendering layer easier to operate than coordinating three different SSR runtimes. If you are evaluating Vercel against another non-framework option, compare this page with [ostr.io vs Cloudflare](/compare/vs-cloudflare.md).

One caveat: if the whole organization is already standardized on Next.js and the public indexable surface is small, framework lock-in may not be a real problem. It becomes a problem when the rendering decision starts driving org-wide platform choices instead of simply solving crawler-facing HTML delivery.

## When Vercel SSR still wins

Vercel SSR still makes sense when the app is new, tightly tied to Next.js, and most of the value comes from user-facing freshness rather than crawler-cost isolation. Teams with a small public surface, strong Next.js conventions, and low crawler volume often do not need a second rendering layer yet.

The cut-over usually happens when public routes multiply faster than product teams can optimize SSR, or when crawler traffic becomes a visible line item. That is the moment to compare Vercel not only to ostr.io, but also to the broader architectural decision in [dynamic rendering vs SSR](/technology/dynamic-rendering-vs-ssr.md).

## When ostr.io is the wrong fit

ostr.io is the wrong fit if your key indexed routes are heavily personalized at request time, or if regulatory, account-level, or user-state conditions change the primary HTML so often that a crawler-facing cache cannot stay meaningfully representative. In that case SSR or tightly controlled ISR is the safer path.

It is also the wrong fit when the site barely has an indexable public surface. If 90% of the application lives behind login and the public marketing site is 50 pages, the simpler answer may be to keep Vercel SSR or even static generation and avoid adding another operational layer.

### Next.js middleware — forward crawler traffic to ostr.io

Keep Vercel SSR for human traffic; redirect bot traffic to the pre-rendered snapshot. One middleware file, no route changes.

```typescript
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

const BOT_REGEX = /bot|crawler|spider|googlebot|bingbot|applebot|duckduckbot/i;

export function middleware(req: NextRequest) {
  const ua = req.headers.get("user-agent") ?? "";
  if (!BOT_REGEX.test(ua)) return NextResponse.next();

  const render = new URL(
    `https://render.ostr.io/render?url=${encodeURIComponent(req.nextUrl.toString())}`,
  );
  return NextResponse.rewrite(render);
}

export const config = { matcher: "/((?!_next|api|og|static).*)" };
```

## FAQ

### Does pre-rendering replace Next.js SSR?

No. Pre-rendering sits in front of your Next.js app and intercepts crawler traffic only. Users continue to hit SSR or client-side routes as before; nothing changes for the user-facing runtime.

### Is ISR enough for SEO?

ISR is enough for small, low-fanout sites. It does not protect against crawler storms on 100k+ URLs because the first request after the TTL still pays the full SSR cost. Pre-rendering decouples rendering from request volume.

### What about Vercel's Edge Middleware?

Edge Middleware is complementary. Most teams install ostr.io by writing an Edge Middleware that forwards bot UA traffic to the render endpoint. Edge Middleware itself is not a pre-rendering layer.

### Will we pay for Vercel functions on crawler traffic anymore?

Not on pages that the crawler hits. Googlebot, Bingbot and AI crawlers are routed to the pre-rendered cache, so they never invoke a Vercel function. You keep paying for function execution on human traffic only.

### Do we still use getServerSideProps?

Yes. Keep getServerSideProps for user-facing logic. The pre-rendering service captures the output of your SSR-rendered page, so the logic still runs on the snapshot pool — the difference is where the output is served from.

## Related

- [Technology — dynamic rendering vs SSR](/technology/dynamic-rendering-vs-ssr.md) — Deep dive into the rendering model before you pick between them.
- [ostr.io vs Prerender.io](/compare/vs-prerender-io.md) — Managed pre-rendering head-to-head with the original service.
- [ostr.io vs Cloudflare](/compare/vs-cloudflare.md) — Workers + KV cache as a pre-rendering alternative.
- [Guide — JavaScript rendering cost](/guides/javascript-rendering-cost.md) — The headless-browser budget at 10k / 100k / 1M URLs.
- [Use case — SaaS platforms](/use-cases/saas.md) — Next.js dashboards with public marketing surfaces.
- [Guide — large sites 100k+ pages](/guides/large-sites-100k-pages.md) — Sharding sitemaps + pre-render scheduling for large catalogues.

## Source

Generated from prerender.info editorial content (single source of truth). The canonical, always-current version is the `resource` URL above. Claims reflect prerender.info / ostr.io editorial guidance and are not confirmed from third-party public documentation unless explicitly linked.