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.
