Skip to main content
Edit

RSC Migration Success Stories

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.

Reported Results at a Glance​

CompanyScopeHeadline ResultSource
DoorDashHomepage and store pages (Next.js SSR migration, pre–App Router)65% LCP improvement on homepage, 67% on store pagesImproving Web Page Performance with Next.js
Mux~50,000 lines migrated to the App Router / RSCSuspense-based streaming kept server code off the client bundle (no headline % published)What are React Server Components?
FrigadeEmbedded SaaS widget62% reduction in client-side bundle sizeBundle size reduction with RSC
BlogHunchFull marketing site + app30% server cost reduction, migration completed in ~1 monthBlogHunch migration case study (via Entesta, migration provider)
Developerway (research piece)Instrumented comparison of SSR, App Router, and Server Components-first appsN/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.

DoorDash — Core Web Vitals Transformation (SSR Baseline, pre-RSC)​

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:

  • +12% to +15% faster page load times on key pages
  • 65% LCP improvement on the homepage
  • 67% LCP improvement on store pages
  • 95% reduction in "Poor" LCP URLs (the >4s bucket that hurts search rankings)

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 — Migrating 50,000 Lines of React to RSC​

Mux published a detailed account of moving roughly 50,000 lines of React onto the App Router and RSC. Their write-up highlights:

  • Keeping server-only components and their dependencies out of the client bundle
  • Using Suspense to stream slow data fetches without blocking unrelated UI
  • Isolating CMS-driven features so a slow editorial call never stalls the rest of the page

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 — 62% Smaller Client Bundle​

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.

BlogHunch — 30% Lower Server Costs in One Month​

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:

  • Migration completed in approximately 1 month
  • 30% reduction in server costs
  • Reduced client-side JavaScript, improving initial loads
  • Gradual rollout using a feature-flag system

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.

Developerway — Honest Technical Analysis​

Nadia Makarevich's React Server Components performance post is the most useful read for anyone who wants a grounded, skeptical view:

  • RSC is not a free win — a lift-and-shift to the App Router without restructuring produces modest gains
  • Streaming + Suspense are where most of the real improvements come from
  • The biggest wins require a Server Components-first rewrite, not a mechanical migration
  • The post includes measured numbers from instrumented apps, not just marketing claims

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.

What These Stories Share​

Across every case study above, the wins come from the same three mechanisms:

  1. Server-only code stops shipping to the client. Libraries like date-fns, marked, and ORM clients stay on the server. Bundles shrink; hydration gets cheaper.
  2. Streaming decouples slow data from fast UI. Suspense boundaries around data-dependent regions let the shell render immediately while waterfalls resolve in parallel.
  3. Restructuring matters more than adoption. Teams that pushed '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.

Next Steps​

References​