Smoother scrolling in Firefox 46 with APZ

Have you ever been on Facebook or Twitter, merrily scrolling down the page, when all of a sudden, the browser appears to freeze? For several long seconds it just hangs there, and you’re not sure if it’s going to crash or not. Then, finally, something gives way, and the page jumps to catch up to your scrolling, disorienting you? That’s called jank, and in Firefox 46 Beta we are well on our way to making jank a thing of the past.

In Firefox 46 Beta, we’re bringing asynchronous panning and zooming (APZ) to Firefox. The underlying technology was first developed for our mobile platforms, where responsiveness to touch input is one of the pillars of performance. Now we are bringing that over to our desktop platforms, and using it for mousewheel/trackpad scrolling. With APZ, scrolling down pages should be smooth and jank-free, even if the page is busy running lots of JavaScript or is slow to repaint. In future releases, we plan on enabling APZ for other methods of scrolling (such as touch and scrollbar-dragging) as well.

Under the Hood

Browsers traditionally handled user input events on the browser’s main event-handling thread. This meant that it could get blocked by pretty much anything else the browser was doing, including running scripts and painting. In Firefox, the Electrolysis (e10s) project separates the content process from the main browser process. This gives us another path for handling input events. Instead of passing the input events from the parent process to the content process to drive scrolling as usual, the input events are used to drive scrolling in the parent process compositor before they are forwarded to the child process for normal processing and dispatch. This is illustrated in the diagrams below.


Figure 1. Code flow without e10s or APZ.


In Figure 1 above, the potentially long-running operations are indicated in red. Although the compositor thread can still composite to the screen rapidly (at 60 frames per second), it relies on getting the painted content from the main thread. Since the main thread can be blocked by long-running JavaScript or paint operations, paint updates from scroll inputs also gets blocked and can’t get to the compositor.


Figure 2. Code flow with e10s and APZ

In Figure 2 above, we can see how introducing e10s and APZ affects the flow. The input events arrive in the main thread of the parent process, which is free of long-running operations. Therefore, it can quickly pass on the input events to the compositor thread, where the APZ code uses it do asynchronous scrolling. Meanwhile, the input event is also forwarded to the main thread of the child process, where it is delivered to web content and triggers repainting. Even though these operations may still be slow, they no longer block the scroll updates from being composited to the screen.

This approach, although great for responsiveness, requires e10s to be enabled, and also introduces a certain complexity. For instance, the parent process needs to be able to do some amount of hit-testing on child processes to know where the input event landed. It also means that the parent process needs to have a mechanism for handling events on which preventDefault() is called by web pages. For details on how this all works, refer to the APZ documentation.


Of course, nothing is free, and APZ comes at a cost. APZ does eliminate jank, but in some cases it does so by checkerboarding instead. Checkerboarding is what you get when you scroll faster than the browser can paint the page. When this happens, the content at your new scroll position hasn’t been painted yet, and so we just show a flat background color. (The term checkerboarding comes from the original iPhone implementation, which would show a checkerboard pattern.) Once the painting catches up, the content fills in.

Checkerboarding is inevitable with asynchronous scrolling due to memory limitations; it’s the cost of removing jank. However, in most cases it shouldn’t be noticeable – it only lasts a few hundred milliseconds, and we are working hard to bring that down further. The way we do this is by painting content outside of the visible area ahead of time, so that when the user scrolls it’s ready to be displayed right away. By better predicting where the user is going to scroll we can reduce the amount of checkerboard shown. Overall, trading off jank for checkerboarding results in a better user experience because the browser itself remains responsive and doesn’t appear to freeze or hang.

Scroll-Linked Effects

APZ also has an impact on the way scroll-linked effects work. Because APZ does scrolling asynchronously from the main thread, this necessarily means that the scroll events seen by the web content will be delayed. In other words, there is some propagation delay from when the user scrolls until the scroll event can be dispatched to the web content. If the page uses the scroll event to reposition some content on the page, it will take additional time to process that change and display it to the user. This means that scroll-linked effects can appear delayed and out of sync with the scrolling. Under ideal circumstances, the delay between the user’s scrolling and the scroll-linked effect being visible should be no more than 2 frames (33ms at a frame rate of 60 frames per second). Although this is barely noticeable, in practice it may take a bit longer if the page is tying up the main thread with scripts, or if it is complex and takes a while to repaint. Therefore, it’s still important for the page to remain as responsive as possible by breaking up long-running scripts or using workers.

To eliminate this delay entirely, authors have the option to implement the scroll-linked effects using CSS positioning rather than JavaScript. We have CSS-only options available for the most widely used scroll-linked effects, including sticky positioning and the parallax effect. With CSS positioning, we can know ahead of time how the positioning will change, and so we can keep it perfectly in sync with the user’s scrolling. You can find examples and more details about scroll-linked effects in the MDN article.

About Kartikaya Gupta

Kartikaya Gupta is a developer on Mozilla's Platform Graphics team, and works on scrolling-related things in the Gecko rendering engine.

More articles by Kartikaya Gupta…


  1. abral

    Does this mean that e10s is going to be enabled in Firefox 46?

    February 9th, 2016 at 10:11

  2. Luca

    Personally I found IE10 and IE11 in Windows 8 very smooth and quick in scrolling pages and not afflicted but lags and hangs that Firefox showed up, since 3 years ago.

    I don’t know if the problem is the same, but I hope that this could bring Firefox to “fight” in speed to IE rendering

    February 10th, 2016 at 00:48

  3. nicofrand

    ” We have CSS-only options available for the most widely used scroll-linked effects, including sticky positioning and the parallax effect.”

    Most widely, I am not sure, lot of us are still waiting for sticky positioning with table headers :/.

    February 10th, 2016 at 01:39

  4. Kartikaya Gupta

    The current plan is to enable e10s in Firefox 46 but not necessarily for all users. We may keep it disabled for users with configurations that we know don’t work well. APZ will only get enabled for those users who have e10s enabled as well.

    February 10th, 2016 at 06:05

  5. Jason Weathersby

    Release features are gated on quality not set by a specific version so we can’t commit to a exact version until we are satisfied that this feature is ready for general release.

    February 10th, 2016 at 12:11

  6. abral

    Jason, I was wondering that because the title of the article says “in Firefox 46”. Thank you for the clarification.

    February 10th, 2016 at 13:00

    1. Jason Weathersby


      Sorry about the confusion. We could have made that a bit clearer.

      February 11th, 2016 at 09:29

  7. Peter J. Sloetjes

    In the current Nightly versions, I am experiencing flashes of white on pages with a dark background during fast page scroll. How is the fill color determined? If the fill color cannot be guaranteed to be equal to the computed style of the top element, then it would be nice if it could be set with a user preference.

    February 13th, 2016 at 15:18

  8. Pete

    Hi, have you experienced scrolling on new Retina / 5k iMac? It is between 25-35 fps :-( Even on v. 47. Chrome/Safari has no issues.

    February 14th, 2016 at 10:36

  9. Kartikaya Gupta

    Peter, we do try to use the background color of the scroll frame. There may be elements on top of that background which make it appear as though the background color is something else. This is particularly the case when images are used as a background. That being said, if you have a specific case you feel is being incorrectly handled, please file a bug for it and we can investigate. Thanks!

    February 15th, 2016 at 20:04

  10. Kartikaya Gupta

    Pete, no, I personally have not tried scrolling on a 5k iMac. It may be that we need to tune some settings for the high-resolution display to improve performance. It would be helpful if you could file a bug for that and include a specific URL that demonstrates the problem. Thanks!

    February 15th, 2016 at 20:06

  11. Pete

    Dear Kartikaya, thank you for your reply. I will do that @ bugzilla.

    I use nonRetina 27 as well as new Retina iMac (with second to best GPU offered – AMD m395) and website on nonRetina are mostly between 50-60 fps but on Retina iMac are usualy 20 fps lower :-(

    February 16th, 2016 at 00:20

  12. Peter J. Sloetjes

    Hi Kartikaya, thank you for your reply. Today I have looked for the issue I mentioned, but it does not seem to occur any more on the pages where I noticed it before :). My impression is that scrolling in Firefox is now more smooth than it ever was, so APZ seems to be really effective. Thanks!

    February 16th, 2016 at 13:45

  13. rafuse

    THANK YOU for this!! Really, I’ve been waiting for this forever!

    February 21st, 2016 at 05:11

  14. Wellington Torrejais da Silva

    Very good!

    February 24th, 2016 at 15:11

Comments are closed for this article.