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

commit b16ccbe3a354e81615ebf805b503a0fae5362492
Author: csharrison <csharrison@chromium.org>
Date: Mon Nov 14 19:48:38 2016

Stop double counting link rel preload preloads for metrics tracking

BUG= 662999 

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

[modify] https://crrev.com/b16ccbe3a354e81615ebf805b503a0fae5362492/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/b16ccbe3a354e81615ebf805b503a0fae5362492/third_party/WebKit/Source/core/fetch/ResourceFetcher.h

Update: the above revision did not help.

Sorry I forgot to link the CL, but r432864 was also related to this effort and actually fixed the problem. Before closing this issue out we should try to understand why it happened.

Shoot, after tracing through the code, I realized that we started marking the preload as referenced by the scanner in r432864. *sigh* let me upload a fix.

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

commit 8b58b651ee02a1ec7edde005e6d8a27cca9bae31
Author: csharrison <csharrison@chromium.org>
Date: Thu Dec 01 17:46:13 2016

Ensure CSS scanner does not mark preloads as referenced

A recent metrics fix (r432864) also mistakenly broke this code by not
passing in a default argument. This CL fixes that problem and adds an
expectation in unit tests.

BUG= 662999 , 596676 

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

[modify] https://crrev.com/8b58b651ee02a1ec7edde005e6d8a27cca9bae31/third_party/WebKit/Source/core/html/parser/CSSPreloadScanner.cpp
[modify] https://crrev.com/8b58b651ee02a1ec7edde005e6d8a27cca9bae31/third_party/WebKit/Source/core/html/parser/CSSPreloadScannerTest.cpp

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

commit 8b58b651ee02a1ec7edde005e6d8a27cca9bae31
Author: csharrison <csharrison@chromium.org>
Date: Thu Dec 01 17:46:13 2016

Ensure CSS scanner does not mark preloads as referenced

A recent metrics fix (r432864) also mistakenly broke this code by not
passing in a default argument. This CL fixes that problem and adds an
expectation in unit tests.

BUG= 662999 , 596676 

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

[modify] https://crrev.com/8b58b651ee02a1ec7edde005e6d8a27cca9bae31/third_party/WebKit/Source/core/html/parser/CSSPreloadScanner.cpp
[modify] https://crrev.com/8b58b651ee02a1ec7edde005e6d8a27cca9bae31/third_party/WebKit/Source/core/html/parser/CSSPreloadScannerTest.cpp

Hey! In investigating  issue 670295  I think I may have figured out a root cause of this.

The problem in  issue 670295  is that in Resource::didRemoveClientOrObserver we unconditionally cancel the request, even if a resource had only "passive" clients (i.e. css preload resource client).

This means it was possible for preloads to be evicted from memory cache before they are matched, but still existing in m_preloads, resulting in a "miss" which is a real miss because we actually evict the resource!

I'll have a patch up momentarily.

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

commit dff0384e2ab5ade040a08a38e72eece575ea0aee
Author: csharrison <csharrison@chromium.org>
Date: Mon Dec 05 16:24:43 2016

Don't remove CSSPreloaderResourceClient for unused speculative markup preloads

The CSS @import scanner attaches a passive resource client to a css
preload request. This passive client should not affect the policy
decisions of the preload and should just observe notifications passively.

This patch fixes a bug where removing a passive client from an otherwise
unused preload ends up cancelling it, which removes the preload from
memory cache. This is very wrong behavior, and causes the optimization
to be less effective, and report bad metrics.

Simply not removing the client will not cause the resource to live
longer than necessary, because the client holds only weak references
to the resource.

BUG= 670295 , 662999 

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

[modify] https://crrev.com/dff0384e2ab5ade040a08a38e72eece575ea0aee/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/dff0384e2ab5ade040a08a38e72eece575ea0aee/third_party/WebKit/Source/core/html/parser/CSSPreloadScanner.cpp

I'm fairly sure #7 fixed the issue for good, but I won't mark as fixed until a Canary is cut and we see at least a day of good data.

Looking at data from 57.0.2944.0 and 57.0.2943.0 it is looking like it's fixed (though a bit noisy).