To prepare the production database and launch the server, run these two command lines:
RAILS_ENV=production rake db:drop db:create db:migrate db:seed assets:precompile
RAILS_ENV=production RAILS_SERVE_STATIC_ASSETS=true rails server
Now, load each URL and see what Rack and Chrome Devtools show for response time.
Fair warning: this is running on a Macbook Air with 20% battery... kinda flimsy.
I'm only including the client scripting result here. Chrome's other numbers are pretty noisy or too small to consider.
| Client | Server | |
|---|---|---|
| no args | ~118ms | 4ms |
| ?noprerender=1 | ~118ms | 2ms |
| ?nojs=1 | ~87ms | 4ms |
| ?nojs=1&noprerender=1 | ~73ms | 2ms |
It's a micro benchmark. These numbers can suggest a relative trend but, without running a proper load test, they won't contain much data.
Also, this page is too simple. Client-side, the tiny rendering time is swamped by JS parsing and page load. It's more apparent server-side, but that's just because the server isn't doing anything else.
I don't see a clear signal. Chrome is showing large variability from run to run. If anything, pre-rendering might slow down page load slightly.
The takeaway: simple client-side rendering hardly affects page load times.
Server-side rendering does add noticeably to the server's response time. Predictably, each server won't be able to handle as many simultaneous clients. Is it worth it? Almost certainly! Besides, if you have heavy traffic, you can compensate with caching.
(It would be neat to see if someone could integrate russian-doll caching with server-rendered React. It doesn't seem like it would be too hard.
