See also the previous bug  crbug.com/517183 

https://www.shacknews.com/chatty has been reported as having laggy and low frame-rate scrolling with the mouse wheel.

This has even been discussed on the site in the context of Chrome being slower than other browsers: https://www.shacknews.com/chatty?id=38047315#item_38047315

Regarding shacknews.com/chatty:

By default, a lot of posts are filtered.  I suspect this reduces the number of DOM nodes enough to make a noticeable difference.  If I view while not logged in to the site, the site scrolls much better.

So it might require making a user account and then checking all the boxes in the "Comment options" section of https://www.shacknews.com/settings , saving, then reloading that page.

Testing in that mode on my workstation I see that each mouse-wheel scroll triggers three frames, and each arrow-key scroll triggers two. The initial delay from input to dwm update is 180-200 ms. Subsequent updates take about 130 ms each. So, yeah, sluggish.

I can't currently do testing on Edge but I will assume that it is faster.

One modest slowdown comes from there being an apparent ~18-23 ms delay from the input occurring to Chrome really getting to work (there is a brief delay before any processing happens, and then a ~12 ms delay before work really starts).

Getting rid of that delay would be nice (I will watch for it in other pages) but the bigger problem is that long delays between frames. That time is almost entirely spent in JavaScript code. It's not immediately clear what that JavaScript is doing or why it would be slower in Chrome than in other browsers.

I looked some more at the script that was using all of the time - it's app-built.js which contains headroom.js. This script is designed to show and hide a header based on where the web page is located. As a test I killed the header completely with the awesome "kill sticky" bookmarklet (https://alisdair.mcdiarmid.org/kill-sticky-headers/) and the performance returned to normal.

Specifically:
- Scrolling started immediately when the input event was received - no 18-23 ms delay
- Chrome managed to generate thirteen frames in ~242 ms, which is pretty close to 60 fps. In fact, it runs at a perfect 60 fps until the last frame which takes 50 ms to generate instead of 16.66.

I still need to investigate why this script is working worse on Chrome than on Edge.