Example analysis: Performance optimization of "Qichu Encyclopedia"

Qiqubaike has undergone a major revision after the New Year. Whether in terms of content or program architecture, the revision uses the MVVM concept of Vue.js, which has accelerated the development process a lot. However, after the revision, obvious performance problems appeared, and there was a relatively obvious page freeze, so we made a special performance optimization. This article mainly introduces how to use tools such as Timeline Profils in Chrome DevTools.

1. Component granularity is increased

The first thing that comes to mind is to use Timeline to look at it:

The Frames situation is normal, but notice that the memory usage is almost 17MB, which is significantly higher than the 12MB before the revision (due to space constraints, I won’t show the picture). So let’s continue to track down memory-related issues and use the Profiles of the Chrome developer tool to see the current memory usage:
Open Chrome Developer Tools -> Click the Profiles control panel -> Select Take Heap Snapshot -> Click Take Snapshot

After checking, I found that there are 9 or 10 listItemHead, listItemImg, listItemMeta and listTuwen component objects respectively (9 are due to business logic issues).

Vue.js supports component system, so in order to improve reusability, I define a card as a component, which is composed of several components.

The card itself is a listTuwen component, which includes three components: listItemHead, listItemImg and listItemMeta.

Next, let's study what the corresponding columns in the snapshot table represent.

An object holds memory in two forms:

• Direct ownership

• Indirect Quote

Corresponding to Shallow Size and Retained Size in snapshot respectively

Shallow Size

Shallow Size represents the size of memory directly held by the object. A standard JS object usually holds memory used to describe its own logic and store direct values ​​(attribute values). Normally, only strings and array types may have a larger Shallow Size.

Retained Size

Retained Size represents the memory size occupied by other objects referenced by the current object. When the current object is destroyed, this part of the memory will be released.

The homepage of Qiqu Encyclopedia can load 30 times with a total of 300 cards. We compare the situation after loading 30 times with the situation when we just entered the homepage:

The memory usage has soared to 70MB. We switch to the Comparison view (red frame) and select Snapshot 1 (red frame).

The #New column shows that the objects of the three components increased by 290 (289 of them are due to business logic), and the Size Delta column shows that the objects of the three components each increased by nearly 7MB of memory, which adds up to 20+MB.

Therefore, we can draw the following conclusion: Components that are reused in large quantities on the same page should not be nested inside other components, otherwise the memory usage will increase rapidly as the number of components increases.

You can see that a Vue component object references a large number of other objects, including directives, watchers, etc., as well as a series of getter and setter methods.

The solution is to not use components inside the card. A card only has this component, and use other methods to improve the reusability of the code.

Finally, let's compare the optimized results:

After the bottom loading is completed, 300 cards occupy about 40M of memory. Although the objects of the listTuwen component occupy a lot more memory, the overall memory usage has dropped by 40%, and the optimization effect is obvious.

Remove unnecessary DOM outside the viewport

It is easy to conclude that the fewer DOM elements on a page, the less memory it takes up and the better the performance.

Referring to the practice of Taobao mobile search results page, we can remove the invisible cards outside the window, and insert them into the display when these cards are scrolled back into the window (or the scroll position is close to a certain pixel value of the window). The number of cards in the list remains at a constant value instead of growing linearly.

From the code of Qiqu Encyclopedia Online, we can see that the number of our cards remains at 30, that is, the DOM data is constant and will not increase as the page is scrolled down.

Next, let's take a look at the memory situation to verify the effect of our doing this:

Memory curve of the Timeline tool before and after optimization:

The memory curves are all sawtooth shaped, and garbage collection is triggered. However, the slope of the curve after optimization is 2° less than that before optimization, that is, the memory usage increases more slowly.

In addition, here is the comparison of Profiles before and after optimization ('DOM' is used as a keyword for filtering):

After memory optimization, the memory usage was reduced by nearly 10M, the DOM data was reduced by 10 times, and the memory usage dropped by 25%.

Lazy loading of images

Before we proceed to this optimization point, let's first learn about the Timeline control panel.

It is best to use the browser in incognito mode and disable all irrelevant plug-ins, because plug-ins will also take up memory and affect the test results. If you need to record network requests, it is best to disable the browser cache as well.

A picture stolen from the Internet (source):

There are three modes to switch focus:

• Events: Displays records of all events

• Frames: Displays the number of frames rendered by the page

• Memory: Displays the memory status of the page

Here we focus on the Frames mode.

Each frame of the page is drawn by the GPU. Its maximum drawing frequency is limited by the refresh rate of the monitor. In most cases, the maximum drawing rate can only be 60 frames per second (fps), which corresponds to 60Hz of the monitor. Therefore, in the test of page performance, 60fps is a very important indicator, the closer the better.

There is a constant mentioned here - the screen refresh rate is 60Hz .

What is the relationship between 60Hz and 60fps? There is no relationship. FPS represents the frequency of GPU rendering images, and Hz represents the frequency of the display refreshing the screen. For a static image, you can say that the fps of this image is 0 frames per second, but you can never say that the refresh rate of the screen is 0Hz at this time, that is, the refresh rate does not change with the changes in the image content. Whether it is a game or a browser, when we talk about frame drops, it means that the GPU rendering frequency is reduced. For example, it drops to 30fps or even 20fps, but because of the principle of visual persistence, the picture we see is still moving and coherent.

Frames mode Frames in the mode is "frame". "One frame" (a column in Frames mode) represents the work that the display must complete in order to display the content within one frame (), including executing JavaScript, handling events, updating DOM, changing styles and layouts, and drawing the page.

There are two horizontal lines running through the Frame view, marking the 60FPS and 30FPS benchmarks respectively.

Note that some columns are partially blank or gray, representing:

• Blank: Free time

• Gray: Unrecorded activities can be understood as some work in C++ inside the browser, which has nothing to do with front-end JS and rendering.

Now let's take a look at the Frames of the project:

There are quite a lot of columns that exceed 60fps, and most of the columns are green.

Let's first explain the meaning of the column colors:

• Blue: Network and HTML parsing

• Yellow: JavaScript scripts are running

• Purple: Style recalculation and layout (Layout, Recaculate Style, Update Layer tree)

• Green: Paint, Composite Layers

So we spend most of our time drawing. Let's select some taller columns and see what characteristics they have:

We see that there are some empty green blocks and solid green blocks, like this:

Drawing is divided into two steps: drawing and rendering

• Drawing: This contains the set of things you want to draw, using the CSS on the element.

• Rendering: Analyze the things you wanted to "draw" in the previous step one by one, and use the GPU to assemble the actual pixels that fill these things.

I translated this part very poorly because I don’t quite understand the specific meaning, so you can read the original text → About the green bars

And Painting includes these events:

Event Description Composite Layers Triggered when Chrome's rendering engine completes merging image layers Image Decode Triggered when an image resource is decoded Image Resize Triggered when an image is resized Paint Triggered when the merged layer is drawn to the corresponding display area.

Based on my observation, I found that the taller green columns generally include multiple Image Decode events. The image loading triggers this event, which in turn generates a large number of Rasterize Paint events. So I guess that the images should be loaded separately instead of loading 10 images at a time. In this way, the events have to be dispersed, and the tall columns can be split into multiple short columns, which can further improve the smoothness.

I won’t go into detail on how lazy loading of images is achieved. You can refer to the Taobao homepage for similar effects.

Finally, let's take a look at the optimized Timeline:

This situation has already reached a relatively ideal state, and the actual operation is also relatively smooth.

But it is worth mentioning that the PM did not adopt this optimization method in the end, because after experiencing it, the PM thought that lazy loading of images would make users feel stuck, not the actual sliding stuck, but the overall experience stuck. So from the perspective of user experience, our optimization plan did not adopt lazy loading of images.