Bundle Size Part II

In my previous post, I shared how I made minor improvements to my app size. In this post, I'll share further improvements and go into more detail on the results.

Axios to Redaxios - Making Fetch Happen

The first item I focused on was axios. Axios makes XMLHttpRequests from the browser and has nice out-of-the box features including automatically converting requests to JSON, handling upload progress for files, and more.

Axios and XMLHttpRequests can be replaced with the browser-native Fetch API. Using native APIs reduces bundle size, improving performance. However, because the axios library was used frequently in the codebase, moving to the Fetch API would have required a significant amount of change.

I decided to replace axios with redaxios, which is a drop-in replacement. Redaxios implements the axios API as a wrapper for the Fetch API - perfect! Using redaxios gave me the benefit of using the Fetch API while making minimal changes to my codebase.

I will note that there is one component of my application - a photo upload screen - where I did not use the Fetch API. This screen displays a progress bar during upload; progress status is not currently supported in the Fetch API. So, this particular component was re-written using a plain XmlHttpRequest instead of a library.

FontAwesome to Phosphor Icons

The second item I focused on was the FontAwesome package. Despite having followed the documentation for minimizing bundle size with Vue, FontAwesome still accounted for ~90kb in my index.js file, which was ~20% of the overall size. The architecture of FontAwesome for Vue results in every icon being included in index.js. This is fine, but my app lazy-loads a lot of components and I wanted the icons to be included on an as-needed basis instead of being loaded all at once.

I chose Phosphor Icons as the replacement icon library. They are free, open source, and lovely to look at! They also have fantastic documentation and examples for Vue, React, Webfonts, Swift, and more. Phosphor also handles lazy-loading and tree-shakability the way I want my app to work.

Before and After

The libraries I replaced had the following impact on my index.js file:

By making these replacements, I reduced the size of index.js from 429.44 kb to 308.71 kb - a 28% reduction!

However, this isn't the most accurate way to look at the size of this application. First, index.js is only one file of several in this app. Second, I don't want anyone reading this to think I'm not using Gzip to serve assets in production - I am! These screenshots don't take gzip and total bundle size into account, so are the improvements really that impressive? Should I be blogging about this at all?? Let's review the output from vite build for the 5 largest components in my application, comparing the results from before and after my changes, with and without Gzip:

Component Size - not using Gzip

All sizes in kB

Component Size - using Gzip

All sizes in kB

Takeaways

What are my key takeaways from making these changes? First and foremost, the total bundle size of the app is 5% smaller when using Gzip, which is great! It's an improvement, if not a double-digit percentage improvement. That said, it is more accurate to look at the app holistically, instead of focusing on a single component.

There is a trade-off to having app size spread out across various components versus the main component. As always, there is no "one-size fits all" solution. The biggest size improvement certainly came from removing the Axios library, however, this was offset somewhat by using the new icon library with better support for lazy-loaded components.

An argument could be made for either approach - a larger main bundle and smaller lazy-loaded components or vice versa. For this application, I opted for the smaller main bundle because I want my main bundle to load quickly. I also know that a typical user session on my app does not load all the components; for my case these changes will result in an improved experience overall.

I hope this provides some motivation to look at your application size and think about the optimal strategy for your specific needs and usage patterns. Thanks for reading!