So what is the metric for "user facing page load"? The main resource reached first paint? Do you want to include all navigations or exclude some (like chrome: schemes)?

Hmm, it seems that my use of "user centric" was confusing.

I think MobilePageLoaded is what we need (whenever a tab loads)

So whenever Chrome starts loading a main resource we should record an "Page load" event.
 - This can happen either as the result of user action or Chrome actions (e.g. restore an evicted tab).
 - There is no expectation of an end state (no need to condition the event recording on reaching a particular point of the page load).


Does this make sense?

I would caution against this as the only metric. We often get clients that send off thousands of provisional loads that never commit, skewing the data a lot. Also keep in mind many of these navigations are not "page views" because we never navigate away from the current page.

Obviously the number of navigation commits is also not really what you want, but possibly the two together would be OK.

 Issue 614122  has been merged into this issue.

I opened a similar bug which I've since duped to this one. Text from that bug:

We currently have PageLoad.Timing2.NavigationToCommit which counts the number of page loads that commit, and PageLoad.Timing2.NavigationToFirstPaint which counts the number of page loads that paint something to the screen, but we don't have a count for number of initiated web page loads. Kenji recently started a thread where we looked at using the PageLoad and MobilePageLoad counters, but these are unowned counters and we could do better adding some owned and maintained counters to PageLoad.* UMA.

In general tracking this correctly is difficult, since we can't distinguish at navigation time between web page loads vs navigations that result in downloads, or PDFs, or images or other non-webpage content (which PageLoad.* UMA histograms currently filter out post-commit).

One thing we may be able to do is have a set of counters for:
* number of navigations initiated
* number of navigations that complete successfully, but result in a non-web-page resource load (e.g. download, or PDF, or image, etc)
* number of navigations that complete successfully, and commit a web page load (this is already available as the sum of PageLoad.Timing2.NavigationToCommit events)
* number of navigations that fail

Unfortuantely this is made increasingly complex by the fact that downloads and 204 responses are reported as failed navigations with error code ERR_ABORTED, with seemingly no other signal to distinguish them from other kinds of aborts.

That aside, these numbers taken together should give us insight into things like:
* what percent of successful navigations result in a web page load (as opposed to some non web page content like a download or PDF)
* what percent of all navigations result in a successful navigation

This problem is unfortunately difficult enough that it'd benefit from someone studying it and writing a short doc summarizing constraints and challenges, and proposing the best path forward to give us insight into navigation counts.

In the meantime, I've been using the count for PL.Timing2.NavigationToCommit and more recently the combined count of PL.Timing2.NavigationToCommit  and PL.Timing2.NavigationToCommit.background.

Maybe that's all we need?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot