Async css

[andershol]

Allow css files to be marked as async meaning that they will not block rendering. The syntax could be a new attribute on the link element or a new value for "rel" attribute (that already have link types such as "dns-prefetch", "preconnect", "prefetch", and "preload" that also seems to serve a technical, how-to-load purpose), say "<link rel='stylesheet async' type='text/css' href='theme.css'>".

This functionality is similar to the async attribute on the script element, and the font-display descriptor for the @font-face CSS at-rule.

A web search will find quite a few articles about how to do this in a more or less hackish way, so there seems to be a demand for it. It seems that the browsers could rather easily add this in a much more reliable way as the browser e.g. knows if the resource is already in the cache and can control the priority of requests.

(I did read the contributing guidelines, but as I read them, they only talk about submitting pull requests and not about submitting issues)

[sashafirsov]

While the JS-based packaging does not have an issue with loading CSS on demand of JS module( lazy or in run time), IMO having coherent phased load behavior over all resources including script, images, fonts, css, etc has sense to be unified and be a part of HTML standard. So I would extend this feature request to "unify the load behavior for web page resources" instead of just CSS lazy load.

Also current separation of synchronous/async/delayed behavior does not reflect the need for modern web app. In complex apps the order of load is phased and each phase accounts dependency graph. Extending loading parameters with "depend on" and "load order" is a good addition to proposal.

All seems to be easy polyfilled for backward compatibility.

[andershol]

There are two related but orthogonal issues here:

1. What should the browser do before a resource is downloaded? For fonts this might be wait for the font to download before showing anything, show invisible text, or show a fallback font some of which can be selected by font-display (note it does not seem to be possible using font-display to opt-out of the initial wait), for scripts it might be to wait for the script to load before proceeding or just to execute it when it is loaded, for images there is "lowsrc" and one might imagine an option to select how the image should animate on to the image when it is loaded. In short, it depends on the resource type what possibilities it makes sense to choose between.
2. What priority should the resource have in the load order? This could tie in with the priority and dependency system that both http2 (section 5.3) and quic (section 3.2) seems to already have. It would probably make sense to give page authors a way to indicate a desired load-order instead of relying on the browsers heuristic.

As an example of why they are orthogonal, consider that it currently seems, that marking a script "async" will give it the lowest priority. But even though a script might not be needed for the first render, it might be desirable to have it load before, say, large decorative images on the page.

This issue is about (1) for the stylesheet resource type.

[noamr]

Perhaps we can add a semantic that <link rel=stylesheet blocking="none"> would make parser-inserted scripts not render-blocking by default

[LeaVerou]

Maybe we can revive this issue?

Async CSS is pretty essential. It's the reason libraries like Font Awesome have to resort to <script> for their embed code.
Tons of questions online about CSS async loading, all resorting to JS in one way or another, with the prevailing solution being this:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

[scottjehl]

I still frequently find reasons for loading CSS asynchronously in my work. As @LeaVerou mentioned, the "print media hack" is commonly referenced as a workaround, but its reliance on JavaScript to apply CSS is a major downside.

The addition of an async attribute for the link element would allow developers to load CSS in a non-render blocking manner without relying on JavaScript. By default, I think this should cause a stylesheet to load at a low fetch priority, but the already standard fetch-priority attribute gives us control to change that when desired.

I'd love to volunteer my time to consult on specification or implementation work if that's helpful in any way. Thank you!

[rajsite]

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

The addition of an async attribute for the link element would allow developers to load CSS in a non-render blocking manner without relying on JavaScript.

CSP settings avoiding inline JS also complicate this common workaround. Another win for a native implementation.

[noamr]

I'm happy to submit a proposal for blocking=none as per #3983 (comment), but one q:

Why has putting those link tags at the beginning body not become a practice for this? It seems simple enough and potentially solves the problem. Is that a matter of popularizing it via DevRel/education? Or is it a material issue with this alternative?

[scottjehl]

@noamr I like how that sounds but I think async feels more intuitive.

As for the question of in-body links, my understanding is they are sync and block rendering for HTML that follows them. Useful for different contexts but not the same. [update: browser behavior varies a lot here!]

[noamr]

@noamr I like how that sounds but I think an attribute that's already in use would be much more intuitive (async).

blocking is also already in use, you use if to put blocking=render on scripts, or on dynamically inserted link elements.
But currently it can only be used to add render-blocking and not remove it.

As for the question of in-body links, my understanding is they are sync and block rendering for HTML that follows them. Useful for different contexts but not the same.

That's incorrect AFAICT. <link> elements inside the body are always async as per spec and don't have the script-like semantics of blocking parsing.

We should be clear here with the use of the word sync - fetching of external resources can either block parsing or block rendering.

• Only classic scripts block parsing.
• Only elements in the head can block rendering (script, link).

So the following should just work:

<head>
   <title>...</title>
  <link rel=stylesheet href="blocking.css">
  <!-- stuff -->
</head>
<body>
  <link rel=stylesheet href="non-blocking.css">
  <!-- stuff -->
</body>

[bramus]

That's incorrect AFAICT. <link> elements inside the body are always async as per spec and don't have the script-like semantics of blocking parsing.

These too are blocking. See https://codepen.io/bramus/pen/NPKYWrX/23a03a80e29b92fa80a41701959d1dba for a demo.

UPDATE: In Chrome and Safari. Not in Firefox.

[noamr]

That's incorrect AFAICT. <link> elements inside the body are always async as per spec and don't have the script-like semantics of blocking parsing.

These too are blocking. See https://codepen.io/bramus/pen/NPKYWrX/23a03a80e29b92fa80a41701959d1dba for a demo.

UPDATE: In Chrome and Safari. Not in Firefox.

Yea I believe this is not per spec. It's a browser heuristic, not sure I like it :)
Thanks for the clarification @bramus, I got this wrong indeed and was looking too much at the spec.

[rik]

Yeah, browsers all behave differently. 8 years ago, Jake wrote about it.