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

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


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

linux-perf
mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

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

blink_perf.layout - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

blink_perf.paint - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

blink_perf.shadow_dom - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

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

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

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

unsupported operand type(s) for +: 'float' and 'NoneType'

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

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

[FCP++] Enable FCP++ metrics via finch experiment by maxlg@chromium.org
https://chromium.googlesource.com/chromium/src/+/4e243fc4a328acee8354c73e7c9df2facac9f3f7
queueing_durations: 0.4522 → 0.6402 (+0.1881)

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

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

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

I confused queueing_duration with Expected Queueing Time until I found the definition here: https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/queueing_duration.html?type=cs&q=queueing_duration+package:%5Echromium$&g=0&l=18

 * This quantifies how out of sync the compositor and renderer threads are. It
 * is the amount of wall time that elapses between a
 * ScheduledActionSendBeginMainFrame event in the compositor thread and the
 * corresponding BeginMainFrame event in the main thread.

I am surprised how FCP++ can relate to the queueing duration. FCP++'s main cost happens in pre-paint, which is way later than frame start.

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

unsupported operand type(s) for +: 'float' and 'NoneType'

+Ehsan, do you know how the queueing durations metric may relate to the implementation of FCP++? 

Here's are something FCP++ is doing, do you see anything suspicous? 
- FCP++ runs swap-time callback as a task on mainthread
- FCP++ runs timer callback as a task on mainthread
- FCP++ records image/text at pre-paint stage
- FCP++ has a hook in LayoutObject::WillBeRemovedFromTree

FCP++ design doc: https://docs.google.com/document/d/1DRVd4a2VU8-yyWftgOparZF-sf16daf0vfbsHuz2rws/edit#

Implementation:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/paint_timing_detector.h