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

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


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

linux-perf

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

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

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

start to use SkFont api (paint's equivalents are deprecated) by reed@google.com
https://chromium.googlesource.com/chromium/src/+/d90028160469664fccdec91f15b64202b91a2600
timeToFirstContentfulPaint: 483.2 → 623.5 (+140.4)

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

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

This is still outstanding. Can we move work off the critical loading path to go earlier? https://crrev.com/f8746079c0456d3b4091e7d06fd05856691a5bb7 is an example of that to help this same metric.

Do we know, at the method level, where the time is being spent? Is it in the textblobbuilder?

This work (migrating textblob's to store SkFont) is ongoning, and should make blobs lighter and more efficient, but we are definitely in the "middle" of that migration. That said, if there is a critical step we should focus on, we may be able to buy back some speed in the short-run.

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