Server rendering benchmarks: Fluid Compute and Cloudflare Workers

Why server-side rendering performance varies so much by platform

Independent developer Theo Browne has published a benchmark suite comparing server-side rendering performance between Vercel's Fluid compute and Cloudflare Workers. Across 100 iterations on Next.js, React, SvelteKit, and other frameworks, Fluid compute finished compute-bound tasks 1.2 to 5 times faster, with narrower response-time spreads.

The comparison is not strictly apples-to-apples: each platform ran its typical production setup. Cloudflare Workers used standard constraints (shared CPU, 128MB RAM), while Fluid compute ran with performance functions (2 vCPU, 4GB RAM). Those defaults reflect the platforms' differing philosophies — Cloudflare's constraints enable global edge distribution, while Fluid's in-cloud model allows configurable resources.

Head-to-head framework results

Across those workloads, Fluid compute averaged 2.55 times faster. The variance column tells a fuller story. For Next.js, Cloudflare responses spanned 3.171 seconds (0.800s to 3.971s) versus Fluid's 1.098-second range (0.343s to 1.442s). Outliers were notable: roughly one in five Cloudflare requests on Next.js and SvelteKit exceeded 10 seconds on tasks averaging 1.2 seconds. A page that loads instantly for one user can stall for the next.

Because users experience individual requests rather than averages, consistency can matter more than a fast mean for production traffic.

The architecture behind Fluid compute

Fluid compute, Vercel's default runtime, makes deliberate trade-offs tuned for server rendering workloads.

Region co-location minimizes I/O latency

A server-rendered page typically makes several database queries and API calls during a single request. An application issuing five queries per request spends far more time waiting on data than rendering components. Fluid compute deploys in the same cloud region as your infrastructure — if your database is in AWS US-East-1, Fluid functions can run there too. That proximity cuts network round-trips for database queries, API calls, JSON serialization, schema validation, and other I/O-bound steps where location directly affects total request time.

Node.js compatibility without a compatibility layer

Cloudflare Workers execute on a custom JavaScript runtime that approximates Node.js behavior, but important gaps remain. performance.now(), for example, is unavailable on Cloudflare because the shared-memory isolate model froze the API as a Spectre mitigation. When code runs in an isolate rather than a VM, memory is shared with other workers, and security constraints limit which APIs can work.

Fluid compute runs standard Node.js and Python, with version selection down to Node.js 24 or any other release. The entire npm ecosystem functions without shims. Frameworks such as Next.js, Remix, and SvelteKit assume a real Node.js environment; when the runtime only approximates it, packages misbehave, edge cases surface, and debugging becomes harder because behavior diverges from documented Node.js semantics.

Concurrency and configurable resources

Fluid compute handles multiple function invocations concurrently on the same environment. Combined with scale-to-1, it keeps warm instances available and uses resources efficiently for rendering work.

Resources are tunable from 1–4 vCPU and up to 4GB RAM, so a lightweight middleware function can run with minimal allocation while compute-heavy server rendering or AI inference scales upward. Both platforms price by CPU time consumed.

Where edge deployment still fits

Edge distribution remains well suited to particular jobs. Static assets cached close to users serve quickly, and simple routing rules or header manipulation need neither database access nor heavy computation.

Fluid compute covers both ends of that spectrum on one platform: high concurrency handles middleware and simple APIs efficiently, while configurable resources absorb server rendering and complex application logic. The platform adapts to the workload rather than requiring the workload to fit the platform.

Accessing the benchmarks

The complete benchmark implementation, raw results, test code, and methodology documentation are available on GitHub. For workloads that query databases and perform compute during rendering, in-region deployment with full runtime compatibility delivers measurable and more consistent performance.