Smashing Conf: 60 Frames Per Second

by Luke Wroblewski September 10, 2013

In his talk at Smashing Conf in Freiburg Germany 2013 Addy Osmani shared some tips for rendering Web experiences at 60 frames per second and why it matters. Here's my notes from his talk Gone in 30 Frame Per Second:

  • Everything you add to a blank screen slows down display time.
  • Conversations about responsive design have shifted from layout to performance. We all have a vested interest in delivering faster experiences. Mobile is pushing this need even further. What we are building for the Web has been evolving -they are getting more complex.
  • Bootstrap was rebuilt to be mobile first. The buttons went from gradient styles to flat button style. Linear gradients provided a 100% improvement in paint time.
  • We all ship things with performance flaws of some sort -we've got to launch.
  • First do it, then do it right, then do it better. Ship it but make a list of the performance issues you have and work through them. Face up to what can be improved.
  • Don't guess -test it. Use tools to determine where performance issues occur.

Painting a Page

  • Janky scroll experiences these days often come down to rendering issues and frame rate.
  • Browsers used to paint pages as complete bitmaps, now they paint them as layers that are composited by the computer's GPU.
  • You can force elements into different layers with CSS hacks to make things paint faster.
  • Frame rate is how fast a device can display consecutive images to the screen. A 60 frames/sec is the refresh rate of most displays today (60hz), which is an ideal target for smooth scrolling. If you can't target 60 fps, aim for 30 fps instead. At 60 fps you have 16.7ms to paint a frame. Factoring in mobile, you have 8-10ms to paint a frame.
  • At 15fps or lower, people will experience jerky and jittery rendering and engagemnet can drop.
  • 30fps is actually smooth if you can keep it constant. If it is variable people will notice an issue.
  • Frame rate matters and can impact your engagement.

Rendering Issues

  • The heavier your Javascript onscroll handlers are, the longer it takes to paint a page.
  • Onhover elements paint the additional elements revealed and the content below it. A set Timeout or delay on hover can help increase smoothness of scrolling so it doesn't trigger unless people actually need it.
  • Deeply nested elements inside a page makes it difficult to measure paint times for them.
  • Chrome paint tools allow you to turn on/off CSS styles and see the impact on paint time.
  • Full source images are an issue for a rendering perspective. Pre-scale images as much as possible to avoid rendering times.
  • Box shadow is rendered in the Web browser and can become a bottle neck for frame rate. Test with paint tools (like Paint rectangles) to see if it is an issue for you.
  • More browsers now involve the GPU to composite the paint step in a browser. Hardware acceleration can help speed up browser paint steps.
  • On mobile, you can end up eating up your GPU RAM if you use CSS hacks to enable GPU acceleration. Tread carefully.
  • Properties that trigger reflow(repaint) are innerText, scrollHeight, outerText, and many many more. Not repainting the entire screen helps apps feel a lot more performant.
  • On scroll handlers, many CSS properties, image resizes in the browser, too many things happening in event handlers, heavy animation, and data processing can all slow down the time it tales to paint a frame.
  • Some properties are more expensive to render than others. Some when combined have a heaver compound rendering cost. Border radius is one of the most expensive properties to make use of along with transforms, linear gradients, and box shadows.