Lesson Outline

Debugging Frame Rate Issues

When developing applications with Ionic (or anything) it is important that we achieve a frame rate of around 60 frames per second. A frame is the result of the browser having done the necessary work required to figure out what your application should look like and then painting it to the screen - essentially a snapshot of what the application looks like at a point in time.

Generally, our application will cause what is displayed on the screen to change over time. We might scroll down the page, or we might increment a counter that needs to be displayed to the user, or we might delete an item in a list, or we might trigger an animation. In each of these cases, we need new "frames" to be calculated and displayed. In the case of something like a scrolling list or an animation, the screen is constantly changing, and so constantly requires new frames to be displayed.

The concept is the same as a flip book, animation, or movie. A bunch of still images displayed in quick succession will give the illusion of movement. If you do this fast enough, that illusion of movement will look fluid, natural, and you would not be able to tell you are actually looking at a bunch of still images.

The point at which an application will feel fluid to a user is around 60 frames per second, if we go too far below that the user may notice what is commonly referred to as "jank" - what appears on the screen will appear to stutter and jump around. We lose the movie like illusion of fluid movement, and can instead notice the individual frames being displayed.

In order to achieve a good FPS (frames per second), we need to reduce or optimise the work the browser needs to do to make its way through the steps outlined in the Understanding Browser Rendering lesson:

Image from developers.google.com licensed under the Creative Commons Attribution 3.0 License

1. JavaScript (CSS) - Perform work that results in visual changes
2. Style - Calculate which CSS rules apply to each element. Calculate final styles.
3. Layout - Calculate how much space elements take up on the screen and where they sit.
4. Paint - Draw the pixels on the screen
5. Composite - Apply the appropriate "layers" on the screen in the correct order and with the correct size/location/orientation

A "frame" occurs each time the browser goes through the steps required above and displays something on the screen. Our general goal when aiming to improve frame rate is:

1. Avoid as many of these steps as possible, wherever possible - it is much better to trigger just the paint/composite steps rather than forcing the browser to recalculate the entire layout again
2. When we need to perform these steps, make it as easy as possible for the browser

We will be discussing strategies to achieve this in the following lessons (interacting with the DOM and animations are especially relevant to this). For now, we are going to focus on using the Performance tab to measure the frame rate of our applications and being able to identify where the browser is spending time doing "work". Once we can see where the application is struggling, we can focus on the areas that require optimisation.