benchmark

hey I wanted to communicate some of my findings before I get heavily involved
with ads again.

I built a component called 'boxlet' that resizes itself on click. You can build
the component yourself -its included with beast. Boxlet grows taller and
shorter when it is clicked, just link the ribbon ad. I replaced the ribbon ad
with boxlet and did some analysis -I activated profiling in firefox, expanded
then and minimized boxlet then stopped the profiler.

My machine: 2.3GHz, Core i7, 8GB DDR3

In both firefox and chrome there is great lag/choppiness. If we comment out
the body of ads.bindEvents (binding ads.ribbonResized to events), we can open
and shut boxlet with no lag or choppiness.

The profiler indicated that most of the activity comes from these:

main_sync/source/FSNavigation.js
main_async/source/app/views/viewSecondaryNav.js
main_sync/source/picturefill.js

I commented out window resize listeners in these scripts and the performance
issues went away completely. In this situation, Firefox's developer tools used
more resources than boxlet or ribbonResized. I included screenshots of the
profiling activity.

The current bottle necks could use standard improvements. throttled function
calls, memoized data. Additionally, we would likely benefit from centralization
of our window listeners. Its common to have one script add a listener and have
other scripts hook into that which is more performant but also makes debugging
easier as you can ignore all resize subscriber but one -or ignore one subscriber
and call the others.

I found many listeners on window resize with grep in foxsports-core-ui/src:

60 possible listeners functions are independently bound to window resize. Two
or three resize/scroll listeners would be more reasonable. Most of the current
listeners are unthrottled (resize will many times unnecessarily in short time).

These scripts seem to be the primary affectors of layout:

Other things I noticed...

ads.js

  $('.belowNav').bind('resize', Ads.ribbonResized);

What's interesting is that there is no 'resize' event published on
elements
. Binding to this 'event' is an unnecessary and expensive
abstraction from jquery. The 'ribbonResized' method constructs big jqeury
objects each time it is called.

I began this to find performance issues around layout. Modifying the layout
will not give us a great performance boost at this time but would still be
worth consideration as a future improvement. There is much additional
scripting and complexity around layout that could be removed, for example
this:

viewSecondaryNav

  $(window).on("resize", function() {
      showIn2N3Col();
  });

FSNavigation

  me.determineListItems();
  me.determineColumnView();

ads

  $sectionSidebarEl.css('margin-top', (newMargin < 70 ? '' : newMargin+ 'px'));