Define behavior of <link rel=preload> in detail #7260

noamr · 2021-10-26T09:06:38Z

A document keeps a list of preloaded resources, with a request and
response for each. A preloaded resource is a result of

When consumed (from the FETCH algorithm), the response is reused if the
request matches all relevant parameters, and removed from the store.

When the document is fully loaded ("load" event) the store is cleared.

See whatwg/fetch#590

At least two implementers are interested (and none opposed):
- This is already implemented, specifying after the fact.
Tests are written and can be reviewed and commented upon at:
- Add tests to verify preload caching behavior web-platform-tests/wpt#31539
Implementation bugs are filed:
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1275460
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1743764
- Safari: https://bugs.webkit.org/show_bug.cgi?id=233854

(See WHATWG Working Mode: Changes for more details.)

/infrastructure.html ( diff )
/links.html ( diff )
/semantics.html ( diff )

Before any particular fetch steps are performed, see if there is a matching request already in the preload store and consume it. This is called from the main fetch to avoid race conditions. Depends on whatwg/html#7260

annevk

Thanks for working on this!

One thing I'm unsure about is whether we should have separate preload/image/speculative parse caches or a single cache with more involved lookup semantics. Especially as we also need to deal with their interaction and we probably do not want to clone responses (and read their body) too many times.

source

annevk · 2021-10-27T08:41:49Z

source


  <p>There is no default type for resources given by the <code data-x="rel-preload">preload</code>
  keyword.</p>

+  <p>A <code>Document</code> has a <dfn>list of preloaded resources</dfn> (a list of
+  <span>tuple</span>s, each consisting of a <span data-x="concept-request">request</span> and a
+  <span data-x="concept-response">response</span>), which is initially empty.</p>


I think it would be helpful to spell out the implicit key somewhere as request is a bit larger than what you need, perhaps in a note.

This also doesn't match implementations, for which the key depends on the resource type. E.g., @emilio tells me Firefox currently uses (url, as, cors, origin, {sheet origin, script kind}) as per https://searchfox.org/mozilla-central/source/uriloader/preload/PreloadHashKey.h.

@annevk The script-kind/sheet-origin is different behavior from other browsers. Can you share the thought behind it?

From browsing the gecko code seems like this comes from the fact that the preload key is used for speculative HTML parsing - as currently there is no way to declare that a preload link is e.g. a module vs. classic script.

So I think this shouldn't go in the spec, and maybe this is a minor "bug", causing observable behavior that exposes browser-specific implementation detail.

Fixed xreflist, and fixed to use an explicit set of parameters from the request that are definable in a link rel=preload element

The style origin is needed because we don't want to share stylesheets that are loaded as user agent / user sheets (as those parse differently as if they weren't). This shouldn't be observable for preload's purposes since all <link rel=preload> are effectively author sheets.

@emilio how about script-kind? Doesn't that mean that when preloading scripts they would only be consumable by classic scripts and not by module imports or <script type=module>?

source

noamr · 2021-10-27T10:40:05Z

Thanks for working on this!

One thing I'm unsure about is whether we should have separate preload/image/speculative parse caches or a single cache with more involved lookup semantics. Especially as we also need to deal with their interaction and we probably do not want to clone responses (and read their body) too many times.

I wonder if this is observable behavior? Couldn't think of a desirable scenario where it is. Maybe a non-normative note?

I see the following observable and thus testable boundaries of preload:

preloaded responses should be reused and not cause extra fetches, even in case of errors
preloads should not break cache semantics beyond the first qualifying request

Implementations are free to optimize beyond that as long as it's not observable ...

noamr · 2021-10-27T11:12:25Z

Actually one intricate way where this is currently observable is the onload of the link element. It's unclear when it's supposed to fire if we're using a resource-type-specific cache. For images should it be fired only after the image is decoded? For scripts only after the script is executed? Hence the response cloning, which could be implemented in other more optimized ways of course (but guarantees the observable behavior of the link's load event)
.

yoavweiss

Thanks for working on this!! One comment, and adding a few more folks I'd like to take a look at this.

source

noamr · 2021-10-31T12:59:32Z

Updated a new version, following implementations more closely in terms of integrity and referrer handling, with some informative notes to explain some of the less-obvious decisions.

At the very beginning of the fetch, while still in the main thread, make a call to the HTML spec to see if the active document has a preloaded entry that matches this fetch's request. If such entry exists, we exit the regular fetch process and continue consuming the response once it is available. Together with whatwg/html#7260

noamr · 2021-11-07T12:15:39Z

New revision, together with whatwg/fetch#1342, addresses a lot of the issues after extensive research:

The map key for the preload entry is URL, destination (aka as), CORS mode and credentials mode.
Handling sync XHR etc. is done by having an allow preloads flag on a request, which would be set to false in those cases.
The preload map is populated synchronously when the link element is processed, and evicted synchronously when it matches an actual fetch. This makes explicit what happens when a consumer tries to access a preload entry that it not fully loaded yet.
Integrity matching is done both for the preload and for the consumer - this covers all the corner cases like having matching integrity in both but with different SHA algorithms. User-agents can make further optimizations without changing this observable behavior.
Behavior in case of removing a <link rel=preload element is not handled yet.

Check that preloaded resources are reused/ignored based on the parameters available to a preload link (href, crossorigin, as), and do not rely on other parameters (e.g. whether a script is a module). See whatwg/html#7260 and whatwg/fetch#1342

source

yoavweiss

Non-authoritative LGTM

noamr · 2021-11-20T08:53:39Z

@annevk, @domenic, this is ready for a round of reviews I believe.
It covers the interoperable parts of current preload behavior.

source

A document keeps a list of preloaded resources, each with relevant parameters from the request, and the response once available. Once a <link rel=preload> element starts fetching a resource, that entry is added, and once the response is fully loaded, the fetch consuming the resource receives the response. See whatwg/fetch#590

source

domenic · 2021-11-23T18:41:48Z

source

@@ -14067,6 +14047,40 @@ interface <dfn interface>HTMLLinkElement</dfn> : <span>HTMLElement</span> {
   </li>
  </ol>

+  <p>The steps to <dfn>create a link element request</dfn> given <code>link</code> element


"To create a link element request given a link element el:"

Also, <code> around link

Still should be "To" instead of "The steps to:"

source

domenic

Only one remaining normative thing, about finalizing and reporting timing for error cases.

domenic · 2021-11-24T20:01:47Z

source

@@ -14067,6 +14047,40 @@ interface <dfn interface>HTMLLinkElement</dfn> : <span>HTMLElement</span> {
   </li>
  </ol>

+  <p>The steps to <dfn>create a link element request</dfn> given <code>link</code> element


Still should be "To" instead of "The steps to:"

source

noamr

New revision following comments from @domenic.

source

noamr · 2021-11-25T18:21:14Z

source

@@ -14067,6 +14047,40 @@ interface <dfn interface>HTMLLinkElement</dfn> : <span>HTMLElement</span> {
   </li>
  </ol>

+  <p>The steps to <dfn>create a link element request</dfn> given <code>link</code> element


source

domenic · 2021-11-30T22:00:09Z

I'll merge now, but it looks like web-platform-tests/wpt#31539 does not pass in all browsers. Can you be sure to file bugs on all of them and then edit the OP with links appropriately?

domenic · 2021-11-30T22:06:26Z

Also I noticed

When the document is fully loaded ("load" event) the store is cleared.

in the OP but that behavior doesn't appear to be in the spec. I assume this is because you did testing and found out it wasn't actually desired? If so, did you write tests to confirm?

noamr · 2021-12-01T06:32:54Z

Also I noticed

When the document is fully loaded ("load" event) the store is cleared.

in the OP but that behavior doesn't appear to be in the spec. I assume this is because you did testing and found out it wasn't actually desired? If so, did you write tests to confirm?

Yes, it wasn't desired. I'll update the tests now that the spec is updated.

noamr · 2021-12-01T06:33:04Z

I'll merge now, but it looks like web-platform-tests/wpt#31539 does not pass in all browsers. Can you be sure to file bugs on all of them and then edit the OP with links appropriately?

Absolutely.

Check that preloaded resources are reused/ignored based on the parameters available to a preload link (href, crossorigin, as), and do not rely on other parameters (e.g. whether a script is a module). See whatwg/html#7260 and whatwg/fetch#1342

* Add tests to verify preload caching behavior Check that preloaded resources are reused/ignored based on the parameters available to a preload link (href, crossorigin, as), and do not rely on other parameters (e.g. whether a script is a module). See whatwg/html#7260 and whatwg/fetch#1342 * Add missing font * whitespace * Cleanup * PR nits * PR nits * More nits

annevk · 2021-12-02T09:35:39Z

@noamr if you filed bugs, can you update OP with the links? Thanks!

noamr · 2021-12-02T09:42:18Z

@noamr if you filed bugs, can you update OP with the links? Thanks!

Done

…vior, a=testonly Automatic update from web-platform-tests Add tests to verify preload caching behavior (#31539) * Add tests to verify preload caching behavior Check that preloaded resources are reused/ignored based on the parameters available to a preload link (href, crossorigin, as), and do not rely on other parameters (e.g. whether a script is a module). See whatwg/html#7260 and whatwg/fetch#1342 * Add missing font * whitespace * Cleanup * PR nits * PR nits * More nits -- wpt-commits: ef427f550f2a2a803fb2fa0886951e559fc83d9c wpt-pr: 31539

Before any particular fetch steps are performed, see if there is a matching request already in the preload store and consume it. This is called from the main fetch to avoid race conditions. Depends on whatwg/html#7260, and together they fix #590. Tests: web-platform-tests/wpt#31539.

Before any particular fetch steps are performed, see if there is a matching request already in the preload store and consume it. This is called from the main fetch to avoid race conditions. Depends on whatwg/html#7260, and together they fix whatwg#590. Tests: web-platform-tests/wpt#31539.

domfarolino · 2022-05-18T00:39:15Z

Also I noticed

When the document is fully loaded ("load" event) the store is cleared.

in the OP but that behavior doesn't appear to be in the spec. I assume this is because you did testing and found out it wasn't actually desired? If so, did you write tests to confirm?

Yes, it wasn't desired. I'll update the tests now that the spec is updated.

Can we also perhaps remove this line from the OP? I know that is pretty minor, but when I was perusing this I read that in the OP, and it took scrolling down here to realize that was obsolete.

This was referenced Oct 26, 2021

Integration with preload whatwg/fetch#1342

Merged

Reflect preload information (in ResourceTiming?) w3c/resource-timing#303

Open

noamr changed the title ~~Define storage of preloaded resources~~ Define behavior of <link rel=preload> in detail Oct 26, 2021

noamr mentioned this pull request Oct 26, 2021

Define the "Preload Cache" w3c/preload#97

Closed

annevk reviewed Oct 27, 2021

View reviewed changes

yoavweiss reviewed Oct 27, 2021

View reviewed changes

source Show resolved Hide resolved

noamr mentioned this pull request Oct 27, 2021

Request parameters and preloads w3c/preload#161

Closed

noamr force-pushed the preload branch from 7f098cd to ebed0be Compare October 31, 2021 12:57

noamr force-pushed the preload branch from ebed0be to ef64446 Compare November 7, 2021 12:06

noamr mentioned this pull request Nov 8, 2021

Add tests to verify preload caching behavior web-platform-tests/wpt#31539

Merged

yoavweiss reviewed Nov 8, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

yoavweiss reviewed Nov 9, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

yoavweiss approved these changes Nov 9, 2021

View reviewed changes

domenic reviewed Nov 22, 2021

View reviewed changes

noamr added 6 commits November 23, 2021 19:07

typo

588b646

Revise integrity

4189fb1

Use map

1f46140

Use custom fetch for preload

29a6566

typo

b54b5bb

noamr force-pushed the preload branch from e9844f4 to b54b5bb Compare November 23, 2021 17:09

noamr added 2 commits November 23, 2021 19:10

Null check

b8f0fae

Move request synchronous flag

0785a24

domenic reviewed Nov 23, 2021

View reviewed changes

Revise body extracting + nits

316497d

domenic reviewed Nov 24, 2021

View reviewed changes

domenic mentioned this pull request Nov 24, 2021

Expand on processResponseEndOfBody values whatwg/fetch#1360

Merged

PR nits

58e25df

noamr commented Nov 25, 2021

View reviewed changes

annevk reviewed Nov 29, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

Return request

47ea968

domenic approved these changes Nov 30, 2021

View reviewed changes

Rewrap

08c5c9b

domenic merged commit cfb20f5 into whatwg:main Nov 30, 2021

domenic added the topic: resource hints (inc. preload) label May 4, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define behavior of <link rel=preload> in detail #7260

Define behavior of <link rel=preload> in detail #7260

noamr commented Oct 26, 2021 •

edited

Loading

annevk left a comment

annevk Oct 27, 2021

annevk Oct 27, 2021

noamr Oct 28, 2021

noamr Oct 28, 2021 •

edited

Loading

noamr Oct 28, 2021

emilio Nov 17, 2021

noamr Nov 17, 2021

noamr commented Oct 27, 2021

noamr commented Oct 27, 2021 •

edited

Loading

yoavweiss left a comment

noamr commented Oct 31, 2021

noamr commented Nov 7, 2021

yoavweiss left a comment

noamr commented Nov 20, 2021

domenic Nov 23, 2021

noamr Nov 24, 2021

domenic Nov 24, 2021

noamr Nov 25, 2021

domenic left a comment

domenic Nov 24, 2021

noamr left a comment

noamr Nov 25, 2021

domenic commented Nov 30, 2021

domenic commented Nov 30, 2021

noamr commented Dec 1, 2021

noamr commented Dec 1, 2021

annevk commented Dec 2, 2021

noamr commented Dec 2, 2021

domfarolino commented May 18, 2022

Define behavior of <link rel=preload> in detail #7260

Define behavior of <link rel=preload> in detail #7260

Conversation

noamr commented Oct 26, 2021 • edited Loading

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noamr Oct 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noamr commented Oct 27, 2021

noamr commented Oct 27, 2021 • edited Loading

yoavweiss left a comment

Choose a reason for hiding this comment

noamr commented Oct 31, 2021

noamr commented Nov 7, 2021

yoavweiss left a comment

Choose a reason for hiding this comment

noamr commented Nov 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noamr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Nov 30, 2021

domenic commented Nov 30, 2021

noamr commented Dec 1, 2021

noamr commented Dec 1, 2021

annevk commented Dec 2, 2021

noamr commented Dec 2, 2021

domfarolino commented May 18, 2022

noamr commented Oct 26, 2021 •

edited

Loading

noamr Oct 28, 2021 •

edited

Loading

noamr commented Oct 27, 2021 •

edited

Loading