High-performance JavaScript: Why Everything You’ve Been Taught is Wrong by Joseph Smarr

Javascript and performance tuning seems to pack ‘em in theses days, so this talk was standing room only. It also had the highest percentage of Macs I’ve seen at OSCON — must have been refugees from RailsConf. This was a talk about lessons learned from developing Plaxo — a very Web 2.0 community site. This talk rocked — the presenter was energized, organized, and it contained all sorts of good nuggets. My experience with AJAX and Web 2.0 mirrored Plaxo’s, and I was happy to learn how to keep my user’s browser from locking up on all the nifty drag-and-drop pages. Some of the accepted Javascript wisdom hasn’t panned-out too well for me, either. Plaxo almost never shipped, and they had to work really hard to make it fast. What happened?

  • didn’t take performance seriously from day one
  • didn’t think browser limits were significant
  • didn’t use the app daily as they were developing it
  • didn’t push back on feature requests for performance
  • didn’t value perceived performance/responsiveness

They needed to unlearn a lot of standard assumptions.Why everything you’ve been taught (AJAX euphoria! Web browsers can do anything now!) is wrong: Browsers are pushed out of their comfort zone; Javascript is parsed and interpreted every time you load the page.

The Plaxo mantra: Be lazy, responsive, pragmatic, and vigilant.


  • Noting is faster than doing nothing
  • Write less code
    • Javascript is parsed every time it’s loaded, and Javascript is downloaded a lot, so keep it under 500K of code — this seems to be a standard best practice. Be careful of third-party libraries — they can add a lot of code.
  • Draw the UI as late as possible
    • Never pre-draw hidden UI elements
    • Cache HTML if appropriate
    • Don’t keep hidden UI up-to-date
    • Consider just redrawing everything versus carefully updating parts of the page

Responsive: When the user says, “jump,” you jump!

  • The initial page load is very important to user
    • CSS at top of page and Javascript at bottom. (News to me. Good idea.)
  • Draw placeholders right away
  • Yield early and often
    • use setTimeout(0) to yield
    • use a closure
    • use onmousedown() instead of onclick()
  • Cache backend responses
    • send all data requests through data manager code
    • use range caches and fill in missing pieces
    • balance local updates vs. re-fetching from APIs

At this point, it really struck me that that a lot of these points are basic UI practices from any UI toolkit like Swing, VB, etc. It’s not like caching and quickly responding to user requests with some UI feedback are revolutionary ideas. I’m all in favor of leaving out optimizations like caching until you really need them, but I’m, uh, surprised that this was such a surprise for our friends at Plaxo. Same goes for practices like eating your own dog food.

Pragmatic: Don’t make things even harder

  • Play to the browser’s strengths
    • avoid DOM, user innerHtml
    • avoid dynamic CSS-class definitions
    • avoid reflow when possible
    • avoid memory allocation like string splitting
    • do DOM manipulation off-DOM, then reinsert at the ends
  • Cheat when you can
    • Use global functions when reasonable (sacre bleu!)
    • Finding by CSS class is slow
    • Directly attach onclick, etc. handlers instead of using event listeners
  • If you have to do it every time, do it statically

Vigilant: Only you can prevent slow web apps

  • Profile
  • Use Firebug (I agree, it rocks!)
  • Measure with a consistent environment
    • browsers bog down over time, you need to restart them for accurate numbers.
  • Consider performance from day one
    • apps get slow when you make them do a lot of things
    • consider how much code is needed
    • make sure everyone remembers how important speed is

Summary: Make the browser happy. Web browsers are more like mobile phones, not a desktop. They are a flimsy, temperamental platform, but everyone’s got one, so it’s the best place to be. Don’t push the limits unless you have to.

Leave a Reply

You must be logged in to post a comment.