Are you using Re-com as well? That relies heavily on Flexbox which is only just starting to be optimised in Firefox. I think Firefox 38 from memory was where it started to get better performance, although still not as fast as Chrome. The other tip is to look at the rendering timeline and see which parts of code/browser events are taking the most time. I'm most familiar with Chrome's one, but I assume that Firefox has a similar one.
On Sat, Jul 4, 2015 at 4:26 AM Russell Dunphy <[email protected]> wrote: > Ah, got you! That's a good idea, will give it a go, thanks. > > On Friday, July 3, 2015 at 5:12:45 PM UTC+1, Colin Yates wrote: > > Hi Russel, I often find my intuition as to where the problem is when it > comes to performance is about as bad as my estimates (i.e. terrible) so I > ruthlessly reduce the problem. In this case, is the performance problem in > JS or simple rendering the DOM. One way to do that is use your app to > render page 1 and inspect the HTML. Copy that HTML into a file called > ‘page1.htm. Now use your app to transition to another page which is > considered ‘slow’ and inspect the HTML. Copy that to a file called > page2.htm. Now edit page1.htm and add a link to page2.htm. You now have a > reduced problem set where there is absolutely no JS and is pure rendering. > > > > Now, load page1.htm in the browser - how quick was that? Now click the > transition button and wait for it to be rendered - how quick was that? It > is sometimes surprising how long this takes, even without the overhead of > JavaScript. At least now I am guided to whether the slog is in rendering > the DOM (in which case chunking the DOM updates is one answer) or somewhere > else. > > > > That’s all I meant. > > > > > On 3 Jul 2015, at 17:06, Russell Dunphy <[email protected]> > wrote: > > > > > > 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 <[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. > > -- > 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. > -- -- Daniel -- 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.
