Porting Flickr to YUI3

Editor's Notes

• #3: I'm Ross, a frontend engineer at Flickr.
• #4: This is a story about problems we found after the launch of that photo page, and a few of the unanticipated consequences of building a page from scratch using YUI3 and the Y! Performance Guidelines The primary goal of the project, from the engineering side, was to improve performance: The old page took 4-6 seconds to load The frontend code was 5 years old To put some perspective on it, the JS contained hand-coded special cases for Opera 7 There were tons of global variables, and a dependency tree that was so complicated that we were terrified to pull out pieces of JS It was ready to be put to rest.
• #5: We investigated doing a retrofit with YUI3 We determined that it would take longer to do that than it would to throw everything out and start from scratch We also determined that retrofitting wouldn't really improve performance: The only way we could meet our goal was to throw everything away We started from scratch using YUI3 and the Y! Performance Guidelines And I mean, really started from scratch. We used empty CSS and JS files and built the page again
• #6: Page load times are down significantly (900ms for Safari, 1.5 for Chrome) We essentially cut the load time in half for the worst case (IE), and reduced it by 80% for the best case (Safari) Code is modular and maintainable The architecture will last us for the next 5 years, even if the individual modules that make it up don't Modules and dependencies mean that 5 engineers can work on the page at the same time Development time was extremely fast Existing gallery modules mean you don’t have to reinvent the wheel Convenience methods mean you can do extremely complex things with very little code (more on this later) Good documentation means that even though we weren't initially familiar with YUI3's syntax, we soon picked it up Porting code from YUI2 to 3 is an easy process – analogous functions exist, and it's a simple matter of changing the syntax
• #7: 99% of the things we used YUI3 for went off without a hitch But there were a few things that caught us by surprise Some where caused by using YUI3, and some were caused by implementing the Performance Guidelines The guidelines are taken as gospel at this point; everyone know them and tried to implement them We found that, at the edges of normal use, some of the guidelines start to break down I'm going to spend the rest of this talk going over the 4 problems that we found, and how we fixed each one. These all happened after launch, and most of them were reported by users
• #9: Most users were having a great experience… but a vocal minority of users were having huge problems, especially on IE These users were persistent in telling us that the page was significantly slower for them now; we have pages and pages of forum posts outlining problems.
• #10: This makes sense in most cases, since script tags block and slow down the page from being rendered. But if your page depends heavily on JS, it can actually increase perceived loading time
• #11: It means that the bulk of your JS won't be downloaded and executed until a second or two after the rest of the UI Having no-JS fallbacks also makes it worse Instead of a button that does nothing for a short time, it actually takes you off the page The problem is exasperated by using YUI3's deferred module loading
• #12: Include a small amount of JS in the head, enough to attach click events and to show a busy indicator Queue up clicks When a module registers itself, have it check the queue and perform the necessary actions The action queue code handles cleanup of the busy indicators
• #13: It tricks people into thinking the UI is responsive Action queueing doesn't actually solve the problem, it just improves the perceived load time
• #14: Page load times are down significantly (900ms for Safari, 1.5 for Chrome) Code is modular and maintainable The architecture will last us for the next 5 years, even if the individual modules that make it up don't
• #17: These users get pages that sort of work, but don't have all the JS modules It's their problem to fix, but most can't do anything about it We had to fix it on our end
• #18: We replaced the names of modules with single or double character strings. This algorithm wasn't reversible, but it was easy to implement and doesn't require a database to store shortened names. We have to run the script that builds the substitution dictionary every once in a while, but that's easy
• #19: They are a small minority at the moment, but eventually we'll have to deal with this problem. 1600 characters or lower is the limit we found covers pretty much everyone.
• #20: It seems that some corporate firewall refuse to load any URL that has the string 'xxx' in it. We had to implement a check that would use the longer version of the string if xxx was detected
• #22: Not just scrolling, but almost all UI interactions requiring a click or a drag
• #23: Both of these need to poll, with setInterval() in case the elements don't exist yet. We found that we were able to create our own delegate method, using Y.on and Y.Node.test that was twice as fast, when run through a massive selenium test. This isn't to say that ours is better (it isn't), but that Y.delegate() has to handle a lot of cases, and has baggage for most uses cases.
• #24: This probably goes without saying, but customizing the solutions for each situation is obviously going to be faster. What was surprising to me was just how slow delegate and on were before we customized them.
• #25: Don't assume that, just because you're using an established library, you don't need to know what's going on under the hood. We removed all instances of Y.delegate and Y.on, and massively improved the click performance of IE. YMMV.
• #27: DOMReady and window.load are meaningless The important moments for us are: When the photo is visible, and When the JS is done loading and the UI is fully functional
• #28: This gives us enough data to create smooth graphs, without burdening too many page loads with the extra code needed to gather and report the timings.
• #29: RRD tool is a round robin database that stores data at decreasing granularity as time goes on: http://www.mrtg.org/rrdtool/ Track everything, but only actively monitor a few important metrics Also serves as quality assurance, it lets us know when site performance is down
• #30: Performance is excellent for Safari, Chrome and Firefox. IE8 is mediocre and IE7 is terrible. If we were to average all of these numbers together, it would mask the 900ms page load times we're getting with Safari. Lumping them in together also hides browser-specific problems. After a recent deploy, we noticed that the IE8 load times were slightly higher than normal; having separate graphs allowed us to find and fix the problem. The real solution is to have reference systems: a fixed computer, OS, connection, and browser configuration, that we can use to compare the performance of the page over time.
• #31: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL
• #32: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL
• #33: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL
• #34: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL
• #35: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL
• #36: YUI3 is amazing If you can't have real performance, fake it Dig deeply into the JS library you use Measure the moments important to you NEVER include XXX in a URL