Webpack Bundle Analysis — A necessary step for all React, Angular, Vue application developers!

If you are trying to create a modern performant web application.. then chances are high that you are using Webpack Directly or indirectly! Are you using for React? Are you using for starting your angular app? Are you using to initialize your Vue applications? CRA (create-react-app) Angular-CLI Vue-cli If your answers are YES to any of the question above — then you are using webpack in the background! webpack follows its parsing logic and generates bundles. The process of bundling is very flexible to accommodate variety of js files and bundle formats like cjs, ES modules, amd, umd, etc. However due to this flexibility, however the side effects can be bundling more code on accident if you don’t know what module type you are shipping to webpack. This is why — we the users of webpack, should analyze and gain insights into what did really get into our bundles. We should question each module’s presence and its applicability, its presence in specific bundles and across bundles etc. But typically, a medium complexity angular application easily includes 1000–1500 modules so.. if one tries to look through the generated modules, that person is going to lose couple of days in his/her life! Thankfully, webpack comes with its own option and to visualize that json yourself. There are couple of very which also provide their own visualization which I find very useful in making sense of contents of my bundles! Today, I will be walking through one of my experience of applications bundle tuning! --json an Analyzer useful plugins So — when I was asked to help on performance of the application, I was told that it took 40 seconds for home page to become responsive! To me that was little too slow. And home page did not actually have a lot of content that it should take long! that Iteration 0 So I started analysis. What follows is series of screenshots and fixes suggested.. I started off by creating a json file and loading it in . Chris bateman’s visualizer This was the report that I saw! Armed with this information, I could immediately saw my first opportunity to achieve better TTI. The 4.2MB bundle. I explained my team to for routes and soon I was given a new code. I also checked network tab for the application to realize that the web-server was not making use of gzip .. a very basic step for web-server configuration. I instructed my team to get this sorted out. use LazyLoading technique content-encoding header Iteration 1 The new chart was as below . First improvement — 6 bundles instead of one. main bundle is now 1/3 of the original size! Now I wanted to focus and understand what is inside the main bundle as well. While 1.8MB (non-gzip) from 4.2MB was a great improvement, I still felt 1.8MB is still quite a bit of code to get downloaded on first page. So I selected main bundle in the dropdown in the above screenshot and inspected what’s present in that bundle. Below is what I saw… My observations: Overall 97% code was from node_modules (essentially libraries) various modules from Angular took 55% of the same — which is about 1MB in size. Moment.js locales folder occupied 150KB Lodash was getting added in multiple modules and in each module was taking up 50–70KB. D3 was imported via This meant that we were including entire D3.js library even though we were not using all the features. import * as d3 from 'd3'; 16% of overall app (or 300KB) — which was shown under node_modules was actually application stylesheet which was part of main bundle. I was not sure if the stylesheet should be that large. So I decided to further investigation of Styles.. Upon inspection, I realized that each of my stylesheet files are unusually large at 35kb+ each! Also I saw that we were including unrelated stylesheets in main bundle. At this juncture, I cracked open the editor and started checking SCSS files. I immediately saw an incorrect scss import getting added on top of all SCSS files causing each SCSS file to be so large. I confirmed this issue by checking other bundles too! Other bundles also were showing large file sizes for scss files. I asked my team to first fix SCSS imports on priority as it was affecting all the bundles. Iteration 2 The next iteration was quite better immediately. All the bundles now have 1–3% CSS code — which is somewhat to my expectation. Now I asked my team to concentrate on removal of momentjs locales, lodash tree shaking, D3 treeshaking and Angular AOT compilation so that Angular compiler will not get included in the application codebase. The new build was really satisfactory to me now! open each image to see specific improvements. Summary of configuration fixes to achieve above improvements For Lodash — we just need to add into webpack config. lodash-webpack-plugin For momentjs — we need to use to only that we desire. context-replacement-plugin include specific moment locales For D3 — we need to import specific imports from D3 (works for D3 v4+). For AOT build — latest version of Angular-CLI is already AOT enabled. ng build --prod As a summary below is table that shows First page bundle size going down over iterations.. By final iteration — first page download size came down by 90%! Main improvements — SCSS imports fixed. GZip content encoding added in web-server Iteration 1 — Momentjs, D3, Lodash fixes, AOT compilation Iteration 2 More improvement ideas Don’t use D3+C3/nvD3/Dimple combos, at least on your home page. At the time of writing, do not make use D3 v4 and hence cannot make use of ES modules that D3 v4 employs. this means, you are easily adding about 150kb to your bundle via D3+C3/nvD3 combo. I would rather recommends — a really tiny (10kb) SVG based charting library (at least on home pages). C3 nvD3 Chartist Similarly, we should really try to drop moment and use library.. Its a beautiful date operations library and provides ES modules so it saves on JS file size. Right now moment.js is clocking 51kb with no tree shaking possible. date-fns Upgrade Angular-CLI v1.5 & angular v5.0+ asap to utilize feature of Angular CLI to compress your bundles even more. build optimizer Upgrade to Webpack 4 (when available) to boost your tree shaking by ! large margin Summary: Webpack is an awesome and super flexible bundling library. But one must pay attention to what kind of libraries are getting bundled via webpack. This can have a large impact on application bundle sizes and thereby on your first page load and parse time. There are multiple tools available to help you visualize the webpack’s json output and arrive at optimization strategies. Connect Please clap, comment, follow on , to keep in touch and have awesome technical conversations! medium twitter