Turns out that this is only because loadUrl which fires navigationStart is called earlier in the async chain on ChromeTabbedActivity startup vs WebApkActivity startup. I wrote up a cl/995635 to fix this.

Deleted: Screenshot from 2018-04-04 12-04-57.png 31.3 KB

	Screenshot from 2018-04-04 12-04-57.png 31.3 KB View Download

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

commit 73460b05653a5746c587f1342149927d20ba3497
Author: Mohamed Heikal <mheikal@google.com>
Date: Thu Apr 05 23:43:57 2018

[WebApk] Move loadurl earlier in startup

Tab.loadurl is currently called in finishNativeInitialization in
WebappActivity vs in initializeState in ChromeTabbedActivity.
initializeState is called earlier in the async chain in
ChromeBrowserInitializer. This CL moves the call to loadUrl to
initializeState in WebappActivity.

Testing shows that this change leads to a 50-70ms improvement in
startup time:

	                         improvement	 average deviation
Startup (ms)	                  81.86214	 39.11936
StartupToNavigation (ms)	  66.5648        34.37813714
NavigationToCommit (ms)	          56.64914	 20.09670629
NavigationToContentfulPaint (ms)  5.47332	 29.81943543
StartupToContentfulPaint (ms)	  72.03812	 47.7408
NavigationToMeaningfulPaint (ms)  5.4415	 29.80534286
StartupToMeaningfulPaint (ms)	  72.0063	 47.73242286

Bug: 825259
Change-Id: I90aee902d9d0fcef4972fafd40453f6f02b320d1
Reviewed-on: https://chromium-review.googlesource.com/995635
Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: Dmitry Skiba <dskiba@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548615}
[modify] https://crrev.com/73460b05653a5746c587f1342149927d20ba3497/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java

See this result inspired me and I had a thought for squeezing out maybe a few ms due to queuing in our system. Take a look at https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/init/ChromeBrowserInitializer.java?q=+tasks.start%5C(true&sq=package:chromium&dr=C&l=246

Here we queue up a number of java tasks and then ensure we only execute one per iteration of the message loop. Maybe that's overly naive given that promoting loadUrl by one task had a meaningful improvement for low-end devices. Couple thoughts:
1) Maybe some of our tasks are effectively "free" but other stuff is getting interleaved. However, because we only do one at a time, we let other stuff slide in and delay critical path initialization. If we look at a profile and some of these tasks are very short _AND_ other tasks are interleaving between, we could try giving ourselves a budget (say <5ms has passed, process another task before yielding?)
2) Alternatively, just post all the tasks at once - don't wait for a task to execute before posting the next and let the message loop just work through them. I could be mistaken but I thought we wanted to have separate tasks so that input events could squeeze in which this would still preserve. I see Dmitry tried something similar (https://docs.google.com/document/d/1OAd1fYv2ugUaiLOTnBPtebNsfvzKaxA-aQVeasmQ6dA/edit#heading=h.zac3d1rbasw2) but isn't as unfair to the UI thread
3) The ordering may not make sense. Could we try starting of tab loading earlier?
4) The very first task does some stuff which seems unnecessary: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/init/ProcessInitializationHandler.java?type=cs&q=initializePostNative&sq=package:chromium&l=204
- The photo picker work happening here?
- SearchWidgetProvider.initialize potentially forces the TemplateUrlService to load which is a separate database (probably small) but could cause more IO contention when we're dealing with paging in the native lib already. This may not even show up in a simple testing-only profile but a user with active data could see it (https://uma.googleplex.com/p/chrome/histograms/?endDate=20180404&dayCount=1&histograms=Sqlite.SizeKB.Web&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial suggests average 1.5mb but median only around 400kb)

While looking at this, I noticed something else bizarre. We always initialize the layer decoration cache:
https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java?type=cs&q=enableLayerDecorationCache&sq=package:chromium&l=283 and
https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/device/DeviceClassManager.java?type=cs&q=enableLayerDecorationCache&sq=package:chromium&l=45
Pretty sure that ^ should be false.

Err, guess I got carried away. :)
Might not amount to much, but I think worth investigating.
Can probably split some of that out to other bugs too

Err I'm probably wrong about (2). I think due to how our message loop works, we could have some native events processed but it would likely still block input events cause they originate in java