Do we mind evading memory cache here and just populating http cache? If so we could probably do this with semantics similar to link rel prefetch.

Otherwise we could probably at least *not* wait for AppCache! This is a trivial improvement that could be done today. See https://codereview.chromium.org/2165653004 for a first pass at this simple step.

the provisional load commits when the first byte is received. if we only fire preloads after the first chunk is parsed, something else is wrong

Preloads wait until the first chunk is tokenized (not parsed) in order to support `media` attribute based preloading. (meta viewport is detected and applied before preloads happen)

We could easily start preloading non-media preload headers right after the commit.

May throw up a more complete patch here...

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

commit 7eacc60e1556444061f9f84bac4d82c34419a2ae
Author: csharrison <csharrison@chromium.org>
Date: Fri Jul 22 19:15:58 2016

Don't wait for AppCache for link rel preloads

The preload scanner currently waits for the Application Cache to be
initialized before sending out any preloads. This is less important for link
rel preloads, which are directives to send a fetch as soon as possible.

This patch bypasses the fetch queuing for these preloads.

For link preloads in headers, we can issue these as early as the commit
point (for those which don't have a media attribute).

BUG= 629420 

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

[add] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/LayoutTests/http/tests/preload/link_header_preload_on_commit.php
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/html/parser/HTMLDocumentParser.cpp
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/html/parser/PreloadRequest.h
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/DocumentLoader.h
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/LinkLoader.cpp
[modify] https://crrev.com/7eacc60e1556444061f9f84bac4d82c34419a2ae/third_party/WebKit/Source/core/loader/LinkLoader.h

Let's mark this as fixed. I believe we can't get any better here without doing things in the browser process. After this patch:
 1. link rel preloads dont wait for appcache
 2. link rel preload headers only wait until commit
 3. link rel preload headers with media attributes are preloaded after the first bytes are tokenized

I'll open up another issue exploring if resource loads in general should go through app cache.