ReactJS — slow rendering of the mounted component?

We're experiencing slow rendering of lists consisting of 200+ items in the project on ReactJS (15.1.0) + react-router + redux.

For example, there is a list of users, which is a static "card", i.e. a block with a photo, a couple of links and small text. Users a lot, so when mounting the component displays the top 30 and the rest at 30 c loaded api-servers on demand (i.e. by clicking "show more"). Each card is a static component shouldComponentUpdate() which always returns false. The list component is subscribed to updates via the connect() and renders the card only if you obtained a new 30. So far so good and as you download data from the backend and rendering card rendering speed remains stable, according to Perf rendering only the new 30 instances of the card with a total time of about 80-90ms.

The problem comes when after downloading the relatively small list (from 200-300 cards), the user clicks a link on the (Link component of react-router) and then back button of browser.

In this case the list component is re-mounted and he has to redraw once all those 200-300 cards, located in the state redaxe. The rendering speed decreases proportionally count cards, i.e. almost 10 times, and if it's tolerable on the desktop, the mobile user, the redraw time is 5+ seconds. And this despite the relatively small quantity of data. In addition, the entire application (as, for example, redux dev tools at this point) "freezes", i.e. there is no opportunity to display, for example, the progress of the rendering.

The question is - is that a normal render time to react under such circumstances? If Yes, then what are the workarounds?
Is it possible in any way to cache the results of rendering a previously mounted component? What are the solutions to the problem of long lists, if element size is unknown beforehand?

Thank you!
July 8th 19 at 15:31
7 answers
July 8th 19 at 15:33
if nothing helps you can try virtual-sheet or something similar

100K finally elements with no brakes
Thanks, but all decisions of this kind will not fit - not known the height of the units, because there can be different amount of text and different height of the photo. Additionally, the list is built in a masonry layout, which further complicates the task of calculating the height of the placeholders. - reb commented on July 8th 19 at 15:36
hmm, I think nothing ignore solutions "of this kind", especially when loading in infinite scroll
here there are interesting elements of different heights, and even staggered
the latest example 99.999.999 !!! elements (the first two miss - there's just uploading at the end)
rest just on your topic...

and the code would be laid out on fidle what you see, and the matter would be quickly gone, suddenly you have the thread where the comma in the wrong place (well, at so - for example) - lauretta commented on July 8th 19 at 15:39
Thank you and see you again. Test code - the rendering Speed decreases proportionally to the complexity of the layout, in addition, the Timeline figures several times more than the console.time(). In pure js rendering in ~5 times faster. But, apparently, this is how the react... - reb commented on July 8th 19 at 15:42
while the current numbers... if anyone is interested not looking into the console ))

for timeline and console time converges
React.render is performed, for example 530ms
after that recalculate style 45ms
and after that Layout 202ms
total 777ms

202ms - this is render by the browser the 1000 elements, each of which is 10 simple DIVS, Spanov etc
total 10K nod
ie won't do it... right?

well, then I will come back to its proposal to use a virtual list
ie will a couple of elements * 10нод = XX nod almost instantly

when should increase calculation time, BUT
but the list also will not render the whole
the SAME sample of these SEVERAL list items - lauretta commented on July 8th 19 at 15:45
although in the example, node 10K is not, and writes the timeline - Nodes That Need Layout 19005 - lauretta commented on July 8th 19 at 15:48
Ah, well, type the text inside the DIVS are text nodes ))
and Yes 11K DIVS(spanou) - lauretta commented on July 8th 19 at 15:51
as an option without using third-party "virtual lists"
draw the first 10 +- (or 30 whatever you have)
and timed out with the minimum of delay to draw EVERYTHING (ie. the first 30 is not updated REAKTOR, and will stay untouched)

for example
render React.render 75ms, Layout 8ms - lauretta commented on July 8th 19 at 15:54
and as a Supplement... but don't know how or anyone else wants will draw it
suddenly though sympathetic help )) well, at least stacko ms would...

from the docks at reacto

Use the production build
If you're benchmarking or seeing performance problems in your apps React, make sure you're testing with the minified production build. The development build includes extra warnings that are helpful when building your apps, but it is slower due to the extra bookkeeping it does. - lauretta commented on July 8th 19 at 15:57
did so, Dan agrees with me )) - lauretta commented on July 8th 19 at 16:00
how's it going?
how dare question? - lauretta commented on July 8th 19 at 16:03
Yes, thank you, reactor create a container and get it ref, and the contents filled through unstable_renderSubtreeIntoContainer() + fill the container orangereya components in pure javascript. - reb commented on July 8th 19 at 16:06
July 8th 19 at 15:35
*block with photo* is most likely a problem of brakes. If so, then you can think of to insanity these pictures, for example.

Well, the most common method - through the UI to limit the viewable area and display only those records which are directly visible on the screen. In your example the "back" button again to reset the state of a component so that it displays 30 records.

response 5 seconds is not normal regardless of whether you react or something else. Is considered an acceptable response to 1C.
It is not in the photo because without them, the same situation. To reset the list back button is possible, but it's just one of those crutches, which do not like infinite lists.
The thing is that in vanilla js the list is drawn much faster, as it should, so the question arose, why does it react so long, despite the fact that there is no comparing the virtual with the real DOM in this case is not necessary. - reb commented on July 8th 19 at 15:38
By the way, now I remember that I have similar behavior too was once on the back button but not always but only occasionally retarding. This is of course speculation, but maybe the issue in react-router? And just render 200 components without back brakes? - lauretta commented on July 8th 19 at 15:41
Yes, just render too slow. Ie, if you simply mount a component with several hundred items (in total a couple thousand gcd). And the more you have, the more slow. That, in principle, normal and understandable, but it is not clear why it all starts on a relatively small lists. - reb commented on July 8th 19 at 15:44
And under different browsers watching? The same brakes? - lauretta commented on July 8th 19 at 15:47
About the same everywhere, chrome is a bit slower. In the comments above there is an example jsfiddle. - lauretta commented on July 8th 19 at 15:50
July 8th 19 at 15:37
>is that a normal render time to react under such circumstances?


>If Yes, then what are the workarounds?

Render without react, especially if everything is static, it will be not so difficult. The main thing to decide under which engines to optimize, maybe with different engines need different ways to work with the house to obtain the most productive result.

And in the future could have the possibility of incremental rendering:
July 8th 19 at 15:39
Yes, well, kind of banal problem that a lot where found and not solved.
Caching, I think, not an option. Clogged RAM and will start the brakes on cellphones.
I have the VC, when malistaire wall for a few hundred posts, very fiercely slow, even when switching to other page - apparently it caches the data and does.
July 8th 19 at 15:41
You have a lot of pictures. And all these hundreds of images, re-loaded. Here are a couple of options:
1. to cache images.
2. to display the content, and then load the required images, as necessary.
3. shipping miniatures for gamers and cache them
4. any other way to reduce the number of zagruzok pictures.
It is not in the picture until the layout with pictures is not even reached - it's all on the test options are simply several of the DOM node on the card. - reb commented on July 8th 19 at 15:44
July 8th 19 at 15:43
My experience in the development fronend just a month, so perhaps the breccia stupidity.
I would venture to suggest that it did not render as such, and the calculation of the changes between VirtualDOM and DOM to make changes.
I think you can play with the parameter key from components of the cards so in one case he was a regular between the renderings, and in the second case is unique, so he believed that everything changed and just threw all the wood and added a new and compare results.
July 8th 19 at 15:45
according to Perf rendering only the new 30 instances of the card with a total time of about 80-90ms

This is not a normal time for rendering packs, chances are you have in the flow of the render-blocking presence requests (e.g. simultaneous receipt of caridi) or heavy calculations.
You can look at the timeline of this process and to understand what could be the reason.

Find more questions by tags JavaScriptReact