I notice (subjectively) that Chrome is generally a *lot* faster when running JS heavy apps than Firefox or, please no - IE<11.
A few tips, I am sure you are already doing: - only render what is needed, don’t use ‘hidden’ as they are still in the DOM - copy the rendered HTML from page1 and page2 into static HTML files and then add an "<a href” to transition between them - that removes all JS and leaves you with the faster you are going to get - read and digest https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem <https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem> - identify the ‘real' performance bottlenecks; sure it may displease you, but will the users really care? What else could you be giving them if you didn’t have to work on this? This is a note to me more than you :). HTH and if you find any other tips then shout loudly! > On 3 Jul 2015, at 15:42, Russell Dunphy <[email protected]> wrote: > > Does anyone have any tips for performance tuning a reagent/re-frame > application they can share? We're running into very slow rendering > performance when changing pages on Firefox on Windows (ie sometimes several > seconds) which, though still noticeably laggy, don't seem to be anywhere near > as much of a problem in Chrome. > > Unfortunately I can't share the codebase, but here's what we've been trying > so far: > > Using React.addons.Perf to identify components that take more data than they > need as arguments - i.e their render function is called with changed data but > they don't end up generating different markup. This has helped us reduce > *re-render* performance, but doesn't help us much on initial page render, > where is where our performance problems mainly lie. > > Wrapping all our subscriptions using our own [custom register sub > function](https://gist.github.com/rsslldnphy/5c937167380dd3442076) to track > how many times each subscription is called, how long it takes etc, to reduce > duplicated work and highlight inefficiences. This has helped us a bit, but > slowness still remains. > > To give a slightly better UX when moving between pages, we first update the > app state with a key that causes a loading spinner to appear, then call > reagent/flush to make sure it's rendered, *then* update the app state again > to trigger the change to the new page. This still ends up being a bit jerky > however (the gif often freezes while the page is rendering, or itself takes a > while to appear) so any better suggestions would be very welcome. > > Thanks in advance for your suggestions. > > Russell > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
