This is 🐈 Yokoyama of development.
In this post, I'll show you four ways to reduce your build time.
We use Gulp and webpack together, and more than I expected, the build time was slow 😭.
During development, the front-end is built repeatedly and frequently. Therefore, if the build time is too long, it disturbs the efficiency and pace of development, and reduces the concentration and motivation.
Many of you are probably using some kind of module bundler in your web frontend development today. There are many different module bundlers, but in 2020webpackis the standard, I think. Let's refer to this paper to reduce the build time.
Click here for table of contents
- 1. Increase the machine specifications
- 2. stop processing from Gulp to webpack
- 3. enable cache
- 4. Review the settings of development build
Increase your machine specs
I know it sounds crazy, but by increasing the machine specs, the build time has improved a lot 🎉.
In our company, we had built a development environment on AWS for development.
However, since we set up one server in the company a few months ago and started developing on the newly added server, we have been able to save a lot of time.
For more information, please refer to this article.
This is Nishimura from the development team. We've been using an instance of aws (Amazon Web Services) to develop learningBOX, but there have been some inconveniences, so we're going to switch to developing on our own server.
The time for a production build (without cache) on AWS is 147.06s It was 😱
On the internal server, the 31.73s The result is that it was quite effective.
However, it is necessary to improve it by other methods because it will become a headache somewhere if it corresponds by raising the machine specification forever.
Stop processing from Gulp to webpack
In our company, webpack is mainly used for TypeScript transpiling.
webpack is based on one output per entry.
But our company is multiple entry and multiple output.
For this reason, I had to pass it from Gulp to webpack and back to Gulp again after the transpile.
However, Gulp is not updated much anymore and I wanted to migrate to webpack completely if possible.
but it turns out that in the current situation it's impossible without rewriting the code quite a bit 😭.
So I modified it so that it works with webpack alone, even if it's only TypeScript.
If you want to realize multiple entries & multiple outputs with webpack, you need to pass entries in the following form.
Reference.Multi Page Application
module.exports = {
entry: {
pageOne: '. /src/pageOne/index.js',
pageTwo: '. /src/pageTwo/index.js',
pageThree: '. /src/pageThree/index.js'
}
};
The part that corresponds to the key is placed in the output [name].
module.exports = {
output: {
filename: '[name].bundle.js'
}
};
In the above example pageOne.bundle.js and the output will be
If the number of files is small, this method is good, but if the number of files is large, it is quite severe to add it here every time.
so glob to get the file to build, and pass it in the form of the entry above.
Now you can get and output files with webpack alone.
This results in a production build (no cache) runtime of 31.73s → 17.97s and that's nearly half!
But this example is not common, so it may not be very helpful lol.
Enabling the cache
From webpack 5Significant speed improvement through cachingis now expected.
You can enable it by setting as follows.
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename]
}
}
};
The webpack standalone time is 15975 ms → 525 ms It was significantly shortened to!
Time as a whole is 17.97s → 9.21s now.
Since the build time of JS and SCSS by Gulp is longer, I decided to improve the production build.
Review the development build settings
The production build is much improved, but what about the development build?
Result of increasing the machine spec (without cache)
56.28s → 14.43s
The result of changing TypeScript to work with webpack alone (without cache)
14.43s → 9.78s
If cache is enabled
9.78s → 4.51s
What used to take me almost a minute is now under 5 seconds 🎉.
It's fast enough as it is, but it's never too early to start.
I wondered if there was a good idea, and decided to stop transpiling to ES5 and TypeScript type checking during development builds.
Transpile to ES5
Our learningBox has been developed to work with IE11.
However, the modern JavaScript notation does not work in IE11 as is.
For this reason, we have converted it to a notation (ES5) that also works in IE11.
Basically, I develop in modern browsers, and when I finish to a certain extent, I check cross-browser compatibility, so the time I touch is modern browsers > IE11.
I know there are pros and cons to this, but I thought it could be shortened by eliminating this part.
Stop TypeScript type checking.
In our development team, we mainly use VSCode.
VSCode and TypeScript work well together, and they perform type checking in real time.
So I decided to leave the type checking to VSCode during development.
In the ts loader in webpack ts-loader but in the development build, the esbuild-loader changed to
If you incorporate the above two
4.51s → 2.90s and we're finally under three seconds!
Change to a differential build
We've already done it, but I'd like to share it with you!
You think it's useless to re-build all the files every time you change them during development, right?
It will be faster if you only build the files that have changed.
Reference.Watch and WatchOptions
If you are on watch, the build time isSeveral hundred msIt will be!
These are the improvements we've made! We hope this will be helpful to you.
English 
Japanese