-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define <link rel=prefetch> #5229
Comments
I'm a bit confused why you are reporting this here. This is the repository for the standard, not the validator. Shouldn't you be reporting this on the validator repository? |
I did but they recommended to log an issue here. |
I see. Yes, it appears this comes from the Resource Hints spec not properly integrating with HTML. @domfarolino has had plans to help with that integration eventually. |
I'll own this for now |
as
attribute
@domfarolino I want to start integrating prefetch into the HTML spec and saw this comment from 2 years ago... are there still any current efforts around this? |
Looking at the different ways prefetched is described at MDN, the Resource hints spec, current WPT support and what implementations do, things are far from being interoperable or tested. prefetch is described as something that happens "when the browser is idle" which is not well defined, and also described as something that the user-agent can initiate. It also has some undefined important pieces, such as iframes. We need to define to some extent:
In broad strokes - prefetch is meant for subsequent navigation which makes it priority lower (fetch at least after document load event) and its scope broader (at least for the subsequent navigation?). |
I think https://wicg.github.io/nav-speculation/prefetch.html, by @jeremyroman, are the current efforts around this? |
Yes I also came across this, and it seems to do a lot more than what |
I'm not sure. My impression is that it is more complex because it attempts to be privacy-preserving cross-origin (by using partitions and allowing the anonymous-client-ip suggestion). Whereas currently all browsers have turned off cross-origin prefetch due to privacy concerns. The same-origin prefetch spec there seems just the right amount of complex? I might be wrong on that though, so @jeremyroman is probably best placed to clarify. |
Either way, I'd be happy to help migrate whichever parts of prefetch into HTML. |
After some internal conversations with the Chrome team, I'm going to submit a PR for prefetch with a simple algorithm: |
Prefetch is simply a fetch with `prefetch-src` CSP and no post-processing of the resource. Closes whatwg#5229
Some quick notes from various twitter threads with devs using it, specifically for the case where no-cache prefetches are available for one-time-use from a memory cache (and it isn't just a priority setting backed by the normal disk cache):
|
Note that when prefetching we also send a
How about sending a
Does sending a short max-age only when the prefetch header is available address this? |
I don't know how web-interoperable including both max-age and no-cache on the same cache-control is. All of this is assuming a non-cacheable resource (for the disk cache) and a resource that can only be used once. If that part of Chrome's implementation is going to go away and it is going to behave like a normal cache resource then none of this is needed (but prefetching HTML also won't work in a lot of cases). stale-while-revalidate also assumes multiple uses of the response and would populate the disk cache (and presumably there is no "real" response if the request can be satisfied from the prefetched response). |
OK, so I think I understand the alternative proposed here. Something like: A prefetched resource (without Am I getting this right? |
@pmeenan: seems like the main use-case for prefetch with If that's so, I think trying to solve this here has been done before and led to the current effort on nav-speculation. In a world where nav-speculation is mature, the place where prefetch "shines" is in early fetch of subsequent subresources (mainly styles & scripts). And for that case, fine-tuning for |
Yeah, if we're delegating the document case (including same-origin) to nav-speculation then I'm totally in favor if getting rid of the current heuristics entirely and just treating it as an idle-time preload into the regular cache (without the "must" that comes with preload). |
That's the idea. The main issue with the current semantics is that it breaks partitioning rules. |
re. re. Finally if we do intend for |
Currently chrome does something internal with
Note that this behavior is Chrome-only, so those sites and libraries cannot rely on this for other browsers. |
Prefetch is simply a fetch with `prefetch-src` CSP and no post-processing of the resource. Closes whatwg#5229
Prefetch is simply a fetch with `prefetch-src` CSP and no post-processing of the resource. Closes whatwg#5229
Prefetch is simply a fetch with `prefetch-src` CSP and no post-processing of the resource. Closes whatwg#5229
Prefetch is simply a fetch, which populates the HTTP cache, with no post-processing of the resource and with a special header Sec-Purpose: prefetch. (The latter is specified in whatwg/fetch#1576.) Closes #5229. Closes w3c/resource-hints#86. Closes w3c/resource-hints#74. Closes whatwg/fetch#1008.
Bug report
Describe the bug
W3 validator reports error for the following tag,
<link href="/css/0919b1814a0e43ed7c9049ed6289f912a857a8b8a.cbb3cd6b.chunk.css" rel="prefetch" as="style">
↩To Reproduce
Go to https://validator.w3.org/#validate_by_input and paste the following code.
You will start seeing the errors like
Expected behavior
There should be no error. As per W3.org
as
is permitted inrel="prefetch"
.https://www.w3.org/TR/resource-hints/#prefetch
Screenshot attached,
![image](https://user-images.githubusercontent.com/10018448/72895891-7d734c00-3d44-11ea-88dd-2d557cb07b9b.png)
The text was updated successfully, but these errors were encountered: