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

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


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

android-webview-nexus6

According to chromeperf, there is only one CL in the range.

https://bugs.chromium.org/p/chromium/issues/detail?id=773018

Can you check if your CL might be the cause?

My CL makes us paint broken image icons more often than we did before, so the regression is plausible and also unavoidable (insofar as the test is probably inadvertently testing how we handle a lot of unavailable images on a page).

 Issue 773360  has been merged into this issue.

Sheriff pass. This CL seem to have caused 245 alerts in the rasterize_and_record_micro.top_25 benchmark (pretty much on all bots).
Assigning benchmark owner (vmpstr) to make a call. Looks like this is about broken images and specs compat. Don't know enough to make a call as a perf sheriff.

+wkorman, are we still running these sets with some images unavailable? From the size and number of regressions and with comment #3 in mind, I would imagine it's only possible if we have a lot of broken images.

I think this caught us in a state where we're updating the pagesets to be static and we need to start including more images, which should recover the regression.

wkorman, wdyt?

FTR the cl in question is https://chromium.googlesource.com/chromium/src/+/6abc19e88235609c7b8fc9df464beed2b667a773

Yes, duping to a similar regression which is blocked on the work to restore images to all of the static pages in the top 25 page set.