Use pre-compiled assets if available

[mchristen]

I've been trying to track down the cause of some request latency that happens on the first request after a fresh boot.

I determined that with the recent refactor of the server rendering code simply deferred the slowness to the first request instead of happening on bootup.

The issue is that by calling

::Rails.application.assets[filename].to_s

you are essentially calling find_asset on the Sprockets::Environment object. This causes the first lookup of the asset file to trigger a compilation to load the file into Sprockets cache objects.

In some production environments all assets are precompiled and config.assets.compile is set to false. I have a patch here that reads the file from disk if asset compilation is turned off in Rails. I'm sure there is a better way, and perhaps this should be a different kind of ServerRenderer altogether.

Using this patch I was able to get my first request latency down from 45s to around 4s, subsequent requests are much faster, what I would expect from a production system.

[rmosolgo]

Wow, nice find! I've noticed that same latency after deploy, but I didn't dig in. I wondered if it was JS instances starting or something. Looks like not!

I like your approach! Does it require you to compile each of filenames? IE compile react.js and components.js separately?

I guess you could just handle that in by passing filenames: ["components.js"] then //= require react in components js.

[mchristen]

Correct, all files configured for react.server_rendering need to be precompiled. I tried including react.js in the assets.precompile list, but I couldn't seem to get it to ever compile. I ended up going with your solution, where my components.js files //=require all the necessary pieces, including react.js.

So as long as all your component files are listed in assets.precompile and each component file //= requires all necessary per-requisites it should work just fine.

[rmosolgo]

Here's another try at this: #430

[rmosolgo]

Addressed by #430