Background:
I joined my current company in October last year. Record the front-end code optimization done in the company. If you also encounter the same problem, I hope it can help you, or you can communicate in the comment area.
Build a private server
Background
When I joined the company, the back-end already had a private server, but the front-end did not have a private server. The
front-end had a business component library, and the frequently used components were written into a gitLab warehouse. When new functions or bug fixes were needed, they needed to be first
The problem of dragging it into the project after building
will cause trouble. When the component library is updated, it can only be put into the dependent package after building it locally.
There is no concept of version. Only the latest code can be used. If there are destructive changes, the consequences will be unimaginable.
Improvement
Build a private server. You can read my other article about the introduction and usage of front-end private server verdaccio
Build tool (webpack) optimization
Background
When I first came to the company, I asked an old employee how to start the front-end project (after installing it myself, npm run serve), it started, but the interface call failed. The old employee sent me
an nginx installation package.
This is what I want to do. Well, I went to communicate in person, and it turned out that when starting the project, I needed to start an nginx locally for interface forwarding.
At that time, I was thinking about what advanced functions this company used. Is there any forwarding that webpack's devserver cannot implement? Forget it, run away first and ask later.
Later, I looked at the nginx configuration and just forwarded all interfaces, and then added a devserver to solve the problem.
After solving it, other front-end developers also said that if they had known it was so simple, they would have done it a long time ago. . .
Startup time optimization
Background:
A front-end project has been iterated for more than 3 years (some functions in it have also been outsourced, and the code is messy and voluminous). It is very large and can be said to be a boulder project. The startup time reaches about 120 seconds (there is still cache in node_modules). scenario (not the first startup), if you use a company-configured window computer, it will take 5 minutes
to test again.
Directly look at the optimized effect picture.
You read that right, it is 50 seconds longer than before optimization. You may have this question (I know you are in a hurry, but don’t be anxious, please continue to look down). Start the third time for the second
time
. Secondary startup
principle
HardSourceWebpackPlugin is a plug-in of webpack, which provides intermediate caching steps for modules. In layman's terms, it caches some files to your node_modules.
The cached directory is node_modules/.cache/hard-source.
In the process of solving the problem, I also tried many webpack plug-ins (the effects of multi-threaded packaging, happyPack, etc. are not obvious). Currently, only the hard-source-webpack-plugin[2] has the greatest effect in the test.
The HardSourceWebpackPlugin document [3] lists some problems you may encounter and how to solve them, such as hot update failure, or certain configurations not taking effect, etc.
Usage method
1. Install dependencies.
Copy the code
npm install hard-source-webpack-plugin -D
2. Modify the configuration of webpack:
ini
copy code
//webpack.config.js
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = { //... plugins: [ new HardSourceWebpackPlugin() ] }
Packaging time optimization
The background
is still the Jushi project above. The startup time is about 2 minutes (the desktop computer issued by the company is 5 minutes). The project uses vuecli, and the packaging time is more than 20 minutes. Moreover, Jenkins often fails to build, and the packaging command needs to add the maximum memory limit.
css
copy code
node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js build
I asked my colleagues why it took so long to build this project. How do you usually operate it when it goes online?
My colleague also answered me very sincerely: We will pack the front-end with several people at the same time, and then start the game of Honor of Kings. Whoever packs it faster will use the package made on his computer. . .
In this case, there is still a problem. If the nodejs version of the personal computer is different, or someone forgets to pull the latest code, the release will fail. It is too closely related to the individual. We should trust the machine more and use Jenkins. Pack
As a result,
the packaging time was optimized from more than 20 minutes to 5 minutes.
Optimization plan:
Added a configuration item so that the css is not extracted separately.
Although
only one line of code was added compared to before, it took more than half a day to find out the real reason.
1. First find out the time spent by the plug-in and loader, and see where the time is spent. The speed-measure-webpack-plugin plug-in can measure the time spent by each plug-in and loader.
Usage:
No useful data was found after the test.
2. Think about why the development environment takes 5 minutes to start, but how can packaging become more than 20 minutes? (Think about it. SourceMap and eslint are not enabled by default when packaging. Logically speaking, it should be faster. Why is it slower?)
3. The project uses vuecli (3.5.3). Has vuecli made some changes to the default values in webpack? Then check the configuration one by one to see which ones are enabled for production and not enabled for development/4. Found
it I haven't found anything suitable for a long time. I wanted to upgrade vuecli to 5, but I was worried that a series of component dependencies would have to be upgraded and the stability of the project was not good enough, so I continued to search.
5. Finally found the object of suspicion. After testing, I found that the construction time will indeed shorten the
guess. The project is a Jushi application. There is too much code in it, so it takes too long to split the css to form separate files. The development environment This parameter is turned off by default, so the startup time is 5 minutes. When packaging, this parameter is turned on, which causes a large number of files to be written, so it is slow.
Code Optimization
Icon Library Optimization
Download Experience Optimization
Background
There is a function in the project for learning courses, which requires a download function. The current process is that the back-end returns a file stream, and the front-end converts the file stream into a link and then downloads it.
A 600M video requires about 1-2 minutes of loading time. Currently, loading is added during downloading, causing users to be unable to operate during this 2 minutes, which greatly affects the user experience.
Q: Why can't you use window.location.href directly?
A: Video courses store IDs. There is a separate service on the backend which is a file service, which requires gateway authentication. The current authentication is placed in the header of the request.
The goal
is to call the browser's default download just like downloading files from the official website of the software, as shown below, without affecting the user's operation.
Solution
After checking some information, location.href or window.open can achieve this effect, but how to solve the problem with token.
I thought of storing the token in a cookie. When the user initiates a request, it will be brought by default. The backend can expand the download interface to support obtaining it from the cookie.
Jenkins optimization
Background before optimization
and after optimization 1. People in the team reported that every time the Jekins front-end project was packaged, nodejs filled up the server's memory, causing the packaging to be queued to see if the memory could be reduced/ 2. Install must be performed every time, can Is it the same as the local one? Only the newly installed packages are updated. 3. There is another big reason why the packaging script is written with the help of the back-end. The back-end does not understand the packaging of the front-end, and the front-end does not understand the packaging script, resulting in a gap in the intermediate information. Improve me I don’t know much about Jenkins, so I can only learn it by myself. My previous company was managed by a professional operation and maintenance team, which was a bit embarrassing.
Check the official documents and packaged scripts and be thick-skinned. Keep asking the backend and slowly understand. I found the reason why I had to deleteDir() every time I packaged it. I checked the official explanation to clear the workspace. I guessed whether this was the cause.
After deleting this script, I found that it was faster every time. Each time the workspace is cleared, when the script is executed again, the installation must be started from 0, resulting in disk reading and writing. This solves the problem of occupying the CPU and installing from zero each time. At this time, two scenarios should be considered:
1
. When new dependencies are introduced, will they be successfully installed?
2. When dependencies are upgraded, will they be successfully upgraded?
No problems were found during testing.
Packaging pipeline optimization.
Previously, npm install and npm run build were unified into the pipeline Protal Npm Build. It is inconvenient to calculate whether the installation package is slow or npm run build is slow.
Improvement
: Separate npm install and npm run build, and submit .npmrc (the warehouse specified in .npmrc as a private server warehouse) to the warehouse (so that when installing, it will be installed from the private server first). Packaged products can be downloaded. Members in the group want to
publish
production When successful, directly download the compressed package from the test environment and update it to the production environment.
Check the official documentation [6]. During the success, upload the compressed package to the server
yaml
copy code
archiveArtifacts artifacts: 'dist/*.tar.gz', fingerprint: true