Implementation of Vue package size optimization (from 1.72M to 94K)

1. Background

I recently made a website, uidea, which is used to assist independent developers to do some UI design. At that time, I was only responsible for development. After deployment, I found that the access speed was worrying. After all, it was a small water pipe server. Compared with increasing the bandwidth, I still have to see if the code can be optimized first, which is more cost-effective. This is the package size before optimization. This guy is 1.72M. The loading time of the small water pipe directly goes to more than 3s. I can't stand it.

II. Objectives

This must be optimized. Before optimization, we need to roughly set the goal. The goal needs to be measured by indicators, so two indicators are set:

• The page loading time should be within 1 second at least. The faster the better.
• The package size is controlled within 200k

Why set these two goals? First of all, page loading time is the final problem to be solved. From a preliminary point of view, there are two factors affecting page loading time: network and package size. The network is temporarily short of money and cannot be upgraded, so the main optimization is focused on package size. First of all, we need to define what package size is. Here I mainly refer to the entry package size. For Vue, it is app.js and app.css. After the entry is loaded, the page can at least be displayed.

To what extent should the package size be optimized?

On the one hand, vue-cli-service is recommended not to exceed 244K. On the other hand, we need to find a benchmark to see how big the package size of similar websites is. Then we also have a reference. I chose materialpalette. Its package size is about 150k. My function is more complex, so I took the 200K between the two as the target.

Why do we need to talk about goals here? Because the goal is actually very important. As the old saying goes, aim for a goal. Without a goal, it is easy to give up halfway during the execution process, or stop at only half a step forward.

Take dating for example. If your goal is to find a girlfriend, then you probably won’t find one. But if your goal is to pursue a certain girl (such as Zhang San) as your girlfriend, then the probability of success will be greatly increased because you can make targeted preparations for this girl.

3. Solution

Once the goal is set, then the plan is decided

Although this is my first time doing Web optimization, I have experience in optimizing Android package size before, and the principles are always the same, so I thought of the following strategies at the first time:

1. Code Obfuscation
2. Resources are placed in CDN. Because it is easy to develop, resources are placed under assets and directly require. This is also a big deal.
3. Delete useless libraries, merge libraries with similar functions, and use only a few libraries to see if you can implement them yourself
4. gzip compression
5. Third-party libraries are also placed on CDN

1 - 3 are the first three optimization solutions that come to mind. Then I searched online for Vue's corresponding optimization strategies and added the last two. There are also some other solutions, such as lazy loading of routes, but because the main content of this website is concentrated on the homepage, this was not considered (although there are many good things, it is best to adapt to local conditions)
So a total of 5 optimization strategies were set, and now we will start

IV. Execution

1. Code obfuscation

I won't say much about code obfuscation. On the one hand, it saves package size, and on the other hand, it can increase the difficulty of decompilation. I searched for Vue obfuscation configuration on the Internet (after all, we have to stand on the shoulders of giants). It works well after trying it. The configuration is as follows

const CompressionWebpackPlugin = require('compression-webpack-plugin');
module.exports = {
 configureWebpack: (config) => {
  // Import uglifyjs-webpack-plugin
  let UglifyPlugin = require('uglifyjs-webpack-plugin');

  if (process.env.NODE_ENV == 'production') {
   // Compression and obfuscation config.mode = 'production'
   //Package each dependency package into a separate js file let optimization = {
    minimizer: [new UglifyPlugin({
     uglifyOptions: {
      warnings: false,
      compress: {
       drop_console: true,
       drop_debugger: false,
       pure_funcs: ['console.log']
      }
     }
    })]
   }
   Object.assign(config, {
    optimization
   })
  } else {
   // Modify the configuration for the development environment config.mode = 'development'
}
  }
 }
}

2. Put resources on CDN

This step is also easy to do. All resources are placed on Alibaba Cloud OSS and it can be done in a few minutes.

3. Deletion of unused libraries

This step took a lot of time, because when developing, I just searched for many libraries on GitHub and imported them with yarn add. Now I need to split them up again.

Add --report after the package command to see the status of the package

yarn build --report 

First, remove ElementUi (about 158k after gzip compression). During development, ElementUi and Vuetify were mixed. In fact, only Vuetify is enough. Then make some small changes to the interface and it's done.

Then there is lodash. I only used a few methods in it, but its entire size is not small, about 25k after gzip compression. So I looked for lodash source code and planned to extract a few methods used, but lodash code was too deeply nested and referenced, so I didn’t want to extract them. I simply killed this library and found a few purer implementations to replace them. Most of my time was spent reading lodash source code.

Then there is vuescroll. When implementing the custom scrollbar style, I was lazy and used this library directly. I found that the size of this library is still not small. After gzip compression, it is nearly 20k. I just killed it and wrote the style myself (this incident tells us that if we are lazy now, we will pay it back in other ways in the future 0_0)
This killed several big libraries.

4. gzip compression

This is a solution I found online. Just add some configuration in vue.config.js, and then you also need to make corresponding configuration in nginx

// vue.config.js
module.exports = {
 configureWebpack: (config) => {
  if (process.env.NODE_ENV == 'production') {
   // ...
   // gzip
   config.plugins.push(new CompressionWebpackPlugin({
    algorithm: 'gzip',
    test: /\.js$|\.html$|\.json$|\.css/,
    threshold: 10240,
    minRatio: 0.8
   }))
  }
  // ...
 }
}
// nginx directly turns on the following configuration gzip_static on;

After packaging, a .gz file will be generated, and nginx will automatically use the .gz file

5. Put the third-party library on CDN

Here we mainly deal with the Vuetify library. After all, after gzip, it is nearly 50k in size. It will be faster to put it on CDN. First, remove Vuetify from the packaging configuration.

module.exports = {
 // ...
 configureWebpack: (config) => {
  if (process.env.NODE_ENV == 'production') {
   // Third-party libraries are not packaged, use CDN
   config.externals = {
    vuetify: 'Vuetify'
   }
  } else {
   // Modify the configuration for the development environment config.mode = 'development'
   config.externals = {
    vuetify: 'Vuetify'
   }
  }
 }
}

Then manually load vuetify css and js in index.html

<link href="https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.css" rel="external nofollow" rel="stylesheet">
<script src="https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.js"></script>

There are actually some better ways here. You can pass it to index.html through webpack parameters and import it through ejs. It is relatively simple now, so I won’t do it here.

5. Effect

Through the above strategies, the final package size is optimized from 1.72M to 94k

VI. Follow-up

Overall, the optimization effect is obvious, but there are still things that can be done later:

• More refined optimization, it should be possible to combine webpack for deeper customization
• Integrate the third-party libraries on the CDN mentioned above. After all, putting them directly in index.html is too scattered, which is not a good project structure and is not conducive to subsequent development.
• There are still many things that can be done to standardize subsequent code development, such as the specifications for third-party library references, resource introduction specifications, etc.
• Performance testing before each deployment, mainly to see if the page loading speed meets the standard

There are still many things that can be done. Sometimes, achieving a goal is not the end of the matter. Maintaining the goal is also something that needs to be considered.

This concludes this article on the implementation of Vue package size optimization (from 1.72M to 94K). For more relevant Vue package size optimization content, please search 123WORDPRESS.COM’s previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!