Do you have more details about that URL bug?

I see that the code is using the url from  page_load_metrics::PageLoadExtraInfo.start_url which should be the url before redirects.

There are no more details---the only evidence of the problem is the existence of the non-none origin with Reference cache type in the prerender experiment.

See the comments on crrev/2776713002 for more details. More confusion, really...

Adding a summary of offline conversations:

In experiments, the prerender control has PrefetchTTFCP counts for non-none origins with "Reference" cache types: ~1/3 of GWS origin counts, a couple percent of OMNIBOX origins. The only way this can happen is when a prerender WebContents has a redirect that changes the start_url, as described in #0.

I've confirmed manually that this situation can occur due to a meta redirect (meta refresh content="0..."). There are probably other similar scenarios.

It's not immediately clear how to reliably track this case correctly for nostate prefetch or simpleload. All client redirects would have to be tracked in the prefetches list, and there are possibly many corner cases to cover.

This situation represents a case where prerender improves user-visible page load performance, nostate is little help (as we don't know about any resources on the redirect target), and we don't have a metric that compares the difference.

crrev/2776713002 would make prerender consistent with nostate & simpleload, but would also just combine this redirect case in orgin NONE reference FCPs, effectively hiding the improvement.

The prerender FCP in this case seem to be quite fast, around 300ms (cacheable main resource) compared to 1200ms for the Warm Cacheable case.

At this point I'm leaning towards not fixing this bug, and keeping the current code path as is; at least this was we can see how big the effect is even if we can't compare it against NoState.

more offline conversations, some highlights:

* the amount of gws_PrefetchTTFCP.Reference looks a bit large to make
  comfortable conclusions

* could happen for 2 reasons:
  1. SERP ->
     client redirect (a few other redirects maybe) ->
     click on a link at the start of the redirect chain
  2. SERP ->
     a few redirects (not necessarily a client redirect present) ->
     somehow going to one of the hops in the redirect chain (except the first)

* we think that (2) is uncommon, tracking it correctly seems not hard

* if client redirects are a big fraction of prefetch traffic, can consider using
  speculative prefetch database or other means to predict redirect target

* let's wait for counts from after removing "wash" and decide afterwards

> With NoStatePrefetch or disabled prerender experiments, this is impossible and all Reference histograms have origin NONE.

I think this is not true, I see a lot of samples in Prerender.wash_PrefetchTTFCP.Reference.Cacheable.Visible for both NoState and SimpleLoad.
Do we have an explanation for these?

Anytime there's an origin NONE that's within 30 seconds of another prefetch, it'll get assigned origin WASH, right?

Indeed!

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

commit fbecc55ae2f4923fd2731391e33af6c37ff7ee2a
Author: pasko <pasko@chromium.org>
Date: Tue Apr 25 07:00:09 2017

Prerender: clarify how FCP works in non-prerendered cases

The only changes are in comments.

BUG= 704911 
TBR=bmcquade@chromium.org

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

[modify] https://crrev.com/fbecc55ae2f4923fd2731391e33af6c37ff7ee2a/chrome/browser/page_load_metrics/observers/no_state_prefetch_page_load_metrics_observer.h
[modify] https://crrev.com/fbecc55ae2f4923fd2731391e33af6c37ff7ee2a/chrome/browser/page_load_metrics/observers/prerender_page_load_metrics_observer.h
[modify] https://crrev.com/fbecc55ae2f4923fd2731391e33af6c37ff7ee2a/chrome/browser/prerender/prerender_manager.h