Thanks for kicking this off, I’ve been looking into providing similar experiments.

I can't speak to the amount of work it would be, but I've been thinking about the same problem from a few different perspectives, and this is one of the few solutions I also thought about.

I wonder for this experiment if freezing the last paint causes users to no longer be able to scroll or interact in any way on the previous page making it feel like the browser is frozen as opposed to delaying a white screen. From my personal experience, hitting a white page feels like progress, whereas staying on the old page when a link is clicked feels like I might not have clicked the link, so I try again, or feels like the browser UI is being janky.

What metrics would be most useful for this: I would think abandoned page loads is probably good to detect user confusion about the page loading, and maybe amount of times the tab or app is backgrounded between navigation start and FCP.

I think the initial proposal from kenji is the simplest, so it might be good to experiment with in canary/dev with this and decide if this solution is good for our users, or if we need to look into a more engaging UI experiment.

Great. Assigning to you so we don't forget to make progress.

"if freezing the last paint causes users to no longer be able to scroll or interact in any way on the previous page making it feel like the browser is frozen as opposed to delaying a white screen."

That's definitely a concern. Ideally, we would still let you scroll but it seems that the implementation would be much harder. Regardless, ...

"From my personal experience, hitting a white page feels like progress, whereas staying on the old page when a link is clicked feels like I might not have clicked the link, so I try again, or feels like the browser UI is being janky."

is also right, and even if we had an interactive / scroll-able origin page.

Which means that the "hold paint" delay will have to be short to not annoy or confuse our users.

Perhaps, we would add a proxy metric to understand how often our users are potentially frustrated: how often the user tries to interact with the origin page while it's frozen. Alternatively, if the experiment is a success or if it's cheap, we could a UX treatment to convey the frozen state (i.e. washed out filter).

"abandoned page loads is probably good to detect user confusion about the page loading, and maybe amount of times the tab or app is backgrounded between navigation start and FCP.": sounds good. Abandoned page loads metrics are tricky, I would recommend reaching out to csharrison@.

And +1 on trying something in dev/canary that we can play with.

One other thing to figure out is when the URL bar changes to show the new address. Security team had some concerns about showing the old pixels with the new URL, but maybe that concern goes away if the old page has been torn down and it's just a static snapshot. In either case, I recommend a security review at some point. I'd probably do it after you have a prototype behind a flag that we're all fishfooding and believe is actually a better user experience.

See also  issue 470669  for an indication of how much users care about bad flashing.
As of right now we preserve the background color of websites during the transition.

Re #5, I believe the security concern is that script could from one origin while another is begin shown in the URL bar.

Re.#6, Thanks for the pointer to that issue! People do seem to care quite a bit! One idea we are considering is to transition to the background color of the target page. We have some tricks up our sleeves to determine what that color is. :)

If we can only fix this for same origin navigation that would be a big step forward.

I think "Flash of white" is really a red herring. This should be called "Flash of unnecessary incomplete paint".

Any same origin navigation of this site shows the problem:
https://www.ampproject.org/

between every navigation there is a short white paint (page has white background color) even though the browser immediately has all resources available to do a meaningful paint.

Renaming to avoid any confusion about the objective.

We will initially move forward with a same-origin experiment that defers commits for min(x, FCP, [some load event that happens on pages without FCP]) seconds where x will be varied by field trial. This will allow us to determine engagement effects of this treatment in general.

Any update?

I haven't made much progress due to other work taking priority. If there are available resources to work on this, I'm happy to hand it off.

Temporarily re-assigns this to me for triage / planning

FTR: first prototype patch from kinuko@ was: https://chromium-review.googlesource.com/c/chromium/src/+/1146413

Working on a doc for a revised approach now.

Design doc:

https://docs.google.com/document/d/1Q-fq62PPeoz2EUygi1xzTdJwIgLwK6zP12_klO3wVXQ/edit#

Stephen will take this over and implement asap, according to the doc described
in comment 18.

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

commit 6d3f5ce70242b52d5132cd4a45264ad3d4770540
Author: Stephen Chenney <schenney@chromium.org>
Date: Wed Nov 14 02:08:05 2018

Rename DeferCommits to DeferMainFrameUpdate

This is in preparation for patches to avoid white flash on navigation,
when we will be introducing a DeferCommits that only defers commits,
not the document lifecycle. Renaming this DeferMainFrameUpdate makes
it clearer that we are deferring everything in this case.

This is a pure mechanical rename: DeferCommits -> DeferMainFrameUpdate and
defer_commits -> defer_main_frame_update. No functionality changes.

Added TODO in various places where we need to reintroduce the idea of
a deferred commit without a deferred main frame update.

See this design doc:
https://docs.google.com/document/d/1Q-fq62PPeoz2EUygi1xzTdJwIgLwK6zP12_klO3wVXQ/edit#

R=vmpstr@chromium.org, pdr@chromium.org
BUG=805798

Change-Id: I48c3b6c230f99e8a96c023a8c88f97de03f110af
Reviewed-on: https://chromium-review.googlesource.com/c/1330799
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607850}
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler_state_machine.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler_state_machine.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler_state_machine_unittest.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/scheduler/scheduler_unittest.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/test/fake_proxy.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/test/layer_tree_test.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/test/layer_tree_test.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/layer_tree_host.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/layer_tree_host.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/layer_tree_host_unittest_context.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/proxy.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/proxy_impl.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/proxy_impl.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/proxy_main.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/proxy_main.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/single_thread_proxy.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/cc/trees/single_thread_proxy.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/content/browser/renderer_host/compositor_impl_android.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/content/renderer/gpu/layer_tree_view.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/content/renderer/gpu/layer_tree_view.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/public/platform/web_layer_tree_view.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/renderer/core/exported/web_view_impl.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/renderer/core/exported/web_view_impl.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/renderer/core/frame/document_loading_rendering_test.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/renderer/core/testing/sim/sim_compositor.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/third_party/blink/renderer/core/testing/sim/sim_compositor.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/ui/compositor/compositor.h
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/ui/compositor/compositor_lock.cc
[modify] https://crrev.com/6d3f5ce70242b52d5132cd4a45264ad3d4770540/ui/compositor/compositor_lock.h

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

commit 9cf3636654603d9e453aeb0be73505c2289a55ae
Author: Adrienne Walker <enne@chromium.org>
Date: Thu Nov 15 18:59:33 2018

cc: Rename too long identifier

The linter gets mad at this when anybody changes this file because the
line is too long, but there's no way to format this properly and not
wrap, so just make the test name shorter.

Bug: 805798
Change-Id: I41e052843d721c8c50becdb5425a376503b8889a
Reviewed-on: https://chromium-review.googlesource.com/c/1336558
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608453}
[modify] https://crrev.com/9cf3636654603d9e453aeb0be73505c2289a55ae/cc/trees/layer_tree_host_unittest.cc

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

commit de6e5c8a6ad572fcb4c4a639729422bce0d82799
Author: Stephen Chenney <schenney@chromium.org>
Date: Mon Jan 21 01:56:04 2019

Add a flag for flash avoidance on same-origin navigation

The flag is added in preparation for changes that disable compositor
commits while updating the renderer lifecycle when the renderer navigates
between same-origin pages (i.e. when the renderer process itself survives).

Note that there is a little cleanup in about_flags.cc to move the comment
back to its correct location.

Beyond the flag and feature there is no functionality change here.

Bug: 805798
Change-Id: I2c3a9d502a096f94df46da3c0b1750d781be3acf
Reviewed-on: https://chromium-review.googlesource.com/c/1418650
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624506}
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/chrome/browser/about_flags.cc
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/chrome/browser/flag-metadata.json
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/third_party/blink/common/features.cc
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/third_party/blink/public/common/features.h
[modify] https://crrev.com/de6e5c8a6ad572fcb4c4a639729422bce0d82799/tools/metrics/histograms/enums.xml