Optimizing Webpack build size

Optimizing File Size

I decided to tackle file size as a fun side project at the office. After our big refactor for JW7 we finally had a modular, clean(er) codebase – so now the fun begins. Let’s squeeze it down as small as possible!

With this kind of task it’s always best to set some goals, pluck the low-hanging fruit and then re-evaluate. Our current player size was 232 kb minified, and as a team we established a goal of reaching 200kb.

To identify targets for refactor, I enabled verbose reporting on WebPack. This causes the compiler to output the size of each module independently. I piped that into a file and deleted everything above and below the modules list.

$ cat modules.txt | tr -s ‘ ‘ | cut -d’ ‘ -f3-5 | grep -v “bytes” | sort -g -r -k2,2


This command takes the modules output from WebPack, trims out the extra spaces, takes the substring between the 3rd and 5th space, removes all rows which are measured in bytes instead of kB and then sorts.

The results

../jwplayer/src/js/providers/html5.js 25.6 kB
../jwplayer/src/js/utils/helpers.js 24.7 kB
../jwplayer/src/js/controller/controller.js 23.7 kB

../jwplayer/~/css-loader!../jwplayer/~/autoprefixer-loader?browsers=%3E%201%25!../jwplayer/~/less-loader?compress!../jwplayer/src/css/jwplayer.less 22.4 kB
../jwplayer/src/js/providers/youtube.js 22.2 kB
../jwplayer/src/js/utils/underscore.js 20.9 kB
../jwplayer/src/js/providers/flash.js 15.4 kB
../jwplayer/src/js/view/controlbar.js 14 kB
../jwplayer/src/js/utils/css.js 10.4 kB
../jwplayer/src/js/controller/instream-adapter.js 10.1 kB
../jwplayer/src/js/controller/model.js 9.76 kB
../jwplayer/src/js/controller/captions.js 8.81 kB
../jwplayer/src/js/api/api.js 7.75 kB
../jwplayer/src/js/view/captionsrenderer.js 7.63 kB
../jwplayer/src/js/utils/backbone.events.js 7.33 kB
../jwplayer/src/js/utils/ui.js 7.23 kB
../jwplayer/assets/fonts/jw-icons.woff 6.96 kB
../jwplayer/assets/fonts/jw-icons.ttf 6.86 kB
../jwplayer/src/js/plugins/loader.js 6.59 kB
../jwplayer/~/handlebars/dist/cjs/handlebars/base.js 6.51 kB
../jwplayer/~/handlebars/dist/cjs/handlebars/runtime.js 6.29 kB
../jwplayer/src/js/view/components/timeslider.js 6.22 kB
../jwplayer/src/js/controller/setup-steps.js 5.96 kB
../jwplayer/src/js/utils/stretching.js 5.66 kB
../jwplayer/~/style-loader/addStyles.js 5.52 kB

<< Trimming the rest >>


My first surprise was the YouTube Provider, which adds playback capability for YouTube videos. I was surprised to see this as number 6 on the list – when we don’t even care about it! Internally we categorized YouTube files as legacy and do not technically support them in v7.0.0. This is an unfortunate misalignment between our code investment and our business goals. The YouTube provider could easily be removed from the player and loaded only when needed. Low hanging indeed!

There are other unused bits as well; for example we include both ttf and woff fonts, and yet a browser only needs one of them. Couldn’t we package in the most common format, and then polyfill in the backup – only when necessary? Another eye-catcher was noticing the CSS was 4th on the list; why is it 22kb? Is that large, average, light?

One cool thing to note when analyzing a library this way is that it can often indicate problems in code organization. Clearly our “helpers.js” file is too large, it does too many things and it should be broken up. True, we got the same message from Plato, and haven’t addressed it yet, but more nails in a coffin can’t be a bad thing.

One final thing to observe is that these sizes are pre-minification, which is a side-effect of our use of the WebPack Uglify Plugin instead of uglifying before compiling. For the purpose of this exercise it doesn’t matter, but we could definitely get more accurate if the needs demanded it.

Leave a Reply

Your email address will not be published. Required fields are marked *