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

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


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

Android Nexus5 Perf
Android Nexus5X WebView Perf
Android Nexus6 WebView Perf
Win 7 Perf
android-nexus5x-perf
linux-perf
mac-10_12_laptop_low_end-perf

memory.desktop - Benchmark documentation link:
  None

system_health.memory_mobile - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

system_health.memory_desktop - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

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

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

Roll src/third_party/catapult 277cdb9bcc3e..ebff6e2b3d0a (1 commits) by chromium-autoroll@skia-public.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/c6cf8e1b190c0b4b73caf9d8d0776d3237aa6e05
memory:chrome:all_processes:reported_by_chrome:v8:effective_size: 9.063e+05 → 5.795e+06 (+4.889e+06)

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

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

Should be ebff6e2b3d0a296de583edc76f4c75031ed3bb7c 
  Potential Perf Regression Expected: Add nonce to injected scripts for responses with restrictive CSP script-src directive.

Please close if this was expected.

This change fixes a bug in WPR where CSP blocks injected script from running. So the change induces behavioral change, which may trigger performance regressions.

That said, I suppose the ask is to explain what really happened here. Without evidence, my speculation is that the WPR fix allowed script that confers determinism in date time and random number functions to execute. The determinism in turn caused the page to load in new content that WPR previously responded with 404.

Where may I find the WPR trace and the url used in some of the failing tests? Loading the wpr archive manually with and without the fix should shed lights.

Mhm, looking closer the regressions have either recovered *or* their baseline (ref) also changed. I don't think there's anything to do here. Would be awesome if the ref changes would be filtered out in first place :/