html - 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)

What I am finding is that the right hand column is causing some jank (which is especially noticeable on low end hardware) when you scroll.

In the chrome timeline i can see some major "Update Layer tree" while I scroll the column. Is there any way I can figure out why "Update Layer tree" is so lengthy and what CSS properties are affecting speed the most? When I click on it - just gives me info on how long it ran for and nothing else.

I have some CSS in each of the li's that isn't performing very well (eg. filters, transforms, box-shadows etc) - If i remove each SASS file one by one, it improves the scrolling performance (and eventually removes jank once i remove all the CSS), but obviously its hard to pin point which css properties are not performing doing this.

I wonder if im missing something in the chrome timeline that can be helpful in this regard?

I have tried to use the will-change CSS property to promote the scroll to a different layer / force hardware acceleration - but this doesn't make much difference.

Also there is no javascript events executing while I scroll.

Limiting to less than 200 items isn't an option.

I have setup an example of this (I know its a longer list of items, but this is just for demo purposes): https://github.com/jooj123/jank/blob/master/scroll.html

What really interesting is that if i remove the overflow-y: scroll; (in .map-search__results in the example above) the scrolling becomes very smooth and jank disappears - why does this have so much effect?

Here is the chrome timeline (with basically just long "Update Layer tree" sections):

Fix:

Paul's answer about will-change: transform is spot on, in particular this tidbit helped:

"Add will-change: transform;. Once added, the "repaints on scroll" rect is gone."

BUT just be careful as it wont always apply depending on your code base, check the scroll performance issues indicator to make sure "repaints on scroll" is off, for me I had to also disable a -webkit-clip-path property (in my actual code base - not in the demo provided) that was set in one of the child divs, see:

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!