For more aggressive progress bar completion strategies, only count high priority resources

For more aggressive progress bar completion strategies, only count high priority resources

BUG=513459
Committed: https://crrev.com/7671698c85e8d997cd9e1421fbc89f433e717f30
Cr-Commit-Position: refs/heads/master@{#418656}

[Nate Chapin, 2016-09-13 21:55:51]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-13 21:56:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nate Chapin, 2016-09-13 22:31:35]

japhet@chromium.org changed reviewers:
+ dcheng@chromium.org, kingston@google.com, ojan@chromium.org

[Nate Chapin, 2016-09-13 22:31:36]

This is a tweak of https://codereview.chromium.org/1860743002

ojan, kingston: FYI

[dcheng, 2016-09-13 22:39:27]

lgtm

[ojan, 2016-09-13 23:41:01]

I was picturing something more aggressive of just counting visible images, but
on further thought, this probably will get us something pretty close to the same
effect since sync/defer scripts will already block domContentLoaded anyways. So,
this just adds web fonts and stylesheets to the things we block the progress bar
on, which seems pretty reasonable.

In ideal world, I'd like to be able to test both of these configurations at the
same time (e.g. domContentLoaded vs domContentLoaded+high priority resources),
but that's probably more engineering effort than it's worth at the moment, so
lets land this and see how it feels.

lgtm

[Nate Chapin, 2016-09-13 23:43:39]

On 2016/09/13 23:41:01, ojan wrote:
> In ideal world, I'd like to be able to test both of these configurations at
the
> same time (e.g. domContentLoaded vs domContentLoaded+high priority resources),
> but that's probably more engineering effort than it's worth at the moment, so
> lets land this and see how it feels.

"at the same time" meaning showing 2 progress bars?

[commit-bot: I haz the power, 2016-09-13 23:46:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-13 23:46:16]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Nate Chapin, 2016-09-13 23:47:01]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-09-13 23:47:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ojan, 2016-09-13 23:58:54]

On 2016/09/13 at 23:43:39, japhet wrote:
> On 2016/09/13 23:41:01, ojan wrote:
> > In ideal world, I'd like to be able to test both of these configurations at
the
> > same time (e.g. domContentLoaded vs domContentLoaded+high priority
resources),
> > but that's probably more engineering effort than it's worth at the moment,
so
> > lets land this and see how it feels.
> 
> "at the same time" meaning showing 2 progress bars?

No, I just meant that in an ideal world we'd have more flag entries instead of
changing the meaning of the exisiting ones so we could change the flag value to
compare the different settings. But, I think you should land this and we should
play with it on some real content before investing more engineering time.

[Kingston T, 2016-09-14 00:01:10]

On 2016/09/13 23:58:54, ojan wrote:
> On 2016/09/13 at 23:43:39, japhet wrote:
> > On 2016/09/13 23:41:01, ojan wrote:
> > > In ideal world, I'd like to be able to test both of these configurations
at
> the
> > > same time (e.g. domContentLoaded vs domContentLoaded+high priority
> resources),
> > > but that's probably more engineering effort than it's worth at the moment,
> so
> > > lets land this and see how it feels.
> > 
> > "at the same time" meaning showing 2 progress bars?
> 
> No, I just meant that in an ideal world we'd have more flag entries instead of
> changing the meaning of the exisiting ones so we could change the flag value
to
> compare the different settings. But, I think you should land this and we
should
> play with it on some real content before investing more engineering time.

I believe we're tweaking the "resources before domContentLoaded" flag so you can
still compare DomContentLoaded and DomContentLoaded + high priority. The other
flag didn't seem as necessary as it had virtually the same end state from what I
could tell.

[commit-bot: I haz the power, 2016-09-14 02:29:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-14 02:29:58]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[kinuko, 2016-09-14 09:10:00]

Hi- does this patch mean the experimental behaviors we've added in the previous
patch (e.g. DCL + same-origin iframe resources etc) didn't look enough /
convincing?  I've been wondering the status of the experiment these days and
just noticed this CL.  If you have any preliminary results of the ongoing
experiments I'd really love to hear that-- thanks!  (Sorry if it's already
shared somewhere and I'm just missing it)

[Nate Chapin, 2016-09-14 19:03:51]

On 2016/09/14 09:10:00, kinuko (slow) wrote:
> Hi- does this patch mean the experimental behaviors we've added in the
previous
> patch (e.g. DCL + same-origin iframe resources etc) didn't look enough /
> convincing?  I've been wondering the status of the experiment these days and
> just noticed this CL.  If you have any preliminary results of the ongoing
> experiments I'd really love to hear that-- thanks!  (Sorry if it's already
> shared somewhere and I'm just missing it)

Sorry, there was an email thread. Added you to it. Short version is that
domContentLoaded is looking a bit too aggressive, and DCL+resources-before-DCL
doesn't appear to be much different from the old onload completion point. So
we're trying making DCL+resources-before-DCL a little more aggressive.

[Nate Chapin, 2016-09-14 19:04:14]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-09-14 19:05:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 20:22:55]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-14 20:26:03]

Description was changed from

==========
For more aggressive progress bar completion strategies, only count high priority
resources

BUG=513459
==========

to

==========
For more aggressive progress bar completion strategies, only count high priority
resources

BUG=513459

Committed: https://crrev.com/7671698c85e8d997cd9e1421fbc89f433e717f30
Cr-Commit-Position: refs/heads/master@{#418656}
==========

[commit-bot: I haz the power, 2016-09-14 20:26:05]

Patchset 1 (id:??) landed as
https://crrev.com/7671698c85e8d997cd9e1421fbc89f433e717f30
Cr-Commit-Position: refs/heads/master@{#418656}

[kinuko, 2016-09-15 05:17:55]

On 2016/09/14 19:03:51, Nate Chapin wrote:
> On 2016/09/14 09:10:00, kinuko (slow) wrote:
> > Hi- does this patch mean the experimental behaviors we've added in the
> previous
> > patch (e.g. DCL + same-origin iframe resources etc) didn't look enough /
> > convincing?  I've been wondering the status of the experiment these days and
> > just noticed this CL.  If you have any preliminary results of the ongoing
> > experiments I'd really love to hear that-- thanks!  (Sorry if it's already
> > shared somewhere and I'm just missing it)
> 
> Sorry, there was an email thread. Added you to it. Short version is that
> domContentLoaded is looking a bit too aggressive, and DCL+resources-before-DCL
> doesn't appear to be much different from the old onload completion point. So
> we're trying making DCL+resources-before-DCL a little more aggressive.

Got it- thanks!