Matthew Beale gave us a lot to think about and showed me a bunch of tools I had no idea existed in this talk about performance. He started by giving us some good things to think about… mainly, what does fast mean to you? He showed different speeds and what that would mean in terms of actually viewing an app (ie- animations, etc.). You can use that “fastness” scale to then look at your code and see what piece is taking the longest. Is it the network? The javascript? Or the render? Thinking about each of these and looking at times for each part help you narrow down what tools to use and what part needs to be made snappier.

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.

Next, we looked at “janky” animation. To solve this issue, you first need to understand browsers, then you measure with the timeline tool (another one of the inspector tabs). You can highlight a specific section to get more information about it. You can look at frames which show how long something takes to get to the screen. Green = paint, yellow = javascript, clear = upload to GPU, compositing. AND THEN, render console has a bunch of additional tools you can use to record and generate the data.

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 .setProperties or 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.