Behavior of blocking attribute on a preload link

[noamr]

According to the spec, a <link rel=preload blocking=render /> would block rendering until the resource is fetched.
This behavior seems a bit off, or in other words I have doubts about it.

If taken as specified, this could lead to a FOUC - as the time between the response arrives and the font is loaded / style is parsed / script is executed is not render-blocked.

It can create strange situations, e.g. with <link rel=preload render=blocking as=script /> and a corresponding <script> without a blocking keyword. Should it or should it not block? Should it block while fetching the preload but not while executing the script? If it blocks until the script is executed, what if it's not executed at all?

OTOH, when evaluating scripts/styles, their subresources (imported scripts/styles) are already implicitly render-blocking. So re-defining them as render-blocking in the preload is redundant.

I suggest that preloads should not be render-blocking at all, and instead to allow render-blocking on particular type of resources that cannot currently do that, like fonts. Maybe:

@font-face {
  font-family: "Some external font";
  blocking: render;
}

This would also make the render-blocking part of the style's content, rather than an external side-effect of one of its headers, which would require web developers to juggle between CSS authoring and backend configuration of HTTP headers.

If we want this to affect the fetch priority, it could be something like:

<link rel=preload as=script href=script.js fetchpriority="render-blocking" />
<script blocking=render src="script.js">

Specify the blocking for the preload as a priority, but not block the rendering indefinitely if the resource is loaded but not used.

WDYT? @xiaochengh @yoavweiss

[xiaochengh]

If taken as specified, this could lead to a FOUC - as the time between the response arrives and the font is loaded / style is parsed / script is executed is not render-blocked.

For font, I don't fully understand this. What's the different between "the response arrives" and "the font is loaded"?

For style / script, this is not true if it's in the document head, because the document is always render-blocked before body is inserted (and can be blocked for longer after that). And if it's in the document body, then it's pretty much the same as having an inline style / script in the document body -- a flash/shift/... should be expected.

I agree that it may seem a bit redundant to use it on style/script resources. But I don't see a reason why we should ban them. Render-blocking preloads are mostly motivated by resources that are by default non-render-blocking.

I've also proposed adding render-blocking a @font-face before (w3c/csswg-drafts#5924) and it was discouraged, while an explicitly preload seems more desireable (@tabatkins)

... but not block the rendering indefinitely if the resource is loaded but not used.

This won't happen. For preloads, rendering is unblocked when the resource is loaded, not when it's used.

[noamr]

If taken as specified, this could lead to a FOUC - as the time between the response arrives and the font is loaded / style is parsed / script is executed is not render-blocked.

For font, I don't fully understand this. What's the different between "the response arrives" and "the font is loaded"?

The time where the response is processed and turned into an actual font can happen after the response arrived, not necessarily synchronously.

For style / script, this is not true if it's in the document head, because the document is always render-blocked before body is inserted (and can be blocked for longer after that). And if it's in the document body, then it's pretty much the same as having an inline style / script in the document body -- a flash/shift/... should be expected.

OK, but in this case, how did render-blocking the preload helped? It had no effect... if the script is anyway render-blocking it remains render-blocking and vice versa. The only thing the blocking-preload would do is shift the FOUC around to a different point in time, potentially shorter.

I agree that it may seem a bit redundant to use it on style/script resources. But I don't see a reason why we should ban them. Render-blocking preloads are mostly motivated by resources that are by default non-render-blocking.

I've also proposed adding render-blocking a @font-face before (w3c/csswg-drafts#5924) and it was discouraged, while an explicitly preload seems more desireable (@tabatkins)

I'll read and comment on that one, thanks for the pointer.
I believe that render-blocking as a network-layer feature is a strange decision and can lead to those gaps between fetching and rendering where the developer would think that there should be a render-block but the behavior would be not so explicit.

... but not block the rendering indefinitely if the resource is loaded but not used.

This won't happen. For preloads, rendering is unblocked when the resource is loaded, not when it's used.

Right, hence there would be a potential FOUC gap.
If the resource is used early - it should state it is render blocking and preload doesn't add any new information. (Provided styles/fonts/images/scripts can provide that information)

If the resource is used late - and you unblock on response -
the time between the response and the consumption is a FOUC gap.

The logic here is that rendering is not a direct result of the loading chain, but rather an effect that may happen later, potentially asynchronously. So tying something render-related to the fetching process is racy.

[xiaochengh]

Thanks for finding out this issue.

I've discussed this issue within the Chrome team, and we agreed that render-blocking preload is a problematic idea. We've decided to:

• Remove blocking=render from <link rel=preload>
• Keep blocking=render as is on <script>, <style> and <link rel=stylesheet>
• Propose something in CSS to turn a web font render-blocking
• Propose a general JS API to block & unblock rendering, so that we can support e.g. images (which typically appear in body and hence shouldn't have blocking=render)

Question: How about <link rel=modulepreload>? It doesn't seem to have issues pointed out here, so I think we also keep it as is?

[noamr]

Thanks for finding out this issue.

I've discussed this issue within the Chrome team, and we agreed that render-blocking preload is a problematic idea. We've decided to:

• Remove blocking=render from <link rel=preload>
• Keep blocking=render as is on <script>, <style> and <link rel=stylesheet>
• Propose something in CSS to turn a web font render-blocking
• Propose a general JS API to block & unblock rendering, so that we can support e.g. images (which typically appear in body and hence shouldn't have blocking=render)

I think those are good moves! Thank you.

Question: How about <link rel=modulepreload>? It doesn't seem to have issues pointed out here, so I think we also keep it as is?

I think it has the same issues as <link rel=preload as=script>. There could be a gap after preloading the module and depednencies, and before the module is imported and evaluated.

[xiaochengh]

Is there any procedure needed to remove blocking=render from preloads? Or do I just upload a PR?

cc @domenic

[noamr]

Is there any procedure needed to remove blocking=render from preloads? Or do I just upload a PR?

cc @domenic

Mainly upload an HTML PR and make sure the WPTs are up to date.

[bakura10]

Hi,

I would like to re-open this, as I think render blocking on preload can be useful. When using declarative shadow DOM, loading a stylesheet currently have two different behaviors:

• It is blocking on Chrome
• It is non-blocking on Safari

I'm waiting to check Firefox implementation. I have raised this issue here: #9232 and it seems that Chrome might be the incorrect implementation.

I would prefer for stylesheet to be blocking, as otherwise the following will cause FOUC, which in my opinion defeat the purpose of declarative shadow DOM:

<template shadowrootmode="open">
  <link rel="stylesheet" href="stylesheet.css">
</template>

If the spec is clarified and Safari behavior is adopted, this means we need to have a way to block the rendering in this context, so we would need to have this and this to be blocking:

<link rel="preload" render="blocking" href="stylesheet.css" as="stylesheet">

<template shadowrootmode="open">
  <link rel="stylesheet" href="stylesheet.css">
</template>

In this context we cannot remove the preload as otherwise the styles would leak into the main document and no longer be scoped to the Shadow DOM (while the preload allows to ensure it is just downloaded but not executed).

Honestly, I would prefer the declarative shadow dom spec to be clarified and be blocking, but I wanted to raise this use case as I feel it is an important one.