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

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


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/14fd7413640000

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

[css-contain] Make contain:layout a stacking context by rego@igalia.com
https://chromium.googlesource.com/chromium/src/+/f01f396190da97d7218ee2f5d76b6b637bf3ced2
25.26 → 26.06 (+0.8071)

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

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

I guess this performance regression is somehow expected.
If the site uses "contain: layout", now it'll be creating new stacking contexts
(which I guess is more expensive than not doing it).

So it's not a surprise that some sites are now slower due to this change.
The change just adds a condition to know if it should create or not a stacking context
to follow what's defined in the spec.

I'm not sure if any further action from my side is required.
Adding eae@ on CC to check his opinion on this topic.

Yeah this is unfortunate but to be expected. Correctness trumps performance. Hopefully we can implement enough further optimizations for contains to make it a win in most, if not all, cases.

Thanks.