Measure wifi precache impact only on affected pages |
||||||
Issue descriptioncrbug.com/663987 aims to provide a filter whereby we can select affected client ids. This filter can be applied to any of the histograms available in UMA. In addition, for page-level metrics such as PageLoad.PaintTiming.NavigationToFirstContenfulPaint, Net.ErrorCodesForMainFrame3, and HttpCache.Pattern, it would be useful to filter such reports only for the pages that were affected by the precache (or would have been, for control). I can think of three different ways of doing this, and propose doing the one of middle difficulty: ## Recommendation In control, fetch the manifests and pretend to fetch the resource URLs by adding them to the precache database. (AFAICT, precache::UpdatePrecacheMetricsAndState() will correctly mark resources as not-precached/used even in control, but verify this.) In both control and enabled, add a new PrecachePageLoadMetricsObserver to chrome/browser/page_load_metrics/observers. For every page view, it should call history::HostForTopHosts() to compute the "host", and then call PrecacheDatabase::GetURLListForReferrerHost() to get the unused_urls. ("used_urls" are those that would have been in the cache by now regardless of precache.) If the intersection of unused_urls and the list of subresources for the current page is non-empty, then report paint timings. ## The easy alternative In both control and enabled, add a new PrecachePageLoadMetricsObserver that reports paint timings iff HistoryService::HostRankIfAvailable() < some threshold. This has false positives, in that many pages for a given top host won't be affected by a precache, and false negatives, in that precaching global resources such as ad-provider JS may benefit pages outside the top hosts. The result is that it will still under-report precache's impact compared to the recommendation. ## The difficult alternative In both control and enable, actually fetch the resources into the cache, but with an additional flag in the cache entry that tells the control to act as if the entry is not there. This has some problems: what to do if the entry was there prior to precaching? what to do about resources evicted by precaching? It's also much more difficult to implement.
,
Nov 11 2016
,
Nov 11 2016
One more wrinkle: In order for control to be a fair comparison, its pretend prefetches must respect the byte caps. Therefore, control will need to issue HEAD requests for the reosurces. (Do HEAD responses get stored in the cache? If so, we'll have to make sure to bypass that as well.)
,
Nov 17 2016
,
Apr 11 2017
,
Apr 11 2017
,
Jun 18 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by twif...@chromium.org
, Nov 11 2016