Experimenting delaying scroll start on wikipedia page in key_mobile_sites_smooth

Experimenting delaying scroll start on wikipedia page in key_mobile_sites_smooth

Currently smoothness action (e.g. scrolling) starts when the
document.readyState = interactive or complete. It is noticed that when
the readyState = interactive, the page can still be loading resources
so there would be contention on the main thread between resources loading
and input handling, which could have impact on the smoothness metrics.

It is to our interests in actually solving the contention issues so we
don't want to artificially delay the action start just to avoid the
contention. But I do see the benefit in running an experiment on just
wikipedia with delayed action start so as to understand to which degree
this contention is affecting our metrics.

So this CL makes a duplicate of the Wikipedia page in the
key_mobile_sites_smooth and running that particular page with
starting scrolling on readyState = complete.

BUG=455277
Committed: https://crrev.com/0d9d1bc419bbeabe0a6a6767cba9254441712da3
Cr-Commit-Position: refs/heads/master@{#314932}

[Yufeng Shen (Slow to review), 2015-02-05 21:46:37]

miletus@chromium.org changed reviewers:
+ nednguyen@google.com

[nednguyen, 2015-02-05 21:49:17]

nednguyen@google.com changed reviewers:
+ jdduke@chromium.org

[nednguyen, 2015-02-05 21:49:17]

LGTM if key_mobile_sites_smooth's owners are happy

[jdduke (slow), 2015-02-05 21:51:17]

On 2015/02/05 21:49:17, nednguyen wrote:
> LGTM if key_mobile_sites_smooth's owners are happy

lgtm

[Yufeng Shen (Slow to review), 2015-02-05 21:51:28]

The CQ bit was checked by miletus@chromium.org

[jdduke (slow), 2015-02-05 21:51:30]

https://codereview.chromium.org/901563003/diff/1/tools/perf/page_sets/key_mob...
File tools/perf/page_sets/key_mobile_sites_smooth.py (right):

https://codereview.chromium.org/901563003/diff/1/tools/perf/page_sets/key_mob...
tools/perf/page_sets/key_mobile_sites_smooth.py:178: name='Wikipedia (1 tab)'))
What is this "1 tab" modifier all about?

[Yufeng Shen (Slow to review), 2015-02-05 21:52:43]

https://codereview.chromium.org/901563003/diff/1/tools/perf/page_sets/key_mob...
File tools/perf/page_sets/key_mobile_sites_smooth.py (right):

https://codereview.chromium.org/901563003/diff/1/tools/perf/page_sets/key_mob...
tools/perf/page_sets/key_mobile_sites_smooth.py:178: name='Wikipedia (1 tab)'))
On 2015/02/05 21:51:29, jdduke wrote:
> What is this "1 tab" modifier all about?

no idea, I guess just some historical naming.

[commit-bot: I haz the power, 2015-02-05 21:53:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/901563003/1

[commit-bot: I haz the power, 2015-02-05 23:58:23]

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

[commit-bot: I haz the power, 2015-02-05 23:58:24]

Try jobs failed on following builders:
  android_dbg_tests_recipe on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)

[Yufeng Shen (Slow to review), 2015-02-06 00:04:34]

The CQ bit was checked by miletus@chromium.org

[commit-bot: I haz the power, 2015-02-06 00:05:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/901563003/1

[commit-bot: I haz the power, 2015-02-06 01:04:23]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-06 01:05:50]

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

[nduca, 2015-02-10 18:27:25]

Drive by: this is a really great goal to chase further... we should aspire to
having monitoring of more (all?) of our pages in both earlyscroll and 
afterload-scroll modes. Anecdotally, people scroll the second we do our first
paint.

Editorially: is there a difference in practice between first paint, the first
time raf fires, and complete state?

[chromium-reviews, 2015-02-10 19:05:12]

On Tue, Feb 10, 2015 at 1:27 PM, <nduca@chromium.org> wrote:

> Drive by: this is a really great goal to chase further... we should aspire
> to
> having monitoring of more (all?) of our pages in both earlyscroll and
> afterload-scroll modes. Anecdotally, people scroll the second we do our
> first
> paint.
>
>
Yeah, I was thinking of making a dup of the whole
sync_scroll.key_mobile_sites_smooth
that runs afterload-scroll as reference. The wikipedia page in this CL is
used as
a pilot to verify our conjecture that the noisy perf metrics results are
indeed due to
the timing of scroll start.


> Editorially: is there a difference in practice between first paint, the
> first
> time raf fires, and complete state?
>
>
I wouldn't trust first paint and first raf. They are more browser
implementation dependent.
And in practice I can see many frames pushed out during web content loading
(without any
user interaction). While complete/interactive state is at least web
standard backed up.


> https://codereview.chromium.org/901563003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.