We've had good success with the "queued rendering with interrupts" strategy as well. The 5.9s to 960ms drop is _slightly_ misleading, since a lot of the renderi

We've had good success with the "queued rendering with interrupts" strategy as well. The 5.9s to 960ms drop is _slightly_ misleading, since a lot of the rendering has yet to be done, but as long as one remembers they're measuring "perceived" rendering time I'm in full agreement. Other than allowing the browser to paint in the middle, I'd say it's equally (if not more) important that the _.defer calls allow user events to interleave rendering, so you get a bit of scrolling, clicking, hovering, etc. Not doing so is akin to running an intensive operation in the UI thread (for those coming from Swing or Android), and you get a frozen browser page instead. The one caveat we've seen, though, is your code gets more complicated due to the async rendering. For us the async render was just a subcall in a larger render method, and some later calls relied on the async rendering being complete for some measurement purposes. We had to move those calls to a callback after the queued rendering was done, but ideally only wanted SOME of it to be deferred (some click handlers, etc, we wanted set up earlier so the user could interact with the page), but in a larger codebase you get into a refactoring nightmare, etc etc. All being said, though, it was probably worth it. :)