Performance Features in webpack 2
Webpack 2 is out for a while now with some interesting features which can help to control and improve the performance of your application. For this reason, we are going to talk about these features here in this blog post. I’m gonna start by talking about
tree shaking feature which helps to reduce the size of your bundle by excluding unused exports in it. Then, I will briefly describe
code splitting feature and how brand new
performance configuration object can help you to use this feature properly.
tree shaking feature is used during the transpiling process to exclude unused exports. Here is an example of how this feature can be used:
if you want to print value returned by
foo you could use following syntax:
By default, old webpack would include both
bar functions in the minified file. However, the new webpack introduces an algorithm for excluding parts of the code that are exported but not used in your application. Therefore, in the above case, the unused
bar function won’t be included in the minified bundle. For further information about
tree shaking, check out this blog post.
Code Splitting in webpack
By default,webpack is bundling your project into one monolith file. In other words, webpack generates one file containing all third-party libraries together with the code of your application. Therefore, each time you change something in the application, the whole file has to be re-uploaded to the server and then re-downloaded by the clients. Considering the fact that the source code of third-party libraries rarely changes while the code of your application changes frequently, it is very inefficient to keep reuploading and redownloading the whole file in this case. What if you could separate static and dynamic part of your code? Code splitting feature can do this.
In the next section, I will briefly explain various types of
code splitting in webpack. Then, I will talk about the newly introduced
performance configuration object which can give us more information about splits generation.
Vendor Code Splitting
These are third-party libraries whose content doesn’t change often; thus, browsers can load it once and then store it in the cache.
You can split CSS files into separate bundles. Such separation allows loading application code in parallel with styles. In this case, you can also take advantage of caching.
On Demand Code Splitting
This allows loading code splits that are only needed for a particular use case on programming request. That way you can prioritize resource loading. For more information, please check webpack documentation.
Code Splitting and Performance Indicators
Please note that bundle size can have a significant impact on your application load time. That’s why putting an effort in proper configuration of code splitting is worthwhile. After using the code splitting, how can we actually check if its configuration works as expected? Discussion about Webpack Performance Budgets led to adding
performance configuration object in webpack 2. Thanks to this, you can now configure webpack to detect code splits that are above the expected size limit.
performance object will define webpack bahaviour for handling oversized splits. By default,
hints is set to
warning which will display a warning with information about oversized splits. You can also set it to
error which will throw an error when the split is exceeding the size limit. You can adjust these options to your environment. For instance, webpack documentation recommends setting
error for production.
Other properties we can specify are
assetFilter. I will explain them base on the example below:
The given numbers are just an example. On the Performance Budget site, you can specify your expected application load time, then based on that an appropriate bundle size for your application will be calculated. Having that number in your webpack configuration will help you to control the size of your code splits; therefore, avoid performance issues.
I hope that you find this post helpful. Feel free to leave some feedback here.