Resources imported via <link rel=import> are not parser blocking, but are typically render blocking. Render blocking but not parser blocking is the right default behavior, as the primary use case for <link rel=import> is to load content (e.g. custom elements) needed to render that document.

However, a web developer may wish to load an import without blocking rendering. Use cases:
* developer wishes to prefetch a custom element that is not needed to render the initial view, but which will be needed once the user interacts with the web app. developer would like the resource to be loaded and processed once it is available, but does not want rendering of the page to block on the load of that component.
* developer uses a web component that can be sufficiently styled before being upgraded using :unresolved, and thus it is not necessary to block rendering on that component. This only works well for components whose size is known before their custom element has finished loading; else a reflow happens when the component loads and the element changes size.

In these cases, it is preferable that the user of the page not have to wait for the import to finish downloading before they are able to see the other content in the web app display on the screen. However, it is desirable that once the import finishes downloading, that import should be processed and loaded into the document (i.e. this isn't just a prefetch of content into the browser cache), so it is fully loaded and available by the time the web app needs it (thus it's also important that these elements fire a load event so developers know when they are available for use).

Thus, we propose that, like <script async>, we add support for <link rel=import async> to address this use case. At a high level, developers should think of these similarly: "I want to load this script/import but I don't want its load to block the rest of the content on the page from rendering."

There is a key difference between <script async> and <link async>: <script async> indicates that the script should not block the parser. <link rel=import> is already spec'd to not block the parser by default, async or not. However, since imports are intended to block rendering by default, <link async rel=import> indicates that the browser should not block rendering on the load of the imported resource.

I am not aware of render-blocking behavior being spec'd as part of HTML5, and this is probably for good reason: it is up to each user agent (browser) to decide when and what to paint during the course of a web page load. However, in practice, all browsers I'm aware of block rendering on the load of pending stylesheets, and similarly, will block rendering on the load of pending imports. Thus, <link async> is an indicator to the user agent that the load of the imported resource should not block rendering.

In a conversation with dglazkov and esprehn, we proposed that <link async> apply not only to imports, but also to stylesheets. The spec'd behavior should be the same in each case: an import or stylesheet with an async attribute should not block rendering of the page.

Whether to spec this as "should not" or "must not" block rendering is unclear: at first glance, "should not" seems appropriate. However, if spec'd as "should not" and one UA decides not to implement this behavior (they allow async imports to block rendering) then developers will likely abandon this technique and resort to JavaScript workaround that don't work particularly well (i.e. loading the import after a requestAnimationFrame callback, which has various drawbacks). Thus, in order to provide a way to load stylesheets and imports without blocking render that is guaranteed to work across browser vendors, my inclination would be to spec this behavior as "must not block rendering while being loaded".