+lof84@ who authored r395413 (adding CreateParams::initialize_renderer field)
+lizeb@ who authored r400147 (adding WebContentsFactory::createWebContentsWithWarmRenderer method)

Hi,

When is the speculative RenderFrameHost created? Is it at navigation time, or earlier?
If this is the former, then it probably still makes sense to keep the method, as it's used in Custom Tabs even before any navigation starts.

The speculative RenderFrameHost is created at navigation time.

But... let me step back a little bit.  IMHO the renderer startup can be broken down into the following stages/steps:
1. no renderer process
2. empty renderer process spawned
3. renderer process spawned and RenderView/RenderFrame created within the process

If Custom Tabs and other Android scenarios mostly care about 1->2 latency, then this latency can be reduced by prewarming a spare RenderProcessHost (see RenderProcessHost::WarmupSpareRenderProcessHost) which will guarantee that the next WebContents created will be associated with an already spawned, empty renderer process (although there will be no RenderView nor RenderFrame inside the process).  If this is sufficient then it might be okay to leave the 2->3 latency to be taken care of during a navigation (via speculative RenderFrameHost).

I might be late to the party, but... Given that this flag is still useful, and taking into account that its implementation is quite small and non-intrusive, does it really make sense to remove it? Its benefit can be visible on slow devices when the network is fast.

While I agree with lukasza@ that most of the startup cost can be saved using RenderProcessHost::WarmupSpareRenderProcessHost, I'm also not sure we need to be in a rush to remove CreateParams::initialize_renderer.  For one thing, WarmupSpareRenderProcessHost wouldn't bind that spare process to the WebContents in question, so any other navigation in the meantime could grab the spare process and require the WebContents in question to create a process from scratch during its eventual navigation.

As such, I'm inclined to leave initialize_renderer around, unless there's a reason it's causing other problems.  I'll set a reminder for lukasza@ to weigh in when he gets back, since I don't think anyone else will pick this up in the meantime.

The NextAction date has arrived: 2018-07-25