Scrolling with 60fps

In the frames section of Chrome Developer Tools, we can inspect how smooth things appear on the screen while browsing a website. This is a useful tool that allows us to test the responsiveness of a site in regard to loading, scripting, rendering and painting. Recording a browser session allows us to see the frames as they appear. Then we can easily compare if we reach the target of 60fps. 60fps might seem quite much for a website, if we consider that our eye won't object while watching a film or animation encoded with 30fps. Although a film can have a lot of action, it is still presented in a fixed amount of frames per second. A website has a more dynamic nature and we can't guarantee that every visitor will look at it in exactly the same way or that he/she will use similarly. A user can potentially turn on/off website components, rearrange things on the screen, download resources, or even juggle between Photoshop, Dreamweaver and Maya with his/her browser accidentally open. Every operation the PC performs affects the browsing experience directly or indirectly, which means that the results of measuring frames-per-second can vary greatly.

The idea of Nyquist, also used in the well-known MP3 algorithm, was that to be able to reconstruct a signal without noticeable loss, we need to sample it at a rate that is twice as high as the maximum frequency of the original signal. If we think about images, we also can't take a smaller photo and convert it in a larger one without quality loss. On the contrary, we often do the opposite. So, in a sense, the 30fps above what we are already used to is a line of defense in case something goes wrong. And with browsing that can be a lot of things. For instance, my browser always gets slower when a file is scanned by the antivirus program or when the hard disk is buffering a large file while watching a video. Some earlier browser versions had a problem with large background images when you tried to scroll a content on a transparent layer. Some new CSS3 properties (box-shadow, border-radius) can be slow too, but probably only in relation to the others and depending on the number of times they get executed. Usually, the most jank will probably be caused by JavaScript, although “it always depends”. In situations like these, when we can do something, this tool can be useful, but we shouldn't forget that as designers we can't control the user's behavior (nor should we). This behavior by itself can influence the perception of a website. A designer can at most direct it so at least it can't be wrong.

That said, I am a bit concerned that we might start looking at websites as animations and evaluate them from an fps standpoint rather than from a value standpoint. Even if animations are of high-bandwidth nature and can carry a lot of information, there are far too many situations where static content makes more sense. The truth is that both types usually complement each other. So we probably can't measure a site from a single perspective and simply label it “jank-free”. Scrolling moves content up and down so we see it animated, but it's usually not where most of the user's time is spent, since it temporary blocks other kinds of interactions with the page. It's not the main mode of operation on a website to be measured in that way. How important could be to scroll with 60fps if the user can't do anything else?

bit.ly/XwnwEn