We checked this on a couple of phones and at least on the Nexus 5 (Chrome M53) it's scrolling at 60 fps most of the time. There is an occasional hitch when the page presumably loads new content (?) during scrolling, but other than that it seems to work okay. Does this match what you're seeing?

If not, please record an about:tracing trace (preferably with the disabled-by-default-renderer.scheduler category enabled) and attach it here and we can diagnose further.

I can reproduce even after all loading has finished. Flinging the page results in  periodic stuttering during the fling. Perhaps a long running javascript function? Trace attached.

Deleted: trace_macys.json 9.7 MB

trace_macys.json 9.7 MB View Download

I should have noted, the trace above was captured on a Nexus 5X with Chrome stable (52.0.2743.98). I'm not really sure what to make of the trace, but it looks like there's two RendererSchedulerShortIdlePeriods that exceed 100ms during the scroll but without much visibility into what's going on. I would expect to be able to see V8 if we're calling into JS so perhaps this is an issue somewhere in Chrome.

I also captured a timeline trace in devtools. This shows multiple frames >100ms but no clear reason why, there's lots of timers being fired but there's no "one big" function call.

+creis

It looks like BeginMainFrame occasionally gets held up behind a long-ish running (~100ms) task posted by StartNavStateSyncTimerIfNecessary.

StartNavStateSyncTimerIfNecessary normally kicks off a RenderViewImpl::SendUpdateState, which serializes the current WebHistoryItem into a PageState.  It's possible that could be a slow task if the page has enormous data to serialize (like some pages which unfortunately store huge amounts of JS in the frame's name).  This would happen 1 second after events like typing into a form or scrolling, both of which get stored in the history item.

You might check to see how big the PageState object is, to see if that confirms the theory.

dcheng@ had some plans to limit the size of frame unique names to mitigate this to some degree.  See  issue 626202 .

I logged the PageState size and it looks like we're continually creating PageStates ~400kb so that's likely the problem.