preface

I had nothing to do these two days. I wanted to optimize the startup time of the project. I spent an afternoon optimizing the startup time of the project from 48 seconds to 14 seconds, about 70 seconds, and the effect was still there, and only one line of code was used.

👇 will show you how to find this line of code. If you have no patience, you can jump to the bottom of the article and read the conclusion directly.

Project background

The project is a simple Vue project, but the company has a layer of Vue – CLI package, but the impact is not significant.

Other also did not have what, the normal H5 web page, with the plug-in is not much, in order to control the volume of the project.

Project analysis

Now that we have decided to optimize, we need to analyze the project first. First, we need to analyze the project with speed-measurement-webpack-plugin and Webpack-bundle-Analyzer. The specific configuration here is not much to say, very simple, a lot of online search, here directly see the conclusion.

The first is the project runtime:

As you can see, eslint-Loader and Vue-Loader are the most time-consuming. One takes more than 40 seconds, and the other takes more than 30 seconds.

Let’s take a look at specific package analysis 👇

The chunk-pages on the left, and the vendors don’t need to look at them, are too many pages, and the corresponding files are too many, so eslint-Loader and Vue-Loader take too long, so many files. Of course it takes a long time to check each one.

The right side could have been optimized, but I don’t think it’s necessary, swiper isn’t that big.

Because the project is a multi-SPA application, there are so many.vue files that esLint takes too long to check and load at startup, causing the project to take too long to start.

The solution

Once you’ve found the problem, you have to solve it. There are two initial solutions:

  1. killeslintIs not checked at local compile time
  2. The cache

Solution 1 is by far the simplest, but it’s a bit unreasonable, because the point of having ESLint on is to format code. While there are hooks to format code when it’s submitted, prompting it during development is a better way to code it properly.

So now the only solution is to cache the operation, then I began to find related plug-ins to better cache.

Try to solve

The first is the hard-source-webpack-plugin, which provides the intermediate caching step for the module, but the project needs to run twice. The first build time is normal, and the second one saves about 90% of the time.

This plug-in is recommended by many articles, it feels very good, and it is very easy to use, just 👇 :

plugins: [
  new HardSourceWebpackPlugin()
]
Copy the code

That’s it.

Is it that simple? It’s that simple, but it’s not that simple, and if it stops here, I won’t be doing it all afternoon.

As simple as this:

npm i hard-source-webpack-plugin -D
Copy the code

Then simply configure it like 👆, restart the project, and guess what?

An error!

The reason?

Is it one of the speed-measured-webpack-plugin or Webpack-bundle-Analyzer? Why?

The reason why the author is not really clear, because the startup of the wrong report is:

Cannot find module ‘webpack/lib/DependenciesBlockVariable’

Oh, this mistake is a little unexpected, why suddenly reported webpack mistake?

I am also scratching my head ah, go to Google no one has encountered this problem.

The hard-source-webpack-plugin plugin is a plugin that uses the webpack plugin as a plugin. The plugin is a plugin that uses the webpack plugin as a plugin. The webpack plugin is a plugin that uses the webpack plugin as a plugin. And this is an internal package of the company, which is not possible to drop the version.

First connection

So what else can we do?

Really have no way, the author attempts to search DependenciesBlockVariable related content, this happened a subtle transformation, the original function in webpack5 been removed, is it because the company internal vue – cli using webpack5. X version?

I immediately found the plugin in node_modules, then checked the package.json file, and was disappointed to find that webPack version 4.2.6.

Now that the WebPack documentation is open, take a good look. To be honest, I have seen this document for N times, and it is a little surprise every time I see it. There are so many functions.

Turn over to see this small function 👇 :

Wow, that’s a bit of a surprise. That’s just what I want, isn’t it? Then make a quick decision and go to vue.config.js, and guess what?

A!!!

Although the documentation is for webpack5.0, I found that the 4.x version also has this feature, if a little weaker, more or less work.

After restarting the project several times, I found that the startup time has been stable, the effect is really good yo ~

I worked straight to 14 seconds, which was a little shaky, but it was the best solution for the situation.

So the final code is:

chainWebpack: (config) => {
  config.cache(true)
}
Copy the code

The reason for using chainWebpack is that there is actually no separate webpack.config.js file in the project, so you have to put it in vue.config.js and use chainWebpack to insert the configuration into WebPack.

You think that’s the end of it? It’s too easy.

Second transfer

After the problem is solved, of course, the speed-measured-webpack-Plugin and Webpack-bundle-Analyzer should be deleted, and then the code should be sorted out and put up.

The hard-source-webpack-plugin plugin doesn’t work. Shouldn’t be. Why can’t you use your own project when everyone else can?

In order to improve the startup time of the project, I installed the hard-source-webpack-plugin again and configured it:

chainWebpack: (config) => {
  config.plugin('cache').use(HardSourceWebpackPlugin)
}
Copy the code

One more run, and guess what?

A!!!

In order to avoid another startup failure, I did not use speed-measured-webpack-Plugin and Webpack-bundle-Analyzer this time, so I cannot estimate the startup time in detail, but the visual time is less than 10 seconds.

The hard-source-webpack-plugin fails because of the two statistical plugins. Try it again.

conclusion

The conclusion here is very simple. There are two versions.

First of all, it would be convenient if the project could use the hard-source-webpack-plugin to do nothing, so this line of code is 👇 :

config.plugin('cache').use(HardSourceWebpackPlugin)
Copy the code

It’s probably more than 90 percent faster, and the authorities are not falsifying the time.

Second, if you can’t use the hard-source-webpack-plugin, give it up. Try the webPack cache function, which is not as good as the hard-source-webpack-plugin, but can improve startup time by 70% or so. So this line of code is 👇 :

config.cache(true)
Copy the code

And do not need to install any plug-ins, in one step.

The hard-source-Webpack-plugin is better when it comes to stability and effectiveness, but cache does not require additional WebPack plugins. It is up to you to decide which one to use.

The hard-source-webpack-plugin doesn’t work. The hard-source-webpack-plugin doesn’t work. The speed-measured-webpack-Plugin and Webpack-Bundle-Analyzer are related to the speed-measured-webpack-Plugin and Webpack-Bundle-Analyzer plugin, but I don’t know for sure. If you know, please leave a comment or send mea personal message.

Look so long, hard!

< (__) >




PS: THE author also uses a series of JavaScript brush article, interested can click into the personal home page to see, put two directories:

Here’s 👇 by date

Front Brush path – Directory (Date classification)

Here are the categories by question type 👇

Front brush problem path – Catalogue (Question type classification)