You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 5, 2022. It is now read-only.
A request has many parameters (see here).
Several of these parameters can cause two requests of the same URL to return a different result (headers, sw-mode, referrer, cors mode, credentials, integrity, redirect mode, cryptographic nonce, ...)
It can get quite hairy to ensure that a preload would have the exact same parameters as the resource request that is going to consume it, as some of those requests are not HTML tags (e.g. fetch, CSS requests) and some depend partly on document-level decisions (like referrer policy).
As an example, a request for a WebFont would include the imported stylesheet URL as the referrer in some user agents, and the server might give a different result for that request vs. a request with a different referrer.
This makes preloads quite brittle. It's often difficult, and in some cases close to impossible, to ensure that a preload element creates a request that would have the exact same parameters as the resource that is destined to consume the preload, resulting in either reuse of responses that came from inaccurate requests or preload cache-misses (the resource is preloaded, but the consumer doesn't use its response due to different parameters). These misses and inaccuracies can also occur upon browser upgrades or subtle spec changes, e.g. if some browser changes how referrers are sent for fonts, some preloads would have to be different on a per-browser basis.
Not sure what the solution for this might be, maybe to bring preload closer to the resource cache and to specify that resource cache better (e.g. allow fonts from the same URL with slightly different request parameters to be reused), or brainstorm more about how to provide this preloading functionality without the brittleness.
The text was updated successfully, but these errors were encountered:
... another option is to make as more detailed, to really declare in the link header what the resource is going to be used for rather than how it should be fetched
A request has many parameters (see here).
Several of these parameters can cause two requests of the same URL to return a different result (headers, sw-mode, referrer, cors mode, credentials, integrity, redirect mode, cryptographic nonce, ...)
It can get quite hairy to ensure that a preload would have the exact same parameters as the resource request that is going to consume it, as some of those requests are not HTML tags (e.g. fetch, CSS requests) and some depend partly on document-level decisions (like referrer policy).
As an example, a request for a WebFont would include the imported stylesheet URL as the referrer in some user agents, and the server might give a different result for that request vs. a request with a different referrer.
This makes preloads quite brittle. It's often difficult, and in some cases close to impossible, to ensure that a preload element creates a request that would have the exact same parameters as the resource that is destined to consume the preload, resulting in either reuse of responses that came from inaccurate requests or preload cache-misses (the resource is preloaded, but the consumer doesn't use its response due to different parameters). These misses and inaccuracies can also occur upon browser upgrades or subtle spec changes, e.g. if some browser changes how referrers are sent for fonts, some preloads would have to be different on a per-browser basis.
Not sure what the solution for this might be, maybe to bring preload closer to the resource cache and to specify that resource cache better (e.g. allow fonts from the same URL with slightly different request parameters to be reused), or brainstorm more about how to provide this preloading functionality without the brittleness.
The text was updated successfully, but these errors were encountered: