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

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


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

chromium-rel-mac11
chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
chromium-rel-win8-dual

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8972297667436017680

=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Helen Li
  Commit : 05ee1dbfaf0aa7c03b9ea2040f0345277042d0f1
  Date   : Mon Jul 31 13:24:01 2017
  Subject: [wpr-go] Switch system_health_desktop.json to use go

Bisect Details
  Configuration: win_8_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : timeToFirstContentfulPaint_avg/load_tools/load_tools_drive
  Change       : 33.52% | 1039.59696296 -> 1388.06981482

Revision             Result                  N
chromium@490724      1039.6 +- 481.902       9      good
chromium@490741      946.451 +- 339.829      6      good
chromium@490749      992.334 +- 336.534      6      good
chromium@490750      972.519 +- 348.303      6      good
chromium@490751      1705.47 +- 2017.86      6      bad       <--
chromium@490753      1339.23 +- 235.655      6      bad
chromium@490757      1388.07 +- 286.238      9      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.tools.drive system_health.common_desktop

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8972297667436017680


For feedback, file a bug with component Speed>Bisection

+ kouhei, ksakamoto@: FYI. The new WebPageReplay backend changes the performance characteristics of timing metrics like timeToFirstContentfulPaint.

It looks like enabling HTTP/2 on WebPageReplay has something to do with this timeToFirstContentfulPaint regression. 
The grouped alerts at https://chromeperf.appspot.com/group_report?bug_id=751983 seem to only have sites that support HTTP/2.

I have sent out an email to the loading team. I wonder if we can get any information out of the linked trace files. 

Let's put this bug on hold. There is a bug in WprGo which caused some webpages to not load completely, which definitely has an effect on loading metrics.

I will fix that and see if this regression will go away.

 Issue 752407  has been merged into this issue.

The fix mentioned in #7 landed in r491925. Looks like that didn't make timeToFirstContentfulPaint drop, so this regression is unlikely due to some pages being loaded incompletely. I will wait for the weekend perf data to confirm and check back on Monday.

The TimeToFirstContentfulPaint values are consistently higher.
I learned today that there is a way to kick off a run on a perf bot with additional tracing categories enabled (--extra-chrome-categories): 

https://chromium.googlesource.com/chromium/src/+/master/docs/speed/perf_trybots.md

I will see if that gives us anything.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/55fa713dce39544e3ae7a4a8a37dbc60b76e9783

commit 55fa713dce39544e3ae7a4a8a37dbc60b76e9783
Author: Helen Li <xunjieli@chromium.org>
Date: Tue Aug 08 03:50:35 2017

[wpr-go] Disable HTTP/2 for browse:social:twitter

This user story shows regression in TimeToFirstContentfulPaint. This is
to disable HTTP/2 on this story so we can see whether that is due to
HTTP/2 being enabled or something else is different about WprGo.

Bug:  751983 
Change-Id: I408435cae8d1ce969b4a7014f4d3fc339616c14d
Reviewed-on: https://chromium-review.googlesource.com/604870
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Helen Li <xunjieli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492524}
[modify] https://crrev.com/55fa713dce39544e3ae7a4a8a37dbc60b76e9783/tools/perf/page_sets/data/system_health_desktop_053.wprgo.sha1

 Issue 753656  has been merged into this issue.

Turning off HTTP/2 has no effect on TTFCP. https://chromeperf.appspot.com/report?sid=8c2b2d3f3934d3b0a95a727eedf88d871283ffe17c0e4198606f51d74c08b066&rev=490757

The underlying issue was with WprGO, there are fewer cache hits during cert verification, so establishing a connection takes longer. The old Wpr uses the same cert for all connections.

For more details, see https://bugs.chromium.org/p/chromium/issues/detail?id=756481#c10. I am merging this into the other bug.