This is the 11th day of my participation in the August More Text Challenge. For details, see:August is more challenging

There are too many articles on performance optimization on the Internet, all saying how to optimize code optimization and so on, which everyone knows, and it is impossible to use all of those in the actual work, but should be targeted to our project optimization, don’t you think?

Such as

What about front-end performance optimization?

What do you do for performance optimization?

And so on and so forth. It’s just the same thing

All right, put the medicine on first

As for performance optimization, it’s a particularly big direction, because every project can optimize at different points, and every framework or client can optimize at different points

In general, under the B/S architecture, the front end requests the back end, the back end arranges the data and returns it to the client, and then the client processes the data and displays the interface to render, which is a general process

So we’re going to optimize based on this process, and basically the points that we can optimize, there are only two broad directions

One is faster network communication, that is, between the client and the server, the time the data is on the road during the request or response makes it faster

The second is faster data processing

  • After the server receives the request, it can sort out the data the client needs more quickly
  • When the client receives the response data, it presents it to the user faster and processes it faster during interaction

Then! Start blablabla…

Faster network communication such as: CDN do global load balancing, CDN caching, domain name sharding, resource merging, Sprite chart, font icon, HTTP cache to reduce requests; Also gzip/ BR compression, code compression, reducing headers, reducing cookies, using HTTP2, using JPG /webp, removing metadata, and more, blablabla…..

Faster data processing such as SSR, SSG, pre-parsing, lazy loading, on-demand introduction, on-demand loading, CSS above, JS below, semantic tags, animation can use CSS without JS, event delegate, reduced reordering, and so on code optimization, blablabla…..

.

Please summarize the above in one sentence to the interviewer

Request optimization, code optimization, and packaging optimization are all routine operations, like yahoo’s 34 Catch-22, and don’t mention the things you already know

Because the optimization point of each project may be different, so the optimization is mainly based on their own project

Or talk to someone about framework optimization, in-depth principle is also very good

What to optimize mainly depends on the developer tools of the browser (Chrome for example) Lighthouse and Performance

Lighthouse is about generating performance analysis reports. You can see the data and ratings of each item and suggest points of optimization, such as where is the picture too large

Performance is runtime data, and you can see more detailed data. Things like blocking, things like rearranging, things like redrawing, it’s going to show up, it’s not detailed enough

Then, according to these reports and performance indicators, we will continue to optimize our projects

Lighthouse

Open it directly in Chrome Developer Tools

Or Node 12.x or later can be installed on the local PC

npm install -g lighthouse
Copy the code

Once installed, a single line of code is enough to generate, say, a performance report for nuggets, and then an HTML file is generated

lighthouse https://juejin.cn/
Copy the code

No matter the browser or the local installation, the generated report is exactly the same, an English HTML file, a translation for everyone to see, as shown in the figure

As shown in the figure, there are five major items in the analysis report, each of which is 100 points full mark. Then, the following is to expand and explain each item separately

Still look at the English version, a programmer must develop this habit

As shown in the figure, the five items are:

  • PerformanceThis is divided into three partsPerformance indicators,Optimizable items,And manual diagnosisWe can optimize a lot of things just by looking at this piece
  • Accessibility: Accessibility function analysis. For example, the foreground and background colors don’t have enough contrast, the image has an Alt attribute, the a link has a recognizable name, and so on
  • Best Practices: Best practice strategy. For example, the picture aspect ratio is not correct, the console has no error information
  • SEO: There is something about SEO search engine optimization
  • PWA: Officially, it measures whether a site is fast, reliable, and installable. In the domestic browser kernel is not unified, small procedures and so fire, so it seems that there is no landing scene

Then we know so much information, is it possible to diagnose and optimize our project

Isn’t that great?

Performance

If Lighthouse is the appetizer, Performance is the dinner

It records performance data as the site runs. By playing back the entire page execution, we can locate and diagnose how the page was performing over each period of time, but it doesn’t have performance scores or optimization recommendations, it just presents the collected data in a timeline

Open Performance, check Memory, click the Record on the left to start recording, and then perform operations or refresh the page, and then click (Stop) to end recording and generate data

As shown in figure

General situation of panel

There are page frames per second (FPS), white screen time, CPU consumption, network load, V8 memory usage (heap), and more, all in chronological order.

So how do you look at this graph and find out where there might be problems

  • If a red block appears on the FPS diagram (see top right), the rendering of a frame around the red block is taking too long and can cause a lag

  • If the CPU graphics area is too large, it indicates high CPU usage, which may be because one JS is taking up too much main thread time and blocking other tasks

  • If the memory usage of V8 keeps increasing, there may be a memory leak for some reason

    • If the current memory usage trend is on the rise after you view the memory usage, you can conclude that memory leaks exist
    • If the memory usage increases, you can also consider that memory leaks exist

After locating the possible time node of the problem through the overview panel, how can we get further data to analyze the direct cause of the problem

Just click on the part of the timeline that has a problem, and the details will be displayed in the performance panel

The performance of the panel

For example, if we click on a location in the timeline (such as the red block), the performance panel will display the performance data at that time node, as shown in the figure below

Many performance indicators are displayed on the performance panel, for example

  • The Main indicators: is the execution record of the render main thread
  • Timings indicators: Record the data information such as FP, FCP and LCP to produce some key time points (described below)
  • Interactions indicators: Records user interactions
  • The Network indicators: is the time the page takes per request
  • Compositor indicators: is the task execution record of the composite thread
  • GPU indicators: is the task execution record of the main thread of the GPU process
  • Chrome_ChildIOThread indicators: is the execution record of the IO thread, which contains user input events, network events, device related events and so on
  • Frames indicatorsRecord the time, layer structure and other information of each frame
  • .

The Main indicators

There are many performance indicators, and MOST of the time I use it is to analyze the Main indicator, as shown in the figure

The first line above is gray, and it says Task. A Task is a Task

What are the yellow and purple ones below? That’s a subtask within a task

Let’s zoom in. Let’s do an example

Task is a Task, and the following are the subtasks in Task. This diagram is expressed in code

function A(){
    A1()
    A2()
}
function Task(){
    A()
    B()
}
Task()
Copy the code

It’s a lot easier to understand

Therefore, we can select the problematic Task, such as the one marked red, and then zoom in (you can swipe the mouse to zoom in) to see the specific time consuming point

What’s being done, what’s taking a lot of time, and if you compress your code, you’ll see the compressed function name. Then we click on a function, and at the bottom of the panel, there’s information about the code, which function it is, how long it takes, what line on what file, and so on. In this way, we can easily locate the time function

You can also scroll through the TAB, see what its call stack is, and so on, and find the code more easily

Specific we can try ~

Timings indicators

The Timings indicator also needs attention, as shown in the figure below

What are FP, FCP, DCL, L, LCP and so on

Don’t worry

The Timings represent data at key points in time. What are the Timings?

  • FP: indicates the first drawing. Record the time when the page first drew the pixels

  • FCP: represents the first content drawing (only text, images (including backgrounds), non-white Canvas or SVG are counted as FCP)

  • LCP: Maximum content draw, which is the speed indicator representing the page. Record the maximum element rendering time in the viewport. This will change as the page is rendered

  • FID: First input delay, an indicator of page interaction experience. Record the time from the first user interaction between FCP and TTI to the time the browser actually responds to that interaction

  • CLS: Cumulative displacement, an indicator of page stability. Record the unexpected displacement of the page, such as the insertion of an image during rendering or the dynamic insertion of a piece of content by clicking a button, when the displacement is triggered

  • TTI: First interoperable time. Visually rendered and ready to respond to user input. Is a measure of how long it takes an application to load and how quickly it responds to user interaction. As with FMP, it is difficult to normalize TTI metric definitions that apply to all web pages

  • DCL: indicates the HTML loading completion time

    Note: DCL and L represent different times in Performance and NetWork, because the start time for Performance is the time you hit record, and the start time for NetWork is the fetchStart time (before checking the cache, The time the browser is ready to request the page document using HTTP)

  • L: indicates the time when all resources on the page are loaded

  • TBT: total blocking time. Record the total blocking time of all long tasks between FCP and TTI

  • FPS: Indicates the frame rate per second. Represents the number of screen updates per second, which is now 60 frames per second on most devices

  • FMP: The first meaningful drawing. Is the time that the main content of the page appears on the screen, which is the main indicator of the user’s perceived loading experience. It’s a bit abstract, because there’s no standardized definition. Because it is difficult to determine the key content of various types of pages in a generic way

  • FCI: Indicates the first CPU idle time. Indicates that the page has met the minimum level of interaction with the user

Ok, and then according to the indicators reflect the problem, targeted optimization is good

conclusion

Praise support, hand stay fragrance, and have glory yan

Thanks for seeing this, come on!

reference

  • How browsers work and practice

  • lighthouse