Reducing scroll jank when using overflow-y: scroll;

Question

I have a 2 column layout, the right hand column is a scrollable result lists with a max of 200 item results (basically just a ul with overflow-y: scroll; set)

Answer 1

I tried out your test page and took a look.

First, with scrolling perf issues I like flipping on a few of the checkboxes in the Rendering pane:

Instantly we can see this div called out as "repaints on scroll". You can then verify that in the experimental Layers panel:

(I right-clicked in the tree and selected "Show internal layers" btw)

Now large "update layer tree" costs are usually caused by LOTS of layers or a few layers that are very large in dimensions. In this case we really have neither. But we do have a scrolling layer that's not getting composited scrolling.

Composited scrolling == fast scrolling == usually the default. But in cases like this we fall back to "main thread scrolling" which is really slow and sucky. On the plus side, crbug.com/381840 is just about to be fixed which should fix this test case automatically. Yay! But we can work around it for now.

The workaround

You did mention you tried will-change and it didn't have an effect, but trying it myself has worked out great. It belongs on the element that has overflow set, in this case its the .map-search__results selector. Add will-change: transform;. Once added, the "repaints on scroll" rect is gone. And measuring with timeline afterwards and it's MUCH better.

Here's a before/after view:

link to viewer

Good luck!

Answer 2

If your issue is noticeably visible to you while scrolling you should be able to, with both the timeline and styles tabs open in your developer tools, uncheck styles that apply to your elements one by one in the styles tab and see how it effects the scrolling. This way you can test each style rule independently instead of entire CSS files. And if you're using sourcemaps in your CSS you should easily be able to find the offending rule in your actual CSS files and make adjustments.

If you're unfamiliar with using the styles tab: with Chrome developer tools open, use the inspector tool (top left corner of the developer pane) to select your items you suspect might be giving you issues. All styles associated or overridden for the selected element will be listed in the styles tab. You can then turn them off one by one. You can use the inspector to drill down as deep as you wish through nested items as well.

UPDATE:

I pulled down the code after your edit and looked at it pretty closely. I noticed that the overflow you have was on your ul item. Personally I've never used overflow on a ul (typically preferring a container like div for that), so out of curiosity I removed overflow-y:scroll from your ul and put it on the ul's containing div .right-content (and set it's height to 100%), and the janky scrolling is gone.

As for the why, I can only speculate, but I believe it has to do with the number of items you are scrolling. When your overflow is on the UL, you are directly scrolling ALL of those child li items. When it's on the containing div, you are actually scrolling ONLY the ul, so I would believe that this process has much less math to determine when calculating positioning of the moving items. 1 div positioning to adjust vs. hundreds of li's to adjust.

If you compare the timelines in the images above you'll see the difference. The one on top is the original version with overlflow-y:scroll on the ul. You can hover over all those little lines in the update tree process and see that there are hundreds of items being painted. These are your li items. In the second timeline is the version where I've removed the overflow from the ul and applied it to the containing div. You can see in this timeline the update tree process has only one item to paint which is the ul. If you look at the dimensions of the items you'll see the difference in size as well.