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

Issue 682220 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Need metric to identify cases where doc.write blocking would have triggered

Project Member Reported by bmcquade@chromium.org, Jan 18 2017

Issue description

When doing logs analysis for doc.write blocking, it's desirable to analyze only cases where doc.write blocking could have triggered, to minimize noise from samples where the feature couldn't have triggered. This is especially important given that the blocking only triggers on ~7% of page loads when on 2G.

We have a metric to identify cases where we reach FCP after encountering blocking, however this is not sufficient for purposes of comparing stats between control and experiment population.

We should add a simple counter that gets recorded as soon as we learn we encountered a doc.write block scenario, in order to identify these cases in a way that's comparable between control and experiment.
 
Some additional info from the code review, where it was asked why we can't use the existing FCP metric for this purpose:

The FCP metric is only recorded if a page encounters a blocking script, and then reaches FCP.

Pages in the experiment population are more likely to reach FCP as a result of encountering a blocking script than those in the control, since in experiment the page loads faster as a result of blocking the script.

Thus we encounter cases in experiment where doc.write FCP is recorded, but wouldn't have been in control, as the user would have given up on the page load before FCP was reached.

This means that we can't use the presence of the FCP metric as a way to drill down on the population of 'affected' users between control and experiment in a way that makes those populations comparable across control and experiment.
I see, FCP isn't sufficient because you want to know about pages that could have blocked but don't reach FCP. Is that right?
You responded before my response sent. Strange, it used to warn you about that. Ignore comment #2.
Project Member

Comment 4 by bugdroid1@chromium.org, Jan 18 2017

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

commit 6cc8974e18028a1e18779c36318acfe5c069ec2c
Author: bmcquade <bmcquade@chromium.org>
Date: Wed Jan 18 22:39:14 2017

Add counter for number of page loads where doc.write blocking triggers.

When doing logs analysis for doc.write blocking, it's desirable to
analyze only cases where doc.write blocking could have triggered, to
minimize noise from samples where the feature couldn't have triggered.
This is especially important given that the blocking only triggers on
~7% of page loads when on 2G.

This change adds a counter that allows us to keep track of cases where
the feature could have triggered, in a way that's comparable across
control and experiment populations.

BUG= 682220 

Review-Url: https://codereview.chromium.org/2644543002
Cr-Commit-Position: refs/heads/master@{#444519}

[modify] https://crrev.com/6cc8974e18028a1e18779c36318acfe5c069ec2c/chrome/browser/page_load_metrics/observers/document_write_page_load_metrics_observer.cc
[modify] https://crrev.com/6cc8974e18028a1e18779c36318acfe5c069ec2c/chrome/browser/page_load_metrics/observers/document_write_page_load_metrics_observer.h
[modify] https://crrev.com/6cc8974e18028a1e18779c36318acfe5c069ec2c/chrome/browser/page_load_metrics/observers/document_write_page_load_metrics_observer_unittest.cc
[modify] https://crrev.com/6cc8974e18028a1e18779c36318acfe5c069ec2c/chrome/browser/page_load_metrics/page_load_metrics_browsertest.cc
[modify] https://crrev.com/6cc8974e18028a1e18779c36318acfe5c069ec2c/tools/metrics/histograms/histograms.xml

Status: Fixed (was: Started)

Sign in to add a comment