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

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


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

chromium-rel-mac11-pro

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

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/12dea75f840000

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

😿 Pinpoint job stopped with an error.
https://chromeperf.appspot.com/job/15d1546f840000

Assigning to reviewer yhirano, since tyoshino is leaving the project: r537580, ""  caused a pretty significant memory regression on this test case. The job had an error, but it bisected to this CL. Can you take a look?

 Issue 814701  has been merged into this issue.

 Issue 814699  has been merged into this issue.

The change was a security fix and we expected that it would introduce some regressions.

cc-ing test owner erikchen FYI

Please clarify what you mean by "we expected that it would introduce some regressions.". 

We're observing a ~50MB regression in cc memory usage. It's possible that your CL is triggering some type of non-deterministic loading in WPR, causing more resources [images] to be loaded, and thus more memory usage. It's also possible that your CL has unintended [and unnecessary] side-effects that greatly increase memory usage.

Given the magnitude of the regression, the perf team would feel a lot better if you could spend some time investigating and/or explaining the magnitude of the regression.

As explained in  issue 799477  and issue 809350, reusing a resource that was fetched by another origin leads to a security issue. The CL stopped that, which means with the CL MemoryCache is less used.