What if I told you that the difference between a 30 second build and a 20 second one is about 4 working days?
Where I work we’ve recently started moving more and more towards using Webpack for our front-end builds. For a number of reasons parts of the build pipeline are still required to use plain old Uglify which in turn is run by Grunt (We use Grunt as the runner for our Webpack builds as well for the same legacy reasons).
Being a lazy developer I simply run the
grunt-watch task and let it take care of which tasks it should run. However the combination of these two ways to bundle JS makes it painfully slow to build our JS files. Since there is no clear separation between where the legacy JS files are and where the newer files that should be bundled with Webpack are we have to resort to running both tasks whenever a JS file changes. To add on to this we also use Soy templates, which require an extra compilation step to compile from
.js and finally an Uglify task to bundle all those
I recently decided to look into why changes to some JS files were causing painfully slow builds. The problem only manifested itself when some dependencies were linked (As we do when developing some of our internal modules). This turned out to be an incorrectly configured Uglify task. Basically the task to bundle the compiled Soy files would traverse the entire project directory looking for files named
.soy.js which weren’t in the
node_modules directory. However since
follow was set to true in the globbing pattern, it would end up following a bunch of useless symlinks in the
To find the issue, and fix the configuration, took me around an hour. This got me thinking, what’s the ROI on improving build speed for front-end projects? Pretty good, it turns out.
Let’s assume that each developer builds their project 50 times per day. For me that’s a conservative number, but it’s round and easy to work with. In Sweden, where I work, there are about 250 working days each year, taking in to account public holidays, paid vacation and weekends. All in all, that totals to about 11 working days each year spent waiting for builds per developer.
All in all this means that developers spend a lot of time waiting for builds and shaving 10 seconds from the build will save 4.3 working days per developer and year! The problem is that this waiting time comes in such small chunks that it’s impossible to do anything useful in between and I at least just end up staring at the screen. For this reason, spending some time shaving a few seconds from your build time can be a big money saver in the long run.