Website performance is a platitude problem, but this is not a simple easy to do things, need a little bit of gnawing, recently gnawing, and then found that there is something in the middle, come to share.

I divide this into two things.

  1. Other people’s performance
  2. Development debugging performance

Other people’s performance

This other person refers to “the performance of your application running on someone else’s device.” It’s important to know, for example, “The customer teased you: We usually use Chrome to do development on PC, thinking, “I open it every day, the average is about 1~2S, not slow at all.” No matter how the customer explains, you take out your mobile phone, still very fast, so the customer recorded a screen for you. It is very slow indeed, and your mind is broken at this time.

Therefore, window.performance is required to report performance. There are many ways to do this without going into details, but do it (and error monitoring).

Look at the picture to learn

Own performance

When we are still in development, before the line, it is best to test their performance, on the one hand is to do a performance test, on the one hand (performance +bug) ≈ personal ability, and the company’s position, every day the bug constantly, beside colleagues are quick embarrassed to know you are not.

usechromeThe toolsaudits(now calledlighthouse) for performance metrics and recommendations

Click on generate report

The following results are obtained

76, looks like a good pass, but there are some yellow dots, you can look at them

Different scores may be scored on different devices and networks, with emphasis on recommendations and optimization

First of all, there are six items below. Click on the right side of metrics to toggle how the time was spent and how it was optimized.

Then we can look at specific proposals.

  • Eliminate render-blocking resourcesRoyal elder sister to save1.36 s

“Resource blocks the first drawing of the page. Consider delivering critical JS/CSS inline and defer all non-critical JS/ styles.”

The description is very detailed:

  1. Resources block the first draw and need to be optimized
  2. Consider inline loading key styles
  3. Lazy loading is not a critical style
  • Enable text compression

    “Text-based resources should be compressed (gzip, Deflate, or Brotli) to minimize total network bytes.”

    1. You can opengzipCompress to reduce the number of bytes transferred

. Skip the third term and look at the fourth term, which has to do with the way I’m going to use it

  • Remove unused JavaScript

“Remove unused JavaScript”

It’s nice to have the files listed.

  1. Analyze the packages you use and try to find a way to import only the components you need from them.
  2. tree-shaking

The specific way, we can look at the next analysis method.

Along this line, item by item… If it doesn’t, when you expand it, there’s a Learn more, see that? Click on that.

usecoverageTools to see the degree of code redundancy easy to dotree-shaking

You don’t need to install anything, just Command+Option+J and type coverage to see it

Then click reload and you’ll see a panel like this (I’m using Edge here, Chrome 8G doesn’t work).

85% of the code is not needed. Some third-party libraries provide several versions of the code, such as xxx-min.js, or xxx-runtime.js or xxx-core.js

Here’s another tip: if you do start tuning, it’s best to measure it once you’re done to see if it’s moving in the right direction.

useperformancePanel analysis Performance This section describes specific performance

This is the most complicated of the three, so I hope you can be patient and stick to it.

Let’s start with a quick picture of the panel (from the web)

To start the analysis, click the second refresh button in the upper left corner of the diagram “Reload and analyze”.

You can then click the first button to stop the load

You’ll get a little bit of data like this. Take your time.

First take a look at the abstract:

The script executes for 650 milliseconds

  • 27 ms rendering
  • 07 ms paint
  • 1196 is free

It doesn’t look like there are any major performance issues with the first draw, but the FPS panel above is still red, which can be analyzed by adjusting the boundaries of time to see what happens in a small chunk of time.

After selecting, look at the main axis, one task appears red, and specific information appears when the mouse clicks, and the long task takes 54.67 (I have read chrome’s suggestion here). If the task is longer than 50ms, it is considered long. Then switch from bottom to bottom (that is, call the stack in reverse, usually the bottom of the stack is the trigger method. Top of stack is the deepest method).

You can see the specific execution time of each function, but this is the main part of the framework, and then you can click on the specific code to optimize.

Then you can analyze the specific business time-consuming

This place, is a long list, appears red frequency jitter, look carefully, the bottom of the stack is a timer. It is specified to reach 55.7ms, and there must be a bit of a problem with this part.

What is a long mission? Why are there long missions?

  • task: taskEach frame counts as onetask

When we play LOL, the FPS in the upper right corner is usually 100+, which means 1s/100+, and if it drops to 20+, I don’t need to tell you more. Current devices are basically 60fps+, if 60fps is needed, 1000/60=16.66ms. Remember where you saw the maximum 50ms, if it takes 50ms to generate a frame, then 1000/50 = 20fps, this is on PC, mobile phone may be slower ~

Oh, and there are 120fps phones these days

Finally, the performance of the virtual DOM is really good, even without a lot of code-level performance optimization, still good performance.

The forehead. I think I’m giving something away…

  • We are currently doing a large level of network optimization!! CDN + micro front end + BFF layer
  • Data seen by BFF layer (95 interfaces all respond within 800ms)

At this point, you have a general idea of the performance bottlenecks in your application. Look for them and try to solve them.

Finally, writing is not easy, so please give a like or leave a comment if you have learned something. I hope everyone can be what they want to be!