This repository has been archived by the owner on May 5, 2022. It is now read-only.
Define the "Preload Cache" #97
Assignees
Labels
Comments
This was referenced May 31, 2017
|
Note: address discussion in #85 when we tackle this. |
|
+1. My intuition is this belongs in Fetch and I'd be curious how closely we could get a preload cache matching HTTP cache semantics. The double download possibilities in some browsers would otherwise be unfortunate. Do we have a Fetch issue to cross-reference? |
|
Opened whatwg/fetch#590 on Fetch. I'm not sure there's any immediate action on the preload spec, so closing this issue here. Let me know if you disagree. |
|
I don't think you should close this until it's actually fixed on the Fetch side. This specification is the cause. |
|
Fair enough. Reopening |
|
Discussed at TPAC 2018:
|
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Feb 1, 2019
Audio and video element requests typically involve custom headers and range requests that are more complicated and nuanced than other resource requests. As a result, despite potentially being preloaded, audio/video resources do not typically hit the preload cache. In order to rectify this issue the Fetch spec needs to specify how the preload/media cache should behave and implementors need to adopt this behaviour. This is tracked here: w3c/preload#97 While the preload spec does describe preloading media resources (as=audio/video), and the current behaviour does match the spec, the behaviour is misleading for developers given that indications are the resource is preloaded and yet the video element typically will re-fetch the resource. This can cause unintended behaviour and potentially even double downloads. In order to mitigate the current cache behaviour and send a clear signal to developers about how their page will behave the current thought is to remove the audio and video "as" declarations from the preload implementation until the Fetch spec issue is resolved. This change removes the audio/video ResourceTypes as a valid preload types. In addition the upstream W3C preload tests have had exceptions added to specify the newly expected behaviour. As this is likely to revert in the future and not result in a preload spec change the original tests have been left as-is. A new test has also been added to the web_tests preload test suite to validate that audio/video types are indeed not preloaded. Intent to Temporarily Remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QnwPuiiYuQE Bug: 735014 Change-Id: I82ad3200d486ce531795dd42f89e6683087047a2 Reviewed-on: https://chromium-review.googlesource.com/c/1440522 Commit-Queue: Brandon Maslen <[email protected]> Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Yutaka Hirano <[email protected]> Cr-Commit-Position: refs/heads/master@{#628250}
|
Closing as the preload cache is now defined. Feel free to reopen if I've missed something |
|
Yay!! \o/ |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We need to define the preload cache, as currently it is not defined and different implementations are doing observably different things.
I think the best place to define such a cache is in Fetch, but as this spec would be its main consumer, thought we should a) discuss it b) track it on this side as well
The text was updated successfully, but these errors were encountered: