Ember is fast. Ember Core is working hard to make Ember even faster. So why does your app drag?
In this talk, we will use the source of real, shipped Ember apps (and of Ember itself) to diagnose, understand, and improve slow interactions. The Chrome developer tools will help us understand slow code paths and identify opportunities for improvement. Along the way, we will learn how parts of Ember work at the macro and micro level and learn how the framework helps us manage performance challenges in a browser environment.
At EmberConf, I spoke on web application performance and Ember.js. The message of this talk is that application performance is bigger than Ember performance. As authors of many of the more ambitious single-page web applications out there, we need to understand the tools and techniques used in analyzing and bettering the a user’s experience.
The slides above are accompanied by two live-coding sessions:
- Debugging a janky animation, part #1 and part #2
- Conserving property change notifications, part #1 and part #2
I also mentioned several tools in the slides and videos:
- I used Google Chrome (stable, v33) on OSX for all my examples.
- gfxCardStatus for pinning a mac to a specific graphics card
- Slowy for emulating high-latency networks (alternatively Charles Proxy or Network Link Conditioner)
Additionally there are a few documentation resources I strongly encourage you to read:
- The documentation for the Chrome developer tools, including:
- How to use multiple Chrome users
- Ilya Grigorik’s excellent Browser Networking book. I believe this can be read online, but if you are a professional developer the money will be well spent.
- Iilya’s recent talk on Speed, Performance, and Human Perception
Let me know if you have feedback on the presentation, and thanks to those who attended. In such a short talk it would have been difficult to comprehensively cover all the possible performance hangups in an Ember application, so instead these slides focus on giving you a new and better understanding of the tools available for gathering data, analyzing issues, and asserting the success of a change. With some practice, you will be using them every day.
Thanks to everyone at EmberConf for a fantastic week!
Correction: *setProperties does not cause observers to coalesce***
In my presentation at EmberConf, I stated that setting multiple properties with setProperties would cause an observer to only fire once. This is incorrect. The observer will fire for each property changed. See an illustration of the behavior in this jsbin. Thanks to @krisselden for the catch.