A related (but probably not blocking) issue filed:
  crbug.com/717260 Page Cycler V2: one of the test case records data for both runs of the cache-warm case.

At the moment, timeToOnLoad is roughly on par with the existing code (control group).

Two tests have significantly bigger timeToFirstMeaningfulPaint:
 http://www.nationalgeographic.com/ (658.887 v.s. 311.146)
 http://www.flickr.com/... (790.523 v.s. 106.146)


It turned out people have already seen this issue with nationalgeographic when LoadingWithMojo was enabled, and investigation showed that it was false-positive.

Please see: https://docs.google.com/document/d/1wissv31WUjeHaSaf78uAH0FiFQfSU6sqv14Lcuo1toA/edit#

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

commit fa5e572013e1c46993b8e79da9e55b58a0f2c86e
Author: yzshen <yzshen@chromium.org>
Date: Tue May 02 21:24:13 2017

Network service: avoid requesting a new URLLoaderFactory for each NavigationURLLoaderNetworkService.

Eventually we will need the ability to customize URL factory per frame, for things like appcache or service worker. But by default we could use a global URL factory.

BUG= 717689 

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

[modify] https://crrev.com/fa5e572013e1c46993b8e79da9e55b58a0f2c86e/content/browser/loader/navigation_url_loader_network_service.cc
[modify] https://crrev.com/fa5e572013e1c46993b8e79da9e55b58a0f2c86e/content/browser/loader/navigation_url_loader_network_service.h
[modify] https://crrev.com/fa5e572013e1c46993b8e79da9e55b58a0f2c86e/content/browser/site_per_process_browsertest.cc

Apologies, applied the wrong component in bulk.