When you’re ready to dive into performance and have pinpointed what part needs working on, then you can move on to the recommended methodology. This is 1) gather the facts and isolate the problem. 2) analyze and theorize about what’s going on. 3) change a single thing… if you change a bunch of stuff and performance is better then you don’t actually know what made the difference. And 4) confirm the theory. The example Matthew used was loading the ember.js website on your phone.
So, first you need to reproduce the immobile latency reliability… in this case you can use slowyapp, Charles, or network line conditioner. You then create a clean browser (this was also a new concept to me) which means you have no extensions, a private window and therefore nothing interfering with the site you’re working on. Then you measure and analyze in the network inspector. In that inspector you can check out the timings tab which gives you a bunch of information.
Part of that information shows us that if you look at the timeline, you can see the load order of things and how long each element is taking. Here, you end up being able to move a script tag which makes the page’s load time much faster.
If you’re a little lost on where all these tools are and how to access them, the slides show it all pretty clearly.
Also, at this point in my notes I had written “OMG, so many tools!” which I thought was worth sharing here.
In this case, the solution to the issue is a webkit transform that keeps it on the GPU and then uploads the whole thing to the graphics card. By adding a Z translation to the animation, it forces the GPU to say this is 3D and should be put on the graphics card.
Finally, we talked about ember.js property change notifications. For this methodology, first you need to understand observers and then look at the profiler. Observers are synchronous and fire when a set thing occurs. There are two options
Ember.run.once. Then you look at the profiler. The profiler has processing and memory. You run a profile and get back information in form of a flame chart. A flame chart allows you to see the stack that is being run. In the list view you can use the profiler to pinpoint the issue. Here, you refactor to create a buffer instead of pushing items into an array which fires 1 change notification instead of many.
The important thing to remember here is to have a methodology to solve issues, to remember that web performance does not equal ember performance and that there are a heck of a lot of awesome tools you can use to help you out. comments powered by Disqus