Larger bundles of script can exhibit a few interesting characteristics:
- They can keep the main browser thread pegged for longer than smaller bundles 😓. This can heavily impact how soon a page is interactive.
- They can increase the overall load time for a page, keeping your users waiting for an experience that could be complete sooner.
Performance Budgets should help us all get a little more thoughtful with how we much JS we load. This will hopefully lead to faster sites 👍
We care enough about this problem that we’ve made the feature an opt-out. We know it will mean one more thing we all need to keep an eye on, but in the grander scheme of things, if it results in your users getting a happier, faster loading experience, then it’s a win 🏅
By default, Webpack prescribes some default performance budgets (for entry points and assets). These defaults are based on studies we’ve done into budgets that ultimately lead to a quick loading experience on both cable and 3G.
If, however, you’d like to tweak these defaults, then you can customize the maxAssetSize, maxEntryPointSize or hints (false, ‘warning’ or ‘error’) using a
performance entry in your Webpack config:
We know that not every site is the same. Occasionally, your architecture may require a larger (or smaller) bundle to load before it’s useful. We hope the above is flexible enough to meet these needs. If you really, really need to, setting hints to false will suppress the performance suggestions.
Highlighting loading patterns
Where possible, we believe it’s a good pattern to only load features a user is going to need for a page. This means shipping the minimal amount of script to make a page functional, lazy-loading the rest of your scripts for other features or components as the user needs them.
For this reason Performance Budgets also try to encourage using Webpack’s code-splitting, where we think it will make a difference.
Btw, the RC also includes our shiny new support for dynamic import()!
It’s a wrap! 🎁
That’s it! Please try Performance Budgets out, and if you have any feedback on how we can improve the UX for this feature, please, feel free to drop us a comment on this issue thread.
I’d like to take this opportunity to thank Sean Larkin, Sokra, Vignesh Shanmugam and the rest of the Webpack team for the hours poured into making my RFC for this feature a reality.