-
-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an asyncMedia
option to prevent parser-blocking async css
#736
Comments
https://github.com/webpack-contrib/mini-css-extract-plugin#attributes, you can do it using this, changing |
Thanks for the suggestion – my understanding from #721 was that this specific use case wasn't supported with the |
Why do you need this? I recommend to use |
I'm looking for a way to download CSS files without blocking javascript parsing. By inserting a If we were to add a An alternative is to instead of doing the
would add a link attribute with: and an onload handler which would replace this with: One difference doing this would be that the CSS gets downloaded with the highest priority, but probably that'd be what you'd want in this case anyway. By "async" what I mean is really what the plugin does already, here: https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/index.js#L783 . My understanding was that this type of insertion would be safe against FOUC because it doesn't call resolve() until the |
It still have |
Close in favor #949 |
Feature Proposal
I would suggest adding an
asyncMedia
option to the plugin that would allow loading of async css bundles with themedia
attribute set toprint
(or something else), which is then switched out toall
on load.Eg.
would add a link attribute with:
and an
onload
handler which would replace this with:when the stylesheet has been downloaded.
I would suggest the default for this option is
print
but that it is customizableFeature Use Case
This is the best practice way of loading async css – without it, the page pauses while downloading the async css as it's appended to the head.
This use case was previously mentioned in #721 , but it cannot be easily implemented due to the fact that the
onload
attribute is in use by the plugin logic itself. For that reason I think it makes sense to implement this as an option in this plugin.(I'd be happy to implement this myself if you think it makes sense)
The text was updated successfully, but these errors were encountered: