Page stuck due to event congestion

Overview

Last Thursday (2021/12/09), feedback from suppliers began to enter the merchant quotation page one after another. The public module (menu bar) of the seller center page has a lag problem, but the development and testing are all in the transfer test, transfer, and grayscale stages. This performance issue was not found.

analyze

First of all, we need to understand the implementation structure of the page. The public module ftl and the right content area ftl of the seller's quotation page are integrated <div id="seller-sidebar" class="menus"></div> the <div id="seller-topbar"></div> of Sitemesh ftl Introduced implementation of seller-react-frame.js to inject element content into related element tags.

In addition, the injected element content is not implemented in seller-react-frame.js , but other scripts are introduced in this script. These introduced scripts are generated by webpack after React implements the topbar、slider component.

The content area on the right is actually implemented using the freemarker template engine. The data is injected into the page from the backend, which is equivalent to server-side rendering.

After understanding the situation of the requested page, let's take a look at the performance analysis of network and performance

network analysis

As can be seen from the network panel, the original size of a script in the common module is 1.3M , the compressed transmission size of gzip is 375KB , and the reading from disk cache (disk cache request) takes 2.78s , and clearing the browser local cache 2.88s CDN The original size of other scripts in the public module is very small, only a few KB , and the request time is only one or two hundred milliseconds.

Obviously, this script is too large and requires code splitting. In addition, reading from disk cache is also time-consuming, so use memory cache (memory cache) instead, because memory cache faster.

The memory cache is stored in RAM and is faster to write and access, but is cleared when the computer is turned off or some other condition. The disk cache is written to the hard disk, which is slower to read and write, but remains on the disk.

performance analysis

Then through Performance detect the page performance, it is found that there is a task that takes a long time to execute in front of the script task of the common module (menu bar). The function of this task is to initialize the fourth-level address and brand init ZTree.js The event complexity of the method initialization tree node is relatively high, so we see that the detected execution time is longer ( close to 3 seconds ), thus blocking the execution of the common module script task.

In view of business requirements, the four-level address tree node can not be initialized when it first enters the page, so I put its script request and execution in the onload function, but through the above figure, it is found that the four-level address initialization is performed before rendering the menu bar, Why is this?

The network request panel looked at the order in which the scripts were obtained, and found that the common module script was obtained before the fourth-level address script, which made me even more confused. At this time, I thought that the menu bar on the left was implemented by React , and the menu bar data was obtained through the interface, instead of the freemarker template engine injecting data through the back end, and then I checked and obtained the menu interface and found that in order to obtain the menu bar data, it turned out that There are serial calls of three interfaces, because the serial calls of the interfaces cause the task of rendering the menu bar to be added to the task queue later than the task initialized by the fourth-level address, and the initialization of the fourth-level address takes a long time, which causes the user Perceived that the menu bar on the left is stuck.

solution

(1) Code splitting the script of 1.3M in the public module;

(2) Optimize serial interface calls in scripts;

(3) After setting the four-level address initialization

(4) Change from reading from disk cache to reading from memory cache (guess, no actual solution has been found);

(5) Because the network request is time-consuming and unstable, it is impossible to ensure that the event loop of the rendering menu bar is initialized before the fourth-level address tree node. Therefore, after the request for the menu bar interface is successful, can pass postMessage or custom event notification initialize the fourth-level event loop address tree node;