Here are some metrics that might serve as a proxy for serious single page apps:

- use of `pushState` or `replaceState` (this would help identify serious "single page apps" that support navigation).
- use of app cache or service worker (this would identify apps that are willing to commit to assets not being totally transient).
- use of IndexedDB, the File API and perhaps localStorage (this would identify apps that have non-transient data)

I'd be happy to think more about useful proxy signals if this generally makes sense and segmenting based on some signals like these might be something you'd want to do.

Renaming Blink>Architecture to Blink>Internals

#1: Thanks for the suggestions.  Ideally we wouldn't need to specifically identify "serious single page apps" but instead come up with a metrics design which is more agnostic to the type of page/app.

One option would be to treat each pushState/replaceState call on the main frame like a top-level navigation - with the idea that conceptually it's a new page view (but loading has been optimized away).  But then if a feature is used only during page load on a site with a lot of pushSates (eg. GMail) this change would result in that feature's usage to go down dramatically.  But I guess that's not really much different than a site mandatory whose login page depends on a feature, but then redirects you to other pages (the whole site is broken if the feature breaks, but metrics report it only as necessary for one of those PageVisits).

Another option would be to treat same-origin navigations as a no-op from a UseCounter perspective - so that rather than talk about "per page-view" we'd be talking about "per site view".

Big picture, if we're going to change something fundamental in our metrics strategy like this, I think we'll want to study the difference between it and our existing scheme (holding everything else constant).  So I don't think we'd want this to block the metrics rework/rename in  issue 676837  (which is more urgent anyway).

Concretely, I think we should try adding a "per host visit" variant of our histograms and compare the results to the "per page visit" one.  If the protocol/port changes it's probably reasonable to consider that part of the same "host visit".  But if the hostname changes at all, that's a new scope for metrics purposes.

foolip, igrigorik, rnyman, pmeenan: do you have any intuition here on what metrics strategy is likely to correlate best with "how risky is it to change/remove this feature"?

Hooking things up with pushState/replaceState will probably skew things towards certain long-lived sites that use those APIs more, where it's not really significant for the user.

The "per host visit" variant would be interesting, but would end up weighing the sites you visit and immediately leave (back to search) the same as the sites where you stay forever. It would be interesting to compare the numbers with the per-page one, but not obviously a better or worse proxy for risk, and probably more biased against single-page apps than our current metrics.

To assess risks in long-lived tabs is tricky. One idea is to ignore page/site loads and simply measure hits per hour. But what happens in the first few seconds is probably disproportionately important. And for single-entry-point style APIs like canvas.getContext(), 100 calls may be no worse than a single call. Background tabs that will be closed also barely matter at all, except for server-sync-related code in the page.

I can't see a single metric that would be perfect, but an hits-per-visible-second metric should be less biased against single-page apps. One could perhaps implement it as sending the metrics (as they are today) of the active tab every N minutes. Short visits could be missed entirely, but overall it should represent all the code paths that influence what the user is actually seeing/hearing.

hits-per-visible-second sounds promising, thanks.  I'd support experimenting with that.

It's not obvious that the benefit we'd get would justify the investment.  Marking this Available for now - I'll update this bug if/when we have compat issues where something like this may have helped (i.e. we get complaints after removing an API that was used by a popular SPAs).

(advice from my talk on data analysis)
If you're planning to do something like hits-per-visible-second, I suggest you record the component values separately and compute the ratio in the analysis side.  Don't compute the ratio within Chrome and log only that.

Can you clarify? I imagined we would simply record the metrics once every hour (on average), and divide by a metric that's always recorded, similar to PageDestruction in the method currently used for chromestatus.com.

"I imagined we would simply record the metrics"
What do you mean by "the metrics"?  If you mean, record hits and emit that count, then on the analysis side look up the hits histogram and another histogram for the denominator such as page loads, that's fine.  I mean don't do the division in Chrome.

(If you do the division in Chrome, and you see an upload of "2" for hits-per-visible-second, you don't know whether this was 2 hits in a one-second visit or 120 hits in a one-minute visit.  These mean very different things, and you've lost the necessary information.)

I mean something like the current WebCore.FeatureObserver or the new WebCore.UseCounter_TEST.Features, where the denominator is one of the enum values, in histograms.xml terminology. When recording the metrics, that value would always be set. (Maybe that makes it unnecessary, I don't know UMA very well.)

That sounds fine.  Just don't do any sort of division (computing a fraction) within Chrome.

Reviewed, as part of triage of old bugs. Still something we might want to address, if we run into compat issues.