Thanks Colin! The only one I'm not sure I follow is to "copy the rendered HTML from page1 and page2 into static HTML files". Is this for the special case where you don't have any dynamic content on the page? Or are you talking about rendering the generic structure of the page first, then loading in actual data?
On Friday, July 3, 2015 at 4:13:36 PM UTC+1, Colin Yates wrote: > 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 > - 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 <rus...@russelldunphy.com> 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 clojurescrip...@googlegroups.com. > To post to this group, send email to clojur...@googlegroups.com. > 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
