Gumroad RSC experiment: benchmark findings and positioning

[justin808]

Context

This is the benchmark-discipline and positioning thread for the Gumroad-style React on Rails Pro + RSC experiment.

Canonical public repo:

• https://github.com/shakacode/react-on-rails-demo-gumroad-rsc

Related hub issue:

• Gumroad public comparison repo: React 19 + Rspack + React on Rails Pro RSC findings #3128

Active public PRs:

• Consolidated parent demo PR: Add Gumroad RSC comparison demo react-on-rails-demo-gumroad-rsc#11
• Current child follow-up for dev-server overrides and clean-port benchmark docs: Honor Shakapacker dev server overrides react-on-rails-demo-gumroad-rsc#10

Scope discipline:

• this is not a Gumroad migration pitch
• this is a measured comparison on one reduced dashboard surface
• Rspack is a build/dev-loop story, not a page-runtime story by itself
• RSC is the runtime experiment

Matched routes

• Inertia control: /dashboard/inertia_demo
• React on Rails Pro + RSC: /dashboard/rsc_demo

Both routes use the same reduced creator-home presenter surface and the same outer layout.

Current headline benchmark

The current headline benchmark is the corrected clean-port alternating result from PR #10.

Why this replaced the earlier grouped or mixed-port numbers:

• route order affects cache state, so the alternating runner rotates order by cycle
• an earlier run had a local asset-proxy mismatch because another repo had reclaimed port 3035
• the follow-up run restarted both Rails and the Shakapacker dev server with SHAKAPACKER_DEV_SERVER_PORT=3036
• Chrome and ChromeDriver matched during this pass

Latest reduced-dashboard result:

Metric	Inertia demo	RSC demo	Delta
Navigation duration	457.16ms	402.29ms	-12.0%
LCP	501.00ms	421.00ms	-16.0%
Response end	320.70ms	335.96ms	+4.8%
Controller action_total	163.10ms	169.74ms	+4.1%
Presenter compare_props	144.80ms	145.49ms	+0.5%
Page-specific JS requests	6	1	-83.3%

What this means

Positive signal:

• the bounded RSC route wins on total navigation duration
• the bounded RSC route wins on LCP
• the bounded RSC route materially reduces page-specific JavaScript requests
• the latest server-side penalty is smaller than the earlier mixed-port runs suggested

Remaining caveat:

• Inertia is still ahead on responseEnd and route-level server timing
• the benchmark is still local-development, not production-like
• renderer-internal profiling is still needed before making a stronger production-performance claim

Product and positioning implications

• Use Rspack to talk about build speed and developer loop improvements.
• Use RSC to talk about route-level runtime tradeoffs and client-JS reduction.
• Do not blur those two claims; it weakens both.
• The strongest near-term message is not “replace Inertia.”
• The stronger message is: some product surfaces cross the line into full React application territory, and that is where React on Rails Pro can justify itself.

Adjacent product idea worth discussing

A friendlier bridge for existing Inertia Rails apps may be viable:

• keep inertia_rails in place
• offer SSR and React 19 support first
• wrap the Node renderer, boot/fallback behavior, CSP, and observability cleanly
• only explore deeper RSC-style integration if the protocol fit stays honest
• keep the implementation clean-room if any public Inertia adapter is derived from ideas in React on Rails Pro

Current validation status as of April 30, 2026 UTC

• PR Support both functions and react components for the API #11: draft, clean, CI Gate green, Demo Validation green, Claude review green, CodeRabbit skipped because the PR is draft, Cursor Bugbot neutral.
• PR Support generator to build a template wepack setup #10: draft, clean, approved, CI Gate green, Demo Validation green, Claude review green, CodeRabbit green, Cursor Bugbot green.

Latest local validation rerun:

• Parent branch: npm run setup
• Parent branch: RAILS_ENV=development NODE_ENV=development bin/shakapacker --mode development
• Parent branch: RAILS_ENV=test npm run build:rsc-demo
• Child branch: npm run setup
• Child branch: RAILS_ENV=development NODE_ENV=development bin/shakapacker --mode development
• Child branch: RAILS_ENV=test npm run build:rsc-demo

Docs/catalog status:

• React on Rails docs/catalog PR merged: Document examples catalog and naming plan #3191
• ReactOnRails.com examples catalog PR is open, clean, approved, and green: Curate the examples catalog around maintained demos reactonrails.com#102

Useful docs

• Current status: https://github.com/shakacode/react-on-rails-demo-gumroad-rsc/blob/jg-codex/benchmark-headline-metrics/docs/current-status.md
• Performance findings: https://github.com/shakacode/react-on-rails-demo-gumroad-rsc/blob/jg-codex/benchmark-headline-metrics/docs/performance-findings.md
• Performance team handoff: https://github.com/shakacode/react-on-rails-demo-gumroad-rsc/blob/jg-codex/benchmark-headline-metrics/docs/performance-team-handoff.md
• Positioning notes: https://github.com/shakacode/react-on-rails-demo-gumroad-rsc/blob/jg-codex/benchmark-headline-metrics/docs/positioning-notes.md
• Gumroad upstream issue draft: https://github.com/shakacode/react-on-rails-demo-gumroad-rsc/blob/jg-codex/benchmark-headline-metrics/docs/gumroad-upstream-issue-draft.md

Next work

• publish the ReactOnRails.com examples catalog when the site PR is merged
• capture production-like renderer profiling
• rerun the benchmark against production-like assets/rendering
• see whether the LCP/navigation win holds while narrowing the server-side penalty
• decide whether to keep the demo PRs as draft case-study branches or make the consolidated parent PR ready for review

[justin808]

2026-04-23 update:

• canonical repo name is now shakacode/react-on-rails-demo-gumroad-rsc
• the React on Rails docs/catalog stack is green and points to the canonical repo slugs
• the current shareable hub issue for the public repo + positioning summary is #3128

I am keeping this issue as the benchmark-discipline / positioning-details thread, but the repo rename and share links above are the current canonical references.

[justin808]

Production-like Gumroad RSC benchmark update from April 30, 2026 UTC:

• Demo PR: Capture production-like RSC benchmark timing react-on-rails-demo-gumroad-rsc#12
• Branch: jg-codex/production-like-rsc-profiling
• Compared routes: /dashboard/inertia_demo vs /dashboard/rsc_demo
• Method: 8 alternating cycles, one warmup request per measured run, matching Chrome 147 and ChromeDriver 147
• Runtime setup: compiled Shakapacker/Rspack assets, compiled RSC demo bundles, Rails without the Shakapacker dev server, dedicated React on Rails Pro Node renderer on RENDERER_PORT=3800

Headline deltas from production-like-alternating-8-reindexed:

Metric	Inertia	RSC	Delta
Median navigation	775.40ms	607.15ms	-21.7%
Median LCP	794.00ms	634.00ms	-20.2%
Median responseEnd	644.80ms	588.80ms	-8.7%
Median action_total	346.87ms	339.20ms	-2.2%
JS request count	6	1	-83.3%
p95 responseEnd	730.62ms	768.25ms	+5.2%

Interpretation: this is the strongest local evidence so far. The RSC route keeps a user-visible win after removing the dev server from the measurement path. The remaining caution is tail response timing, especially p95 responseEnd, so the next proof step should be a stable deployed repeat plus renderer-internal timing.

Instrumentation note: PR #12 adds /rsc_payload/ resource timing capture to the benchmark harness, but this implementation streams the RSC payload inline on initial load. That means those browser resource fields are empty until we expose a separate payload resource or add renderer-side Server-Timing.