New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 664657 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature



Sign in to add a comment

Measure wifi precache impact only on affected pages

Project Member Reported by twif...@chromium.org, Nov 11 2016

Issue description

crbug.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.
 
Labels: -OS-Linux
Labels: -Type-Bug Type-Feature
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.)
Owner: twif...@chromium.org
Components: Internals>Preload
Components: -Internals>Network>DataUse
Status: WontFix (was: Assigned)

Sign in to add a comment