Hmm. That makes sense. Perhaps we want separate UMA conditioned on (1) the preview was triggered, and (2) the preview was applied. At the very least, we'd want counts of triggered vs applied.

We have counts of applied via the infobar UMA. I would say that we should add UMA to track triggered on a page as a seperate bug.

So what would you propose this bug track?

This bug should be a rename of LoFiOn PLM UMA to litepage UMA, and we should change the tracking condition to look for a litepage page received.

I think the main thing we want to track is TTFCP and PLT for the various kinds of Preview pages we serve. Since we have several kinds (server LoFi, server WebLite, server HD, client LoFi, etc.) it might be best to have a separate histogram for each type. Is that possible or too much work?

I think these histograms should only be recorded when a given type of Preview was *applied*.

It is fine with me if they live under the PageLoad.Clients.DataReductionProxy.* namespace, even though not all of these Preview types are delivered via the proxy.

Thoughts?

To lay out what we have as of today:
PageLoad.Clients.LoFi.* -- Tracks both server and client LoFi applied pages (client LoFi can be used on server LoFi pages, and maybe vice versa?)
PageLoad.Clients.Previews.OfflinePages.* -- Tracks Offline Previews
PageLoad.Clients.DataReductionProxy.* -- Tracks DRP page loads and DRP holdback page loads
PageLoad.Clients.DataReductionProxy.LoFiOn.* -- Tracks DRP page loads where server previews are not prevented by some client behavior (client side blacklist)
PageLoad.Clients.NoScriptPreview.* -- Tracks No script applied preview pages

I was initially opposed to combining client and server LoFi pages, but I think in a lot of ways, it's fine to do this. They do very similar things, and sometimes they will trigger together.

It seems we are not tracking "lite pages", but all of the other previews are tracked in some way.

We have a couple options here, but I believe we should standardize to:
PageLoad.Clients.Previews.LoFi.*
PageLoad.Clients.Previews.LitePages.*
PageLoad.Clients.Previews.NoScript.*
PageLoad.Clients.Previews.OfflinePages.*

This would mean LoFiOn would be removed, and LitePages would be added, but all names would be standardized on "Previews". Again, all of these would track actual previews pages (the infobar would be triggered) as opposed to eligible to be previews.

Thoughts?

Refreshed during triage.

Refreshed during triage.

I'm going to defer to buettner@ in terms of what UMA we should be tracking here, since this is closely related to the PLM data collected through a separate channel, and I don't have strong feelings about exactly how we record this information.

I think this is a good idea and worth doing. We can't do very deep analysis for server previews from UMA as we don't know exactly what flavor of Preview was served a lot of the time.

But, Previews related UMA will be useless without knowing if a Preview was actually triggered and I'm sure we'll need to share UMA at some point. 

I don't feel strongly about how client-side previews are tracked. Server-side it's fine to lump it all together as "Lite-page" -- we can pull details from serve logs if need be. 

I think we should transition to client-side LoFi for both HTTPS and HTTP instead of spending time trying to get any LoFi specific to combine server and client LoFi.

I'd like client optimizations to each have separate UMA.

I think the proposal for this bug is splitting things into:
PageLoad.Clients.Previews.LoFi.*
PageLoad.Clients.Previews.LitePages.*
PageLoad.Clients.Previews.NoScript.*
PageLoad.Clients.Previews.OfflinePages.*

This means refining the lite page name and verifying it is recording the correct thing.

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

commit 6b1d7dffd1a1d11f6e9d124a67f506816ddb080b
Author: Ryan Sturm <ryansturm@chromium.org>
Date: Tue May 15 23:44:05 2018

Replacing LoFiOn UMA with LitePages UMA

This change removes PageLoad.Clients.DataReductionProxy.LoFiOn.* and
adds PageLoad.Clients.Previews.LitePages. The key difference in these
two histograms is the earlier triggers for all pages that use server
LoFi or server LitePages, whereas the new UMA will only trigger for
pages that use server LitePages.

Bug:  720035 
Change-Id: I48c6f349aa5e1a6dfc2e261729ca8d3d624cb08d
Reviewed-on: https://chromium-review.googlesource.com/1060098
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Commit-Queue: Ryan Sturm <ryansturm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558884}
[modify] https://crrev.com/6b1d7dffd1a1d11f6e9d124a67f506816ddb080b/chrome/browser/page_load_metrics/observers/data_reduction_proxy_metrics_observer.cc
[modify] https://crrev.com/6b1d7dffd1a1d11f6e9d124a67f506816ddb080b/chrome/browser/page_load_metrics/observers/data_reduction_proxy_metrics_observer.h
[modify] https://crrev.com/6b1d7dffd1a1d11f6e9d124a67f506816ddb080b/chrome/browser/page_load_metrics/observers/data_reduction_proxy_metrics_observer_unittest.cc
[modify] https://crrev.com/6b1d7dffd1a1d11f6e9d124a67f506816ddb080b/tools/metrics/histograms/histograms.xml