Is the main use case here iframes? That one would be easier, but getting both iframes and HTML imports at the same destination would be trickier (as I believe imports are limited on script-src CSP directives, unlike child-src for iframes).

The spec mentions iframe and frame: https://www.w3.org/TR/preload/

There doesn't seem to be a mention of HTML imports support on preload.

Yeah, as HTML imports seem to be contentious, and are not included in Fetch.

I'll start by adding support for iframes then.

Seeing this on a couple of properties that preload imports. chromestatus.com for example.

Deleted: Screen Shot 2016-05-02 at 3.34.13 PM.png 272 KB

	Screen Shot 2016-05-02 at 3.34.13 PM.png 272 KB View Download

Deleted: Screen Shot 2016-05-02 at 3.34.16 PM.png 421 KB

	Screen Shot 2016-05-02 at 3.34.16 PM.png 421 KB View Download

Yoav, whats the current status here? I think this probably blocks preloading iframes too, which I'm interesting in experimenting with.

I have a patch up on https://codereview.chromium.org/1987413002/ but it risks loading iframes twice.

Something like https://codereview.chromium.org/2219663005/#msg9 would be required first, at least for `document`. If droger@ is not planning to work on it, I could take a stab at it.

SGTM. That will also be useful for the PreloadScanner.Counts.Miss metrics that are slightly broken with link preloads.

I filed  bug 638155  for this.

I was planning to take a look at it this week, but feel free to steal it.

As said in the other bug, I believe that what I need to change is LinkPrefetch, not LinkPreload.

this would be really helpful for Polymer-based Chrome UIs (i.e. settings, downloads, history).

OK looks like this wasn't a good fit for droger who needs link prefetch (not preload). 

Yoav, do you have time to throw up a variant of that idea (i.e. swap LinkRelPreload type with a flag). Otherwise I may be able to do that.  

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

commit a5a314d3249ecf1c291b417fbe067e8c2a65fad2
Author: yoav <yoav@yoav.ws>
Date: Sun Aug 21 10:24:24 2016

Remove LinkPreload resource type

This is a refactoring CL, removing the LinkPreload resource type,
as it is not really necessary.
It also matches the priority of <link rel=preload> with no `as` attribute
to regular raw resource types (e.g. XHR).

BUG=593267

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

[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/fetch/Resource.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/fetch/Resource.h
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/loader/LinkLoader.cpp
[modify] https://crrev.com/a5a314d3249ecf1c291b417fbe067e8c2a65fad2/third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp

Talking to csharrison@ about this, this seems like a footgun until we resolve iframe prioritization in general. Currently iframes are downloaded at Very High priority, so preloading them has a good change of them contending for bandwidth with more critical resources.

Check out this link https://fetch.spec.whatwg.org/#concept-request-destination

 Issue 657833  has been merged into this issue.

Due to #18, I'm not planning to work on this in the near future, at least until we'll resolve iframe prioritization.

I don't think we are talking about <iframe> here?

We are taking about

<link rel=preload as=document href=LINK_TO_A_DOC>

because these works:
<link rel=preload as=image href=LINK_TO_A_DOC>
<link rel=preload as=script href=LINK_TO_A_DOC>
<link rel=preload as=style href=LINK_TO_A_DOC>

I don't see a reason why as=document won't work. This is needed to preload html resources for things like web components

#23 - If you want to prefetch the HTML of the next navigation (because you *know* where your users are going next with high certainty), `<link rel=prefetch>` is the right tool for the job. (likely to not contend with current content on the page, can survive navigations and can live in cache for a short period, even if non-cacheable)

#24 this is about specifying html downloads for the current page ahead of script execution.

Can you please provide a concrete example of what you're trying to achieve? It's not clear if you're interested in preloading iframes, HTML imports, follow up HTML top navigation documents or something else altogether.

#26 Loading dynamic html content for the current page, especially for serverless static hosting.

I'm afraid I still don't understand how you're planning to use said preloaded content. Can you maybe include a code example and a description of what you're trying to achieve?

Here is an example:

<head>
 <link href="main.html" rel="preload" as="document">
 <script src="main.js"></script>
</head>

main.js:

fetch(document.querySelector("link").href).then(async function(response) {
 document.body.innerHTML += await(response.text())
})

According to the spec, you need to load that with an empty `as` value (which may soon change to a "fetch" `as` value. See https://github.com/whatwg/fetch/pull/442#issuecomment-268846601).
Your use case is also blocked on fetch() working with preload. See https://bugs.chromium.org/p/chromium/issues/detail?id=652228

Is there an update on the status of this? slightlyoff@ and I were discussing the topic earlier today.

We have 2 use cases that would require this for now:
- sometimes we know that an iframe will download another iframe (sigh), and we'd like to make that the second request while making the first request
- AMP has a (dozens of bytes) ad sandbox iframe. We want to download that as early as possible, while we only include the iframe itself (and run JS in it) when it is likely to enter the viewport.

I see that often people think of preload as a helper for the preload scanner, but the case of "eager preload and lazy JS execution" is equally important for the health of the web with third party JS.

+pmeenan, kouhei

I agree there are use cases for this feature.

Due to OOPIF / frame isolation we probably won't put main resources in memory cache, so a solution to as=document would look very similar to prefetch without some of its complexities (e.g. detachable loading).

Yoav /Kouhei, has there been progress on a priority annotation for the web platform? I wonder if that sort of thing could help here.

To clarify csharrison@'s point, at current prioritization scheme, there is concern that iframe preloading would end up delaying the downloading of resources for the current page, which are arguably more important in the general case. I had a CL up that implemented this, but never landed due to regression concerns: https://codereview.chromium.org/1987413002/

An explicit priority API (which I don't think we made much progress on, but should) would allow the developer (or AMP) to specify each resource's priority, and work around that concern.

Have you tried using `<link rel=prefetch>` to satisfy those use cases? That might be an easier avenue for support of your use-cases.
Another, for the "dozen of bytes iframe", might be srcdoc and inlining of that data.

Unfortunately we are seeing double-downloads with prefetch. See http://output.jsbin.com/joqores/quiet

Also, we'd like to use this for non-cacheable resources like a youtube or instagram embed iframe.

Would hate to ask what the status of this is. However there is great reason to have this feature. Sending the current Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Or (at minimum) Accept: text/html, */*;q=0.8
Would be awesome. There is currently no way to differentiate as=script and as=fetch as they both send Accept: */* to the server.

I do realize this may not be the appropriate place to raise this discussion. Please point me in the right direction if this is the case.

Thanks in advance!

- Snuggs

Looking to start using the <link href="/uri/to/iframe.html" rel="preload" as="document">
to preload an <iframe>. When would this feature be released?

Preloading iframes (e.g. with Videos), could be useful, as described above. Are there any plans on supporting preload with as=document anytime soon? Shouldn't the <link rel="preload" href="..." as="document"> be ignored, instead of triggering the warning in the console?

Also "manifest" is reported as an invalid value:
<link rel="preload" href="http://example.com/app.webmanifest" type="application/manifest+json" as="manifest">

"manifest" as a request destination is defined in: https://fetch.spec.whatwg.org/#concept-request-destination

#38 - "manifest" is indeed a request destination and support would be simpler and less of a footgun than "document" support. (even if I'm not sure I understand the use-case for it - does the browser need the manifest download to finish before showing the "install" prompt?)

In any case, I think it'd be better to not lump those issues together and open a separate issue for "manifest" support

#39

My reasoning is that when link rel="manifest" is used, the browser makes a request for the manifest file so why not preload it knowing it'll be used?

However, I'm uncertain there are any real world benefits doing so. I wont open an issue on this. If there's a need for chrome to conform to the spec in this matter I suppose others will make noise :P 

Thank you for your response Yoav. 

The link in c.38 also states that "worker" is a valid request destination, but I get the same console error about needing a "valid" as-value.  Does this ticket cover all missing as-values, or should a new ticket be opened to cover supporting an as-value of "worker"?

This is useful in general for any type of advertisement in iframes (not that people love ads, but hey if we're gonna load them - why not do it faster?).

#33 

Priority Hints have come a long way (https://github.com/WICG/priority-hints/issues).

This would also be very useful for https://github.com/wicg/portals