Our screens have a speed at which they draw and redraw pixels. This is commonly referred to as the refresh rate:

We can see that this screen has a refresh rate of 60Hz. This means that what we see on screen is redrawn 60 times a second. Now, why am I taking up your valuable time to draw attention to this detail?

The reason is this. For the longest time, we never had to imagine a world where things would need to display faster than 60 times a second. The three things we could always be certain of were:

1. Death ☠️

2. Taxes 💸

3. Your visual updates would appear at most 60 times a second 💻

Now, don’t worry. Things #1 and #2 are still certain. What has changed is that many of us are now accessing content on devices whose screens refresh far faster than 60Hz. For example, the newer Macbook Pros and their ProMotion refresh rate setting can push the refresh rate well into 120Hz territory:

Many mobile devices, newer gaming monitors, and more have high refresh rates these days. Higher refresh rates often result in more responsive movements in fast-paced games, smoother animations, and more.

As a response to this, our browsers have reacted by ensuring frame-rate sensitive timers like requestAnimationFrame fire faster than 60 times a second. If developers didn’t anticipate a future beyond 60fps, the same visual code run using requestAnimationFrame would result in wildly different running speeds, as visualized below:

Now, before you ask, we’re picking on requestAnimationFrame because its speed is tied to the screen’s refresh rate. It is the animation approach most impacted here. Both CSS Animations and the Web Animations API use a time-based approach for running animations, so their running speed isn’t impacted by changes to the refresh rate.

Throttling the Frame Rate

Fortunately, we have a great solution that we can use to to mitigate the varying speeds we may see with requestAnimationFrame. That solution involves throttling the frame rate to our desired speed, and this will work independent of the screen’s refresh rate or the speed requestAnimationFrame will run at:

// set the expected frame rate
let fps = 60;

let interval = 1000 / fps;
let startTime = performance.now();
let previousTime = startTime;

let currentTime = 0;
let elapsed = 0;
let frame = 0;

function animationLoop(timestamp) {
  currentTime = timestamp;
  elapsed = currentTime - previousTime;

  if (elapsed > interval) {
    previousTime = currentTime - (elapsed % interval);

    // add your animation code
  }

  requestAnimationFrame(animationLoop);
}
animationLoop();

In this code snippet, we can change the fps variable to any frame rate we want. It doesn’t have to be 60, so this approach gives us quite a bit of flexibility.

If we set a frame rate higher than what requestAnimationFrame will run at, this code will run at the maximum rate requestAnimationFrame will support on a particular device.

Meet framerate.dev

How often have you been curious to find out what the frame rate (as determined by requestAnimationFrame) is on a particular device? If the answer is more than once, check out a fun page I created called framerate.dev:

Load the page, and in a few blinks of your eye, you’ll see a frame rate appear. Frame rates in the browser are fun to dig into, and to see some exciting findings people have shared, check out this thread.

Conclusion

I hope you found this technical dive into frame rates fun! Until next time, feel free to follow me on Twitter or chat about this (or any other topic) on the forums.

Cheers,

Kirupa 😀