ReactJS - Mounted component rendering slow -?

Question

JavaScript

We encountered slow rendering of lists consisting of 200+ items in a ReactJS (15.1.0) + react-router + redux project.
For example, there is a list of users, which is a static "card", ie. a block with a photo, a couple of links and a little text. There are a lot of users, so when the component is mounted, the first 30 are displayed, and the remaining 30 are loaded from the api-server upon request (that is, by the "show more" button). Each such card is a static component whose shouldComponentUpdate() always returns false. The list component is subscribed to updates via connect() and renders cards only if new 30 are received. So far so good, and as data is loaded from the backend and cards are rendered, the rendering speed remains stable - judging by the Perf data, only new 30 instances of the card component are rendered with a common time about 80-90ms.
The problem appears when, after loading a relatively small list (already from 200-300 cards), the user follows the link in the card (the Link component from react-router), and then returns back using the browser button .
In this case, the list component is re-mountedand he has to redraw at once all those 200-300 cards that are in the redax state. At the same time, the rendering speed drops in proportion to the number of cards, i.e. almost 10 times, and if on the desktop it is tolerable, then for a mobile user, the page redraw time is 5+ seconds. And this is with a relatively small amount of data. In addition, the entire application (as does, for example, the redux dev tools at this point) "freezes" i.e. there is no way to somehow display, for example, a rendering progress indicator.
The question is - is this a normal render time for react under these conditions? If so, what could be the ways to solve the problem?
Is there any way to cache the rendering results of a previously mounted component? What are the options for solving the problem of long lists if the size of the element is not known in advance?
Thank you!

Answer 1

if in the end nothing helps, you can try a virtual list or something similar developerdizzle.github.io/react-virtual-list

Answer 2

* block with photo * - this is most likely the problem with the brakes. If so, then you can think in the direction of inlining these pictures, for example.
Well, the most common way is to use UI design to limit the visible area and display only those entries that are directly visible on the screen. In your example, on the "back" button, you again need to reset the state of the component so that it displays 30 records.
a response of 5 seconds is not normal, regardless of whether you have react or something else. A response of up to 1s is considered acceptable.

Answer 3

>Is this a normal render time for react under these conditions?
Yes. https://localvoid.github.io/uibench/
>If so, what could be the ways to solve the problem?
Rendering without react, especially if everything is static, will not be so difficult. The main thing is to decide which engines to optimize for, because with different engines you need to work differently with the house to get the most productive result.
And in the future, incremental rendering may be possible: https://www.facebook.com/notes/andy-street/react-n...

Answer 4

Well, it seems like a banal problem that occurs in many places and is not solved.
Caching is not an option in my opinion. The RAM will be clogged and the brakes on the mobile phone will begin.
I have VK, when you scroll through the wall for several hundred posts, it slows down very fiercely, even when you go to other pages - apparently it caches the data and only reboot saves

Answer 5

You have many pictures. And all these hundreds of pictures are being reloaded. Here are a couple of options:
1. cache images.
2. display content, and then load the required images, as needed.
3. download thumbnails for mobile phones and cache them
4. any other way to reduce the number of downloads of images.

Answer 6

My experience in front-end development is only a month, so maybe I'll catch some stupidity.
I would venture to suggest that it is not rendering as such that slows down, but the calculation of changes between VirtualDOM and DOM to make changes.
It seems to me that you can play around with the key parameter of the card components, so that in one case it is constant between renderings, and in the second case it is unique, so that it considers that everything has changed and simply throws out the whole tree and adds a new one and compares the results.

Answer 7

judging by the Perf data, only 30 new instances of the card component are rendered with a total time of about 80-90ms

This is not a normal time to render a batch, most likely you have blocking requests in the render thread (for example, synchronous drawing of a picture) or heavy calculations.
You can look at the timeline of this process and figure out what could be the reason.