I found that best results are achieved when both prefetching and warmup renderer creation is disabled. I see ~300ms reduction in startup time over 100 runs: https://docs.google.com/a/chromium.org/spreadsheets/d/16XfzB2FPToxjGWI821GQ52fAWz56SACAYAoZ_sJi8xU/edit?usp=sharing

My methodology was simple:

1. Build and install Monochrome, register it as a webview provider

2. Run Chrome, sign in with a test profile (EM-oriented, not very large)

3. Run build/android/adb_profile_chrome_startup --url=https://wikipedia.org 100 times, with and without --cold argument

4. Parse reports and extract three metrics:

   * Startup, the time from "ChromeApplication.onCreate" and until "BenchmarkInstrumentation::ImplThreadRenderingStats" (first time we draw layers), this is roughly the time when tab counter appears in [ ] tab button

   * Load, the time from "NavigationTiming navigationStart" and until "firstContentfulPaint"

   * Startup + Load, the time from "ChromeApplication.onCreate" and until "firstContentfulPaint"


I see ~300ms reduction in "Startup", and no regression in "Startup + Load". I.e. Chrome starts faster.

 Issue 761605  has been merged into this issue.

I've decided to abandon this idea (crrev.com/c/687963) because while Startup metric improves, Start+Load (i.e. time from start to firstContenfulPaint) stays the same. See pages in the sheet:  https://docs.google.com/a/chromium.org/spreadsheets/d/16XfzB2FPToxjGWI821GQ52fAWz56SACAYAoZ_sJi8xU/edit?usp=sharing

why is it not worth improving startup metric alone? If there are some other bottlenecks for page load perf later in the pipeline, why should they block this improvement?

Improving Startup means that UI finishes initialization a bit faster. Visually that means tab button shows tab count faster. I think that doesn't worth the complexity this change adds.

We might want to reopen this in the future, but for now we better focus on other startup issues, like the fact that renderer is often blocked on the browser UI thread.

> I think that doesn't worth the complexity this change adds.

Are you referring to the complexity of disabling prefetching for low end devices or complexity of benchmarking or something else?

Sorry, from your comment and spreadsheet I could not find what change you were testing.

oh sorry, I did not recognize crrev.com/c/687963 as the uploaded patch, now it is clearer

I would argue that the complexity of a 40 line change is totally worth 300ms UI draw improvement. We will be adding AndroidGo startup as a perf testing configuration anyway, so I am not seeing added complexity in benchmarks either.

I tend to agree with Egor. If it looks like chrome is ready and the page load just takes longer to load but it's truly a wash on load time, I think that's an improvement for user experience

OK, I'll revisit this once I finish with other stuff.

lizeb@ is working on making prefetching (much) smarter in issue 758566.

And "disable warmup renderer" bit will be covered by  issue 796957  (by moving it after library loading).

We can return to this issue once these pieces land, but for now I'm closing this.