The Rari SSR Breakthrough: 12x Faster, 10x Higher Throughput Than Next.js

Three months ago, I shipped Rari with numbers that felt impossible: 4x faster component rendering than Next.js, 3.74x higher throughput, and 5.8x faster builds. The framework was genuinely fast. The community responded with enthusiasm. I was proud of what we’d built.

Then I couldn’t shake a feeling: we’d left something on the table.

I kept looking at the architecture, at how React Server Components were supposed to work, at the patterns emerging in production React apps. We had speed, but we were missing something fundamental. The app router wasn’t there. True server-side rendering wasn’t there. The use directive semantics weren’t quite right.

So we went back and built the missing pieces properly.

The result surprised even me. Not just faster—fundamentally better align…

Then I couldn’t shake a feeling: we’d left something on the table.

So we went back and built the missing pieces properly.

The result surprised even me. Not just faster—fundamentally better aligned with how React Server Components were designed to work. And the performance numbers reflect that alignment.

What We Discovered

When we added proper app router support, true SSR, and correct RSC semantics, something remarkable happened:

Response times dropped to 0.69ms (3.8x faster than Next.js)
Throughput jumped to 20,226 req/sec (10.5x higher than Next.js)
P99 latency under load: 4ms (12x faster than Next.js)
Bundle sizes: 68% smaller (27.6 KB vs 85.9 KB)

These aren’t incremental improvements. This is what happens when your architecture matches React’s design intentions.

The Three Missing Pieces

Looking back, I realize we’d shipped Rari with some architectural gaps. Not bugs—gaps. We could render React Server Components, but we weren’t doing it the right way. Here’s what we added:

1. The App Router

I used to think the app router was just about file-based routing. I was wrong.

The app router is how your framework understands your application. During build, Rari now analyzes every route, every component, determining exactly what needs to run on the server and what needs to hydrate on the client.

This unlocks:

Automatic code splitting based on route boundaries
Intelligent prefetching of dependencies
Zero-config RSC rendering directly from your routes
Proper dependency graph analysis across the entire app

// app/layout.tsx - Server component by default
export default function Layout({ children }) {
return (
<html>
<body>{children}</body>
</html>
)
}

// app/dashboard/page.tsx - Server component by default
export default async function Dashboard() {
const data = await fetchUserData()
return (
<div>
<h1>{data.name}</h1>
<DashboardClient initialData={data} />
</div>
)
}

The moment we added this, bundle sizes dropped. The framework finally knew what belonged where.

2. Correct Use Directive Semantics

We had the directives wrong. Not broken—just wrong enough to cause confusion.

Here’s what I learned: 'use server' doesn’t mark server components. It marks server functions. Server components are the default. No directive needed.

This is simpler and eliminates an entire category of confusion:

// Server function - handles mutations, database access
'use server'

export async function updateUser(userId: string, data: FormData) {
await db.users.update(userId, Object.fromEntries(data))
revalidatePath('/dashboard')
}

// Server component - fetches data, renders markup (no directive needed)
export async function UserCard({ userId }: { userId: string }) {
const user = await fetchUser(userId)
return (
<div>
<h2>{user.name}</h2>
<UpdateForm userId={userId} onSubmit={updateUser} />
</div>
)
}

// Client component - handles interactivity
'use client'

export function UpdateForm({
userId,
onSubmit
}: {
userId: string
onSubmit: (userId: string, data: FormData) => Promise<void>
}) {
const [isPending, setIsPending] = useState(false)

async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
e.preventDefault()
setIsPending(true)
await onSubmit(userId, new FormData(e.currentTarget))
setIsPending(false)
}

return (
<form onSubmit={handleSubmit}>
<input name="name" required />
<button disabled={isPending}>
{isPending ? 'Saving...' : 'Save'}
</button>
</form>
)
}

Once we aligned with React’s actual design, everything clicked. The mental model simplified. The code got clearer.

3. True Server-Side Rendering

Before, we were doing what I’d call “RSC-flavored rendering.” Components ran on the server, but the hydration story wasn’t complete.

Now everything renders on the Rust runtime by default. The client receives pre-rendered HTML and RSC payloads, then hydrates only the interactive bits.

This eliminates three major performance bottlenecks:

Client-side hydration overhead — The tree doesn’t re-render to become interactive
JavaScript parsing delay — Interactive components are already wired up
Cascading waterfall requests — Data is fetched server-side during render

The Rust runtime handles RSC rendering with minimal overhead, delivering HTML directly to the client. No ceremony. No layers. Just fast.

The New Numbers

With these three pieces in place, here’s what happened:

Response Time: 3.8x Faster Than Next.js

Metric	Rari	Next.js	Improvement
Avg Response	0.69ms	2.58ms	3.8x faster
P95	1.15ms	3.37ms	2.9x faster
Bundle Size	27.6 KB	85.9 KB	68% smaller

Throughput Under Load: 10.5x Better

We stress-tested with 50 concurrent connections for 30 seconds:

Metric	Rari	Next.js	Improvement
Throughput	20,226 req/sec	1,934 req/sec	10.5x higher
Avg Latency	2.04ms	25.25ms	12.4x faster
P99 Latency	4ms	48ms	12x faster
Errors	0	0	Stable

Build Performance: Stayed Consistent

Metric	Rari	Next.js
Build Time	1.64s	9.11s
Bundle Size	273 KB	742 KB

Build times barely changed because we were already leveraging Rolldown and tsgo optimally. The real wins were in runtime performance and bundle size.

Why Performance Improved

Better architecture plus correct semantics equals better performance. Here’s the breakdown:

Smaller Bundles (68% reduction)

Only interactive components ship to the client. Server components stay on the server. The app router eliminates dead code. The framework finally knows what the client actually needs.

Lower Latency (3.8x faster)

SSR means no client-side hydration wait. The Rust runtime renders faster than JavaScript. RSC rendering starts immediately. No layers between your components and the client.

Higher Throughput (10.5x)

The persistent Rust runtime handles connection pooling efficiently. Concurrent request handling is optimized at the runtime level. No per-request overhead from spinning up Node.js contexts.

Predictable Performance

No garbage collection pauses. No event loop blocking. Linear scaling with more instances. The kind of predictability you need in production.

The Lesson: Alignment Matters

Here’s what I learned from this: great performance comes from alignment. When your implementation matches the underlying design philosophy, speed follows naturally.

React Server Components were designed with a specific model: server components by default, client components when you need interactivity, and a clean boundary between the two. Once we fully embraced that model, the performance gains weren’t incremental—they were exponential.

This isn’t just about Rari being fast. It’s about proving that you can have both great performance and great developer experience when you build the foundation correctly.

What This Means

For Users

Faster First Paint: HTML arrives immediately from the server
No JavaScript Parsing Delay: Interactive components hydrate instantly
Lower Memory Usage: The client only runs code for interactive features
Better Performance Under Load: The server handles the heavy lifting

For Developers

Same DX: 'use server' and 'use client' directives work exactly as you’d expect
Hot Module Replacement: Change a server component and see it update instantly
Full TypeScript Support: Complete type safety across the client/server boundary
Zero Config: Build, bundle, and RSC setup are automatic

For Business

Lower Server Costs: Smaller client JavaScript means fewer resources needed
Better Scalability: The Rust runtime handles 10.5x more concurrent requests
Predictable Performance: No garbage collection pauses under load

Getting Started

The API hasn’t changed. If you’ve tried Rari before, upgrading is a single version bump:

npm install rari@latest
npm run dev

New to Rari? Start here:

npm create rari-app@latest my-app
cd my-app
npm run dev

You don’t need to think about any of this. The framework handles it:

Hot module replacement works for both server and client components
TypeScript inference across the client/server boundary
Error boundaries and Suspense work as expected
Form actions and revalidation are built-in

Open Source, Completely Reproducible

All benchmarks are reproducible. The test applications and scripts are at github.com/rari-build/benchmarks.

Test Environment:

Hardware: MacBook Pro M2, 8GB RAM
Test Duration: 30 seconds with warmup
Concurrent Users: 50 simultaneous connections
Real-world patterns: data fetching, nested components, client interactivity

Run the benchmarks yourself and share your results. I’m genuinely curious what numbers you see on different hardware.

What’s Next

This is just the beginning. With SSR and app router now in place, we’re focusing on:

Streaming RSC for progressive rendering (framework support added, testing in progress)
Advanced RSC patterns for suspense and edge-case support
Ecosystem integrations with popular libraries and services
Production case studies from teams using Rari in real applications

Join Us

If you believe that performance and developer experience shouldn’t be mutually exclusive, I’d love to have you:

Try Rari at rari.build
Star us at github.com/rari-build/rari
Contribute to the framework or ecosystem
Join our Discord for real-time discussions and support

We built Rari because we believed we could do better. These benchmarks prove it. Now we’re building the features and ecosystem to match.

The web deserves frameworks that are both fast and beautiful to work with. That’s what we’re delivering.

Similar Posts