Front-end performance optimization for actual combat

As the bottleneck of Web projects, performance problems have been criticized by front-end developers. Love the high performance optimization experience, hate the fact that it’s hard to analyze and locate.

This paper introduces the analysis process and optimization results of performance problems in practical projects for reference of readers with similar problems

The background,

1.1 Project Background

Vue2 + Element-UI + WebPack4 Single-page Web application The number of page routes is 3000+, the overall volume is 300M+, and the front end colleagues are involved in the complex management system of code development standards

1.2 Background

Enter the home page of the system, open the menu list, arbitrarily click the menu list menu, click to enter the sub-menu, jump to the corresponding module page. Click the menu for the first time and wait about 17 seconds to jump to the corresponding menu page. Click the menu page to jump, and the browser enters the state of suspended animation. When you click the page, there is no response.

Second, process analysis

Question 2.1 points

Factors affecting route hops After consideration, there are only two possible causes:

  • Does the route jump lag caused by the large project volume and too many page routes?

  • What about browser feint for code reasons?

The cause of excessive page routing? The project routing adopts the route lazy loading mode

export default new Router([
    routes:[
    	{
    	    path:'/Login'.name:'Login'.component:resolve= > require(['@/components/Login'],resolve)
    	}
    	...	
    ]
])
Copy the code

After Webpack compilation and packaging, the code of each routing component will be divided into a JS file. These JS files will not be loaded during initialization, and the corresponding JS file will be loaded only when the routing component is activated.

This article records the import process of asynchronous components. If you need to view it, you can read it by yourself.

Once you understand the reason, take the root cause and place it squarely at the code level. In the middle and later stages of project development, it is not difficult to analyze performance problems through code logic. Unless you are fully involved in the development, the overall architecture code is very familiar, which probably exists… Even if it exists, I am afraid it is “not aware of the true face of lushan Mountain, only the body in the mountain!”

We used the Performance analysis panel tool provided by Chrome to record and analyze the analysis process.

2.2 Analysis Process

Click to jump to end Record the performance analysis report as follows:

A) Mark S area, that is, simulate the whole process of the user clicking the menu normally until jumping to the corresponding module page25.27Seconds, the longest execution time for Scripting block-js18541Ms,idle block - Idle time6168Ms, other blocks within the acceptable time range do not participate in this analysis. B) Marked P area is the memory statistics broken line map during the jump. The ups and downs in memory occur at2000Ms - After clicking the jump,2000After MS, JS Heap memory, Memory consumed by Nodes elements, and memory consumed by Listeners are increasing continuously and reaching the highest point c) mark t1-T5 area calling process of main thread task call stack. T1 task is obviously a mouse movement event process; T2 task is the call stack process of the menu page after clicking the menu; T3 task can be seen as the call stack process of click menu; T4 task is a jump page lifecycle execution call stack process; T5 task is the page asynchronous request after the page redraw call process. D) AREA N1-N2 refers to the process of network invocation. N1 is the menu permission check performed at the route guard during the jump route, and the asynchronous interface that requests it determines whether the current jump menu belongs to the current login person. N2 is the process by which the page to jump to asynchronously requests page data; N1 is between T3 and T4, N2 is between T4 and T5 e)F1-F5 is the frame rate alarm, generally FPS is greater than or equal to60When, the page will be very smooth, below60When the page will be stuck; F1-f5 have different degrees of alarm, corresponding to the page of a long time delay.Copy the code

After collecting and analyzing the above indicators, it can be seen from the flame diagram of main thread execution that the main time of the whole process is spent in the call stack execution process of T4-jump page life cycle, and magnifying the flame diagram of call stack execution at T4 stage:Since the call stack is very deep, only the top part of the schematic diagram is captured here. Here, it slides directly to the bottom. Here, the longest call stack is illustrated as shown in the figure below:At the bottom of the stack, execute created, initGlobal, anonymous2 times; The green areas are frame codes, and the other colors are the areas we should pay attention to. Click these four areas respectively to see the detailed information under THE S panel, as shown below:

Click the code link in the P panel again to see the actual code.

From the above analysis, the optimization ideas are as follows: 1. Find the invocation process of created, initGlobal and anonymous-session.Js in the project; 2

2.3 Solutions

Through code analysis, it is found that a mixins-global blend has been added to the main entrance of the system. In the flame diagram, the functions executed at the top of the overly long T4 and T2 call stacks are all life cycle functions of mixins. Check vUE official website – global mixed data as shown below:

We print keywords in the global blend lifecycle Created,



Then watch the console print,

This function will be executed when each VUE instance is created. Each VUE instance here can be understood as a vnode instance. Vnode instances of different types represent DOM elements of different types. Vnode instantiation is the corresponding vNode class that exists in vue.js. This can be interpreted as a real DOM node, which we won’t go into here.

At this point, if we replace global mixing with local mixing, can we solve this performance problem?

Just do it. After modifying the code, simulate the user. Click to open the menu list.



Analyze the above again:

A) the whole process of S region6736Ms, idle- The longest idle time of a thread5212Ms,Scripting- JS execution time947Ms, has reached the acceptable time range b) two peaks in the P region, peak1Appear in the2000Ms left and right view thumbnail is open menu list process; peak2Appear in the4500Ms left and right to view the thumbnail is to click the menu list to jump to the corresponding page; Time point moves back JS HEAD- heap memory drops and flattens out, Documents element drops and flattens out to indicate page rendering is complete; Normally, T1 and T2 tasks appear in area C)T during the execution of Nodes, and T1 text indicates the time spent for mouse movement events448.12Ms; T2 is the initialization event time of the jump page326.84Ms; D)N LAN request process; N1 is the menu permission check performed at the route guard during the jump route, and the asynchronous interface that requests it determines whether the current jump menu belongs to the current login person. N2 is the process by which the page to jump to asynchronously requests page data; N1 was between T3 and T4, and N2 was between T4 and T5. Corresponding to the single thread JS execution principle. E) The mouse movement event corresponding to the page F1 in the frame rate recording area F appears red block-millisecond lag at the end; F2 corresponds to the initialization event of the jump page, and there is a red block-millisecond lag at the end of F2Copy the code

Then check the enlarged picture of the flame at the bottom of the stack as follows:



At this time, the events at the bottom of the stack are basically the framework call process, and the two obvious pink microtasks in the figure are also completed within a maximum of 3.22ms, as shown below

3. Comparison of optimization results

  • Before optimization:
Simulate the overall consumption of users clicking on the menu to jump25.27s; Scripting - js18541ms; Idle - Idle events6168ms; Caton event15.98s
Copy the code
  • After the optimization:
Simulate the overall consumption of users clicking on the menu to jump6878ms; Scripting - js947ms; Idle - Idle time5354ms; Caton time326.84ms
Copy the code

The global variable of global mixing causes the system to stall. Replace global mixing with local mixing. The process of analyzing and solving the problem was exhilarating. It took 8+ hours to change the code, 720+ files were modified, and the whole process was a blur, telling myself that it was almost over, it was almost over… Thankfully, the whole test and verification process was relatively smooth! Clap, clap, clap.

Four,

Performance issues, which are the focus of Web project development, can be prevented in advance. Yahoo’s 35 catch-22 rules are the industry standard, and there are many articles on the web that analyze yahoo’s catch-22 rules for reference. If possible, try not to put the performance optimization in the middle and late stage of the project development, the middle and late stage of the project architecture, technical solutions are basically mature, if at this time because of the performance optimization problem, the need to adjust the technical solution, then the loss is outweighed by the gain. This document describes how to use the Performance analysis panel provided by Chrome to analyze and resolve problems. The analysis process, for example, provides reference for readers with similar problems.