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.