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 <russ...@russelldunphy.com> 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 <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.
-- 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.
