Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Server Side Rendering Optimization

See original GitHub issue

Steps to reproduce

git clone https://github.com/shaundr/react_ssr
cd react_ssr && bundle && yarn && bundle exec rails s
open localhost:3000

Expected behavior

Timely server side rendering, perhaps parallelized?

Actual behavior

~140ms per HelloWorld example Screen Shot 2019-10-11 at 10 22 45 AM

System configuration

Sprockets or Webpacker version: 4.0.7 React-Rails version: 2.6.0 Rails version: 5.1.7 Ruby version: 2.6.1p33

I’ve been hoping to SSR some of an application, however it appears to be too slow. I’m sprinkling React into the views with the react_component helper, which can result in quite a few components mounting. It looks like React-Rails renders them serially via ExecJS. Has anyone looked in to batching or parallelization?

Issue Analytics

State:
Created 4 years ago
Comments:8 (7 by maintainers)

Top GitHub Comments

5reactions

BookOfGregcommented, Oct 11, 2019

Yep, in your project this is really slow!!! Definitely unacceptable!

It’s because you’re using ExecJS directly. So lets use NodeJS 😃

$ node -v
v10.16.2
$ EXECJS_RUNTIME='Node' rails s

Oh dear…

So lets use a JS engine that doesn’t suck.

Wait, you’re telling me there are JS engines better than NodeJS? Yes I am, it’s mini_racer and it’s ruby based!

Gemfile
gem 'mini_racer'

WOW so fast. Why isn’t this a project dependency? Well it’s because JRuby users can’t use mini_racer, they have to use the_ruby_rhino (I feel bad for them).

Yeah maybe we need to make this much more explicit in the README, PR welcome!!

4reactions

shaundrcommented, Oct 11, 2019

@BookOfGreg you are amazing, thank you.