A, goals,

This must be optimized. Before optimization, we need to roughly set the target, and the target needs indicators to measure, so we set two indicators:

Page load time is not much said, at least within 1s, the sooner the better package size control within 200K

Why these two goals? First of all, the page loading time is the final problem to be solved. Preliminarily, there are two factors affecting the page loading time, network and package size. The network is temporarily short of money and cannot be upgraded, so the main optimization focuses on package size. The corresponding Vue is app.js and app.css. After loading the entry, the page can at least show how much the package size should be optimized. On the one hand, vue-cli-service suggests no more than 244K, and on the other hand, we need to find the right standard to see what the package size of similar website is. Then we have a reference. I choose materialpalette, and check its package size is about 150k, my function is more complex. So I took 200 kelvin in the middle of the two as the target why do I talk about the target here?

Second, the plan

The goal is set, and then the plan code is confused with the resources into the CDN, because the development of the map is easy, the resources are placed under assets, directly introduced, this is also a big useless library delete, similar functions of the library merge, only use a few functions of the library, see if you can achieve gzip compression

1. Code confusion

Not to mention code obfuscation, which on the one hand saves package size and on the other adds some decompilation difficulty

const CompressionWebpackPlugin = require('compression-webpack-plugin'); module.exports = { configureWebpack: (config) => {// introduce uglifyjs-webpack-plugin let UglifyPlugin = require('uglifyjs-webpack-plugin'); If (process.env.node_env == 'production') {config.mode = 'production' // Package each dependency into a separate JS file. minimizer: [new UglifyPlugin({ uglifyOptions: { warnings: false, compress: { drop_console: true, drop_debugger: false, pure_funcs: ['console.log'] } } })] } Object.assign(config, {optimization})} else {// Modify config. Mode = 'development'}}}} for the development environmentCopy the code

2. Store resources to the CDN

This step is also easy to do, all resources are put on Ali Cloud OSS, a few minutes

3. Delete useless libraries

This step took quite a bit of time, because the map was easy during development. Many libraries were directly found on Github, and YARN Add was introduced. Now we need to split it carefully

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

yarn build --report
Copy the code

The first thing I did was get rid of ElementUi (about 158K after gzip compression), which was mixed with Vuetify at the time of development, and just one Vuetify was enough, and then I did a little bit of interface modification and then LODash, I only used a few of these methods, but the size of the whole thing is quite large, about 25K after gzip compression, so I looked for loDash source code, intending to extract several methods used, but the LoDash code is too nested, reference is too deep, so I simply killed the library, and found some more pure implementation to replace. I spent most of my time reading the loDash source code, and then VUescroll. When I was implementing the scrollbar style customization, I used this library directly, and found that the size of this library is not small, nearly 20K after gzip compression, so I directly killed it, and wrote the style myself. It will be returned later in other ways

4. The gzip compression

Add some configuration to vue.config.js, and then add some configuration to 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 enable the following configuration gzip_static on;Copy the code

5. Add the third-party library to the CDN

This is mainly about Vuetify, since gzip is going to be almost 50K in size, so it’s going to be faster to put on a CDN

The first is to remove Vuetify from the package configuration

module.exports = { // ... configureWebpack: (config) => {if (process.env.node_env == 'production') {// CDN config.externals = {vuetify: 'Vuetify'}} else {// Modify config for development environment config.mode = 'development' config.externals = {Vuetify: 'Vuetify'}}}}Copy the code

Then manually load vuetify CSS and JS in index. HTML

< link href = "https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.css" rel = "stylesheet" > < script SRC = "https://cdn.staticfile.org/vuetify/2.4.4/vuetify.min.js" > < / script >Copy the code

There are actually better ways to do this, which can be passed to index.html with the Webpack argument and introduced via EJS, but it’s easier now, so I don’t do it here

Five, the effect of

With the above strategies, the final package size was optimized from 1.72 M to 94K

Six, subsequent

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

More refined optimization, it should be possible to make deeper customization with Webpack to integrate the third-party library on the CDN mentioned above. After all, it is too scattered to put directly in index. HTML, which is not a good project structure, and is not conducive to the subsequent development and the specification of the subsequent code development. Such as three-party library reference specifications, resource import specifications, etc., can do a lot of pre-deployment performance testing, mainly to see whether the page load speed is up to standard

There are a lot of things that can be done. Sometimes, achieving a goal is not the end of one thing, and maintaining the goal also needs to be considered