All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=923440

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=a7bd213a94e84d3dcb33a9d385961690fd01a4f7c5dc0d75ff9b24e6ef8fcf72


Bot(s) for this bug's original alert(s):

Android Nexus6 WebView Perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/138aa86a540000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/138aa86a540000

Roll AFDO from 73.0.3671.0_rc-r1 to 73.0.3672.0_rc-r1 by chromium-autoroll@skia-public.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/2c7da71a5d429c476dbe4351fa3b8fdec82ecefa
frame_times: 123.1 → 128.5 (+5.408)

Assigning to sheriff gbiv@chromium.org because "Roll AFDO from 73.0.3671.0_rc-r1 to 73.0.3672.0_rc-r1" is a roll.

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Appears to be fixed by the roll in r624467. The roll in r622307 looks like the one that initially won us a decent chunk of CPU, then we regressed back to (perhaps) slightly worse than we used to be in r623150, then we won it all back.

This looks and sounds very similar to issue 923363, so I'm duping this against that.