docs/pro/react-server-components/success-stories.md
If you are deciding whether React Server Components are worth the effort, these case studies show what teams have actually measured after shipping RSC in production, alongside DoorDash's earlier pre-RSC Next.js SSR migration as a useful server-first baseline. The sections below summarize the reported wins, link to the source articles for verification, and point to the React on Rails Pro docs that walk you through getting the same benefits.
| Company | Scope | Headline Result | Source |
|---|---|---|---|
| DoorDash | Homepage and store pages (Next.js SSR migration, pre–App Router) | 65% LCP improvement on homepage, 67% on store pages | Improving Web Page Performance with Next.js |
| Mux | ~50,000 lines migrated to the App Router / RSC | Suspense-based streaming kept server code off the client bundle (no headline % published) | What are React Server Components? |
| Frigade | Embedded SaaS widget | 62% reduction in client-side bundle size | Bundle size reduction with RSC |
| Developerway (research piece) | Instrumented comparison of SSR, App Router, and Server Components-first apps | N/A — methodology analysis (no headline metric) | React Server Components performance |
All numbers and quotes below are from the linked source articles. Treat them as vendor-reported benchmarks — representative of what's possible, not a guarantee of what you will see.
Note: This case study predates React Server Components — it is included as a server-first rendering baseline, not an RSC benchmark. Do not cite these numbers as RSC results in stakeholder presentations.
DoorDash reported large Largest Contentful Paint (LCP) improvements after moving key surfaces onto Next.js server-side rendering. The write-up predates Next.js App Router / RSC, so treat the numbers as evidence for what server-first rendering (the same architectural shift RSC formalizes) can unlock — not as a direct RSC benchmark:
Why this matters for React on Rails teams. LCP is the Core Web Vital most tightly coupled to conversion and SEO. DoorDash's results are useful evidence for selling the business case to stakeholders who are skeptical that an architecture change can move revenue metrics. The same streaming-first rendering strategy is available in React on Rails Pro through stream_react_component — see Streaming SSR and RSC Rendering Flow.
Mux published a detailed account of moving roughly 50,000 lines of React onto the App Router and RSC. Their write-up highlights:
Why this matters for React on Rails teams. Mux is proof that a large, mature codebase can be migrated without a rewrite. React on Rails' multi-root model lines up especially well with their incremental approach — each stream_react_component call is a separate migration surface, so you don't have to flip the whole app at once. See Component Tree Restructuring Patterns and Data Fetching Migration for the patterns Mux describes.
Frigade ships an embedded onboarding/product-tour widget that runs inside other companies' apps, which makes client-bundle weight a first-class business constraint. After moving rendering to RSC they reported a 62% reduction in client-side bundle size.
Why this matters for React on Rails teams. If you ship a widget, checkout flow, or any component that has to load on top of another app's JavaScript budget, this is the result to benchmark against. The mechanism is the one described in Purpose and Benefits — Bundle Size Benefits: server-only dependencies never touch the client.
Sourcing note. The BlogHunch figures below come from a case study published by Entesta, the migration vendor who performed the work — not from a first-party BlogHunch engineering post. Weigh accordingly alongside the first-party case studies (Mux, Frigade).
BlogHunch's reported outcome is notable because it measures operational cost rather than just front-end performance:
Why this matters for React on Rails teams. Server-cost reductions come from doing less rendering work per request — static server components cache well, streaming lets the renderer release resources sooner, and offloading data fetching to the server removes redundant API round-trips. For how this maps to Pro's node renderer, see Node Renderer basics and Fragment Caching. For gradual rollout techniques, see Preparing Your App.
Nadia Makarevich's React Server Components performance post is the most useful read for anyone who wants a grounded, skeptical view:
Why this matters for React on Rails teams. Read this before you promise stakeholders DoorDash-scale numbers. If you adopt RSC without restructuring component trees, you'll leave most of the value on the table. The Migration Guide is structured specifically around the restructuring work Developerway calls out — 'use client' is a boundary marker, not a component annotation.
Across every case study above, the wins come from the same three mechanisms:
date-fns, marked, and ORM clients stay on the server. Bundles shrink; hydration gets cheaper.'use client' down to leaf interactions got much larger wins than teams that mechanically flipped file headers.React on Rails Pro gives you these three mechanisms via the node renderer, stream_react_component, and the RSC webpack loader. The engineering work is in the restructuring — the infrastructure is already there.