This UMA doesn't cover every type of navigation, but it covers a lot of cases. Note that parse start is recorded based on when the start of the page gets to blink:

https://uma.googleplex.com/p/chrome/histograms/?endDate=20180630&dayCount=1&histograms=PageLoad.ParseTiming.NavigationToParseStart%2CPageLoad.ParseTiming.NavigationToParseStart.Background%2CPageLoad.ParseTiming.NavigationToParseStart.LoadType.ForwardBackNavigation%2CPageLoad.ParseTiming.NavigationToParseStart.LoadType.ForwardBackNavigation.NoStore%2CPageLoad.ParseTiming.NavigationToParseStart.LoadType.NewNavigation%2CPageLoad.ParseTiming.NavigationToParseStart.LoadType.Reload&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

IIUC that includes the time from the request being sent to the first byte being received. I was hoping to factor that out.

Also, I think separating link clicks, omnibar navigations, and intents would be telling.

Ping! This bug has been flagged as stale by Chrome Speed Metrics bug triage, and it has an owner. Any update on this issue?

bengr,

I think the right way to go about this is via UKM. Could you clarify:
Do you mean the amount of time from navigation start until we start to send the headers to the final location (including redirects and connection time)? Or something in that area. Note with network s13n, it may be a little trickier to get certain events exposed at the level we would need them.

With s13n, it should still be possible to get resource timing for the main frame request. See https://cs.chromium.org/chromium/src/chrome/browser/page_load_metrics/observers/ukm_page_load_metrics_observer.cc?rcl=ab0c2e9255d4158565ec08abe9daf72a25c09f6b&l=147.

I agree we should do it in UKM. From UKM PLM observer, we can also get the time for navigation start. Subtracting that from time when the main frame request was sent should give us the required result.

This is now recorded as UKM MainFrameResource.NavigationStartToRequestStart