React Server Components: A Year in Production

When we decided to migrate our dashboard from a traditional React SPA to React Server Components, the promise was clear: smaller bundle sizes, better SEO, and streaming SSR. Twelve months later, we've shipped the migration to production serving 50K+ daily active users. Here's what actually happened.

The primary motivator wasn't性能 — it was architecture. Our client bundle had ballooned to 847KB gzipped. Third-party analytics, feature flag SDKs, and charting libraries were shipping to every user regardless of which page they visited. RSC let us move data-fetching and heavy computation to the server, dramatically reducing what ships to the browser.

After the migration, our client bundle dropped from 847KB to 312KB gzipped — a 63% reduction. The biggest wins came from moving recharts, date-fns, and our internal analytics SDK to server components. These libraries never needed to be in the client bundle.

The lesson: audit your imports. Every 'use client' boundary is a decision about what ships to the browser. Be intentional about it.

RSC caching is powerful but dangerous. We hit three major issues: stale data in production (cached responses served for hours), over-caching personalized content (user A saw user B's dashboard), and cache invalidation storms when deploying new versions.

Our fix: implement cache tags tied to user sessions, set aggressive TTLs for personalized data (30 seconds max), and use on-demand revalidation triggered by mutations. Cache aggressively, invalidate precisely.

Migrate incrementally, not all at once. We rewrote 40+ pages in a single sprint, which created merge conflicts and context-switching overhead. A page-by-page approach with feature flags would have been safer. Also, invest in observability early — we added Sentry and custom performance monitoring after the fact, which made debugging production issues harder than necessary.