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).
> 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%"?
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.
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.
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.
"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?
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.
31 comments
[ 3.2 ms ] story [ 72.7 ms ] thread2. Get a CDN for static assets
3. Use Webpack, again, for making development easier
Saved you a click.
Inventory:
And having a counter cache for the sum per product (e.g.: product.inventory_quantity).[1]: https://github.com/magnusvk/counter_culture
The primary metric is DOMContentLoaded, then the time to finish all requests.
If it took N seconds to show the page, it now takes N/5?
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%"?
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.
Just as you can improve a golf score, or a marathon pace, or your BMI.
Step 1: Have it be 5x slower than necessary
Step 2: Fix it
>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
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.
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.
A frontend app using create-react-app has everything to compose js files, load css and even manage sha1 suffixed asset file names.
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?
If you absolutely do need them, I would just separate them by routes.
This kind of article is just a click bait. No data to support his claim.