How we made our React-Rails app 5x faster | Hacker News Reader

How we made our React-Rails app 5x faster

blog.progressly.com

66 pointsamk_31 comments

"Using the Webpack-Rails gem allowed us to finally compile frontend assets when deployed instead of checking the minified files into source control for Heroku deployments."

Huge red flag for a project. Checking in minified files at any point of app development is a nightmare for developers. The fact that they were doing this at all is no good. And if you're reading this and your team is doing it, that's no good either!

The #1 thing you can do to speed up a SPA is server side rendering, which it doesn't look like this company is doing https://progressly.com/engineering#/engineering. The entire page is blank for almost a second on each load. Was it 5s before? I sure hope not! But the tactics mentioned in this article are insignificant to actual server rendering.

Why would you couple Rails + React in the first place?

We have a similar project and decided to just put everything React-related into "client" directory in Rails, then, once webpack builds production-ready files, it puts them into public/assets (during container build time). And that's it, I can run React without Rails, vice versa, test them independently,... etc.

Agree with this. While you may feel like you're losing something big by not using the asset pipeline, tools for managing assets in js are now totally awesome.

A frontend app using create-react-app has everything to compose js files, load css and even manage sha1 suffixed asset file names.

Yes, I would create two different projects, one Ruby only and one JavaScript only.

I wonder if there is a well established pattern for server side rendering of some pages in this kind of applications. Obviously one can use Rails views for some important pages but how not to duplicate HTML in Rails and React?

Hm, why would you need to render some pages in Rails? Why not just go React all the way and use Rails for API only.

If you absolutely do need them, I would just separate them by routes.

If the SPA is large, server side rendering is faster. Users get the first page in milliseconds, whatever page it is, then the SPA loads and takes over. I would do that for a few entry points to the site, for example the ones that get into the sitemap in the Google results page.

How much of the 5x was from proper CDN usage? Given that we can all expect a CDN to dramatically benefit delivery time, I would be interested in seeing these kinds of posts with obvious wisdom omitted.

How do they define 5x faster? http request to browser renders the page usable?

I wrote the thing, but have noprocrast on that account...

The primary metric is DOMContentLoaded, then the time to finish all requests.

>How do they define 5x faster?

If it took N seconds to show the page, it now takes N/5?

> Last week we deployed an update to our React-Rails app that improved load time by 500%

By "improve" they surely mean reduce. How can a measurement be reduced by 500%? If load time has decreased to one fifth, it would have been clearer to write "load time was reduced by 80%"?

Maybe it takes 1s to load, but now happens 4s before you even think of opening the page?

Technically, we can say they increased load speed by 400%. But it would still sound very awkward.

I guess the velocity measurement "amount of functionality loaded per second" did improve by 500%, a bit contrived though.

"500%" is equivalent to "5x"

So "improved by 500%" means "improved by a factor of 5".

In the case of time, improving means reducing.

So time got reduced by a factor of 5.

Which is also wrong. "Improving speed by 100%" means being twice as fast. 100% + 500% = 600%. Better avoid it even if it sounds sooo much more than "double" or "five times".

Improve by itself doesn't imply a direction. It has to be inferred via context. Improving page load time by 500% is perfectly reasonable to say, the reader infers that improve means decrease in this case.

Just as you can improve a golf score, or a marathon pace, or your BMI.

They were checking in the minified files into git? Really?

FTFY: How we made our React-Rails app COMPILE 5x faster

This kind of article is just a click bait. No data to support his claim.

This snippet from the gist provided in the article says it all about any "optimizations" they might have done:

  path: production 
            ? path.resolve(appRoot, 'public', 'webpack') 
            : path.resolve(appRoot, 'public', 'webpack')

No mention of E-Tags.

1. Make sure you're using the latest stable version of React core

2. Get a CDN for static assets

3. Use Webpack, again, for making development easier

Saved you a click.

Now I have to find out what to do with my extra click, thank you real much!

Upvote the comment ;)

Pretty much! Caching makes a big difference, especially for first-time visitors. For logged-in users, one particular big gain was getting rid of a join from users to events to show the notifications count, and replacing that with a counter cache (denormalization).

By the way there is counter_culture[1] which is great for more complex counter caches:

Inventory:

    product quantity
    1       2
    1       5
    2       -1
    2       3
    2       10

And having a counter cache for the sum per product (e.g.: product.inventory_quantity).

[1]: https://github.com/magnusvk/counter_culture

That looks useful, thanks

Is it just me or is every story titled "10 tips on making X faster" or "how we migrated from X to Y and reduced number of servers from 10k to just 2" or "how we speed up Z by 400000%" is really just a story of "how we made our project better by stopping, checking what we really need to do, researching how to do it and then investing time to actually do it right"? There is hardly ever any new ground breaking wisdom, new revolutionary algorithm or amazing new tool, it's all about knowing what you're doing, which usually takes a few tries.

How to make your software 5x faster

Step 1: Have it be 5x slower than necessary

Step 2: Fix it

>How to make your software 5x faster

>Step 1: Have it be 5x slower than necessary

>Step 2: Fix it

Corollary:

Step3: Pat yourself on the back

Step4: Show everyone how clever you are

Yes, this is what it boils down to. However, without these posts people would keep developing more and more overhead, mot taking a step back and questioning oneself wether the current state of the project can be improved. Especially when you work at a startup, it is sometimes hard to find the time and reasoning to take a step back and analyze the project from a distance. Trust me, these tips are useful to get the optimizing ball rolling.

Reply on news.ycombinator.com