-
Notifications
You must be signed in to change notification settings - Fork 10
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
Polyfills plugin should feature detect polyfills support (using webcomponents loader) #9
Comments
Maybe it would be better to turn this into an RFC, more thoughts come to mind
|
Looks like our Lighthouse Performance score could improve as part of this if there's a better way to handle loading of polyfills |
There are about three items that are left, not really related to what true differential loading is though which is basically generating two bundles, but with
The bulk of the heavy lifting coming from polyfills though instead of the straight bundle, we should switch to using the loader, so that it can feature detect the right polyfills to load without the cost of the whole bundle. The rest of the open items could probably be made their own (single) issue. |
Type of Change
Summary
Currently, polyfills are enabled by default. I think for a static site, as few dependencies should be needed, but if some are needed to support browsers, they should be opt-in, ideally through differential loading
Details
Write test cases for these use casesUpdate README with documentation / samples of the above use casesLooks like we'll need to migrate PostCSSUse webcomponent-loader or everything? (but actually is bigger bundle size wise than just using bundle?)Question: confirm which browsers actually need polyfillsThe text was updated successfully, but these errors were encountered: