CSDN fan account: down and out front online fry powder ZZZ, irregularly send [standard factory will meet questions], [will commonly used algorithm], [will be high concurrency solution], [optimization] and other special columns for everyone to study and watch

Before we begin, we will introduce a use that you can skip to and watch directly in the optimization section of Vue packaging results, and then refer to it on the way back to watch better

1. Customize webPack configuration in vue-CLI

Vue-cli official document

If we configure directly in the configureWebpack, our configuration will appear in both production and development environments, so this is definitely not what we want. We can optimize the configuration this way. In fact, vuE-CLI helps us take this into account. He passed in a production environment development environment for us at configuration time

  1. Create a new webpack.config.js file in your project

2. Configure the property field configureWebpack in vue.config.js3. Check the current environment in webpack.config.js4. Import the environment configuration we exported from the webpack.config.js file in vue.config.js

2. Optimization of Vue packaging results

2.1 Analysis of packaging results

2.1.1 Use of tools to analyze packaging results

Since Vue2.0 uses Webpack as a packaging tool, we can add the webpack plugin or loader we need into the vue2.0 packaging webpack

For details about adding custom Webpack configuration in VUe-CLI, please refer to 47. Customize webPack configuration in vue-CLI

Since we can add our own Webpack configuration, we can analyze the package result of Webpack plugin: Webpack-bundle-analyzer, which adds it to our production environment to package the results so that we can see the size distribution of the modules in our VUE project visually when we package the VUE

2.1.2 Viewing the Packing Result

We all know that Vue is a non-invasive Web framework. Because of its non-invasive nature, we can add as many third-party JS libraries as we are used to to increase development efficiency to vue framework, so our packaging result might look like this:

There is no such thing as tree-shaking optimization in Vue2, so Vue2 has very little packaging optimization

Question 1:

We can see that we introduce the third-party libraries, they occupy packaging are very large volume as a result, may we have our own vue code and the code is not two third party packaging result of JS library code amount to much, we only quoted here two very commonly used packaging result of third party JS library has accounted so huge, Then we are in a large project, we can imagine that the packaging result may bear a huge amount of third-party JS library code

Question 2:

Babel simulates most of the apis and objects of ECMAScript from the beginning to the present, so we can use the convenient development syntax provided by the higher version of ECMAScript at will. Bable then helps us convert the JS code from the lower version of the browser to the lower version, but we know that the lower version of the JS code emulates the higher version of the JS code requires a lot of JS code to do the underlying code implementation, which is a lot of code volume work. This leads to our older browser users loading the same huge amount of JS code because some of them are using older browsers

Guess 1 (optimize the packaging volume of public third-party JS libraries) : Can we pull these third-party JS libraries out? It is not included in our project, because we only use the code function of the third party library, we all need network request, we know a thing called CDN node acceleration, you may say that CDN node acceleration is charged, A good thing to mention here is that a large number of our common JS third-party libraries have common CDN node acceleration, but they can only be used to pull out of the common JS third-party library, our own project code is not able to enjoy the CDN node acceleration [Guess 2 (start modern mode packaging results optimization)]: We vue packaging results can be divided into two kinds of packaging as a result, a don’t do Bable code compatibility, our code will be much smaller volume, then load in high version users visit when he is not Bable code, we provide the low version of the browser to access, because of compatibility issues, they have Bable to load our code, Doesn’t this guarantee the experience of users of older browsers, but also the compatibility of users of older browsers?

So how do we do that? The following two optimization methods will be introduced in detail ↓↓↓

2.2 Optimize the packaging volume of public third-party JS libraries

Here we recommend a CDN acceleration (public) with a large third-party JS library:BootCDNInsert a picture description hereWe can find a large number of third-party JS libraries deployed on CDN, such as Vue, VUe-Router, Vuex, jQuery and MockjsHere we can tinker with the VuE-CLI webpack configuration:

For details about how to add a customized Webpack configuration to vue-CLI, see the official vue-CLI documentation

// vue.config.js
module.exports = {
  configureWebpack: {
    externals: {
        vue: "Vue".vuex: "Vuex"."vue-router": "VueRouter".axios: "axios".jquery: '$'.mockjs: 'Mock',}}};Copy the code

In fact, we do not need to mock this way, because mock does not exist in real project development, it is only convenient for our front-end interface data simulation tools

Since we add it like this, we will cause the development environment to do these operations, which will affect our development efficiency, so we need to distinguish the development environment configuration from the production environment configuration, we can refer to the above47. Customize webPack configuration in VUe-CLIConfigure the configureWebpack into the production configuration, not the development configurationSince we pulled them out to use the third-party JS library, we need to manually import the third-party JS library of the CDN node in the page ourselves:

Why would we want to have a Nodejs template syntax around at this point? Since the resources introduced by our script are not needed in the development environment, we determine if the current packaging environment is production, which is why we have these script tags that would not exist in the development environment

HTML for the production environment: HTML for the development environment:Because we configured the replace global variable in Webpack, we need special handling in the use syntax:

vur-router: vuex:Axios, Vue, and Mock are not considered because they overlap with variable namesThen we pack and find that the JS volume of the third party library in our project has been removed:If the project is compressed by Gzip, it becomes 44.4 KB size height. Using the common CDN, we realize the optimization of packaging volume

Note: In the world of Web security, JS is actually the biggest security vulnerability, because we use the CDN given by others, so we reference others’ JS code. At this time, we have not thought about it, the JS code of our website is given by others, and if others change the JS code, then cross-site script execution can be realized. So our website security from where to start, so big factories have their own CDN completely not panic, this is just a hidden danger, may happen. After all, power is in your own hands is the most comfortable

2.3 Start modern mode of packaging to optimize different browser versions of the user

This optimization is taken into account and done for us in vue-CLI, where we simply add CMD code to build execution in package.json configuration file--modernYou can:

Our project might be bigger than one because it packs two different results, but vue has tweaked our HTML to optimize the loading by allowing users to load only their own small JS codePrefetch has a lower priority than Preload, prefetch means I’m not using it very much right now and you load it slowly, preload means you have to load it at the beginning because I’m in a hurry, right

This way of optimization is very convenient, there is no need for us to do anything, vuE-CLI does it for us at packaging time

Say so many package to load the above optimization, but the largest number of users access to influence, our component performance, we have a small project components may have hundreds of components, not to mention the big project, so we component of optimization is a very important optimization, then we have to optimize left left left on component

2.4 Optimization of component loading

Let’s think about where do we normally load components? Is there some component that we load when we match a route, right? So how do we introduce components in vue-Router? Do you introduce components like this:We think, if the import is on whether or not our routing by matching code read from above, will in all our components, but we have a lot of components are now used less than ah, this time it will be loaded into our components, very influence our user load for the first time the problem ah, * * we can achieve, When I match this route is he loading this component? ** This is what we mean by asynchronous component loading

To implement asynchronous component loading, we simply need to change the way component import is written:We all know that import returns a promise, so import is asynchronous, and then we read the official documentation that component can receive not only a component configuration object, but also a function that returns a component configuration object by executing that function. That’s a qualitative change. We used to do the placeholder with the actual component, but all we have now is a few lines of function code to do the placeholder, and I will execute the function and get the component when I match

The essence of a component is a component configuration object. If we recall the script part of the vue file, do we always have an export default {

} This is exporting the configuration in our component

Can such first loading efficiency be fast?

Vue’s official documentation also covers asynchronous components, and there are many better ways to configure them

2.5 Optimized first screen display

As we all know, all dom in our VUE page is executed by JS and then rendered. Our HTML code is actually only dozens of lines, so if we load JS slowly, the page will have a blank screen stage, which will not give users a very good experience. Can we show some to the user?

We can add a load in project dynamic effect of the animation image in a static file, and then in the HTML file app div to join the pictures make it just a matter of, we can in the app div write casually, because we know that when an element is as a template, it will all be covered the inside of the original content, So let’s just write:When our JS loading is completed, our IMG will be covered, so this effect is particularly good, because static resources are directly in our project, so the loading efficiency will be particularly fast, so try to make the size of the picture smaller, so as to better improve the efficiency of the project

3. Summary

Optimization scheme:

  1. CDN extract common library
  2. Use modern packaging
  3. Using asynchronous components
  4. White during processing

Above is all the Vue optimization scheme, if any help to you can move your hands three even, a key bloggers will not be sent, will meet on the big questions 】 【 【 】 will commonly used algorithm, [will high concurrency solve], “optimization” and other special columns for everybody to learn to watch, if you have more and better optimization welcome comments! The blogger will test it first time and then summarize it for everyone!