Pick the cherry or shake the tree to prune the dead code.
The problem statement that made me dig deep into this topic and write this article is tree shaking with rc-slider
.
In one of my recent React project, I am taking utmost care to make sure that I let no stone unturned to achieve the best performance. Among things like lazy loading, code splitting and image optimisation, tree shaking is turning out to be very useful.
Most of the libraries these days provide an option of tree shaking by default. With tree shaking, only the modules that you’ve imported from a library are used while creating the build instead of using the entire library. This way, the size of your build reduces, which results in reduced download time and hence you achieve better performance.
Achieving this is quite straightforward:
Instead of importing modules like:
import arrayUtils from 'array-utils'
you change the import to:
import { unique, implode, explode } from 'array-utils'
It will make sure that only the these specific modules are imported in the production build. This works fine for most libraries, but some libraries like lodash
and rc-slider
don’t support this way of tree shaking. For these libraries, there are a different way of picking only the required code. And this method is called cherry picking.
I was using rc-slider
library the recommended way but noticed that the size of my build increased by 500kB and there was no tree shaking happening for the build.
The default way of importing Range
element from rc-slider
:
import { Range } from 'rc-slider';
But this was not solving my issue. I figured it out that this library provides a way to cherry pick the element of my interest:
import Range from 'rc-slider/es/Range';
With this the size of my build decrease significantly (details in table below). Also the percentage of unused code of rc-range
reduced by a huge percentage.
Below is the code coverage report without cherry picking (unused code: 49%):
And this is the code coverage report after cherry picking (unused code 28%):
Here is the overall metric depicting the result after just changing a single line of code.
This might be a very simple example, but being able to save 400+ms download time with such a small change is a huge achievement in itself. Implement this in large scale and you will be surprised with the result.
There are lots of performance tricks or guidelines like this that will and has always helped developers achieve better performance. It’s time for us to stop neglecting performance and start following good practices.
Dead code is the code that is of no use to you but still gets added in your build.
As a web developer, it is sinful to make your user wait for a large file to download of which only a fraction is actually used.
I hope you found this article useful. I would love to hear your thoughts. 😇
Thanks for reading. 😊
Cheers! 😃
If you find this article helpful, you can show your appreciation by clicking on the clap button. As the saying goes, When we give cheerfully and accept gratefully, everyone is blessed.