background

Everyone went to a hospital to pass physical examination ~ often do not understand a few assay index, skip to see doctor’s advice directly: “did not see abnormal”. Isn’t that true, but today is not about telling you how to read a medical report. In fact, we also have some front-end methods to the page “physical examination”, but if some students have not looked at the words, for some data may ask: “How is this thing calculated?” The purpose of this article is to interpret the report with you.

In what way can page metrics be obtained

In fact, there are many wheels to use, if you want to quickly implement, you can directly use the off-the-shelf tools, of course, you can also be interested in manual calculation. We will not focus on tools here.

lighthouse

What is a lighthouse

Lighthouse is an open source tool developed by Google for analyzing web pages and performance metrics. It also provides actionable advice to help developers optimize.

How to use the lighthouse

Some common ways we use Lighthouse are as follows:

  • Browser developer tools
  • The command line

My personal opinion of these two scenarios is that if you just want to see the metrics of the page after development, you can just use Lighthosue in developer tools. If you need to test a batch of pages, you can consider using the command line, and the command line also has the advantage that you can directly generate periodic reports through the script, let everyone compare….. And then secretly optimize it.

If you want to know the timing of the report, you can leave a message to urge more, ha ha ha ha.

performance

What is the performance

Performance is also a tool provided by the browser. In Chrome, you can view the loading time of a page, the loading order of some resources, and even the call of stacks.

How to use the performance

Find Performance in developer tools, select Refresh and record. You can also set the network state to test.

window.performance

What is a window. The performance

The Web Performance API allows Web pages to access certain functions to measure the Performance of Web pages and Web applications, including Navigation Timing APIS and high-resolution temporal data

How to use the window. The performance

This is the logical thing to do, but normally we call it after the page has finished loading, and performance is mounted directly to the window. It is recommended to use a listener to listen for load events to avoid overwriting functions.

What are the implications of each indicator in the report

Lighthouse has four key indicators, which are:

  • The Performance properties of
  • The org.eclipse.swt.accessibility barrier-free
  • Best Practices
  • SEO Search engine optimization

Of course, this time we will focus on the performance module that we often use.

Performance Access Flow Chart

The following chart is a flow chart of the performance index. It introduces some common fields to explain how the performance index time is calculated.

  • NavigationStart: The time the current page starts, which is understood as the moment the address request is processed
  • FetchStart: the time when the browser initiates the HTTP request to read the document
  • DomainLookupStart: DNS query starts
  • DomainLookupEnd: DNS query ends
  • ConnectStart: The TCP connection is established, that is, the handshake is started
  • ConnectEnd: TCP is established
  • RequestStart: The moment an HTTP request is made
  • ResponseStart: Returns the time of the first byte
  • ResponseEnd: time when the request ends
  • DomLoading: The time when DOM parsing begins
  • DomInteractive: The DOM is parsed and the DOM tree is created
  • DomContentLoadedEventStart: DOM resource loading time to start
  • DomContentLoadedEventEnd: The time when the DOM is ready to execute all scripts that need to be executed on the page
  • DomComplete: The time when the DOM structure is generated
  • LoadEventStart: Start time for onload event execution
  • LoadEventEnd: End of the onload event execution

Performance

There are 6 indicators below Performance:

  • FCP(First Contentful Pain)
  • TTI(Time to interactive)
  • SI(Speed Index)
  • TBT(Total Blocking Time)
  • LCP(Largest Contentful Paint)
  • CLS(Cumulative Layout Shift)

These 6 indicators are calculated according to different weights, and the final score of performance is obtained. The weight of V8 for these items is as follows:

Audit Weight
First Contentful Paint 10%
Speed Index 10%
Largest Contentful Paint 25%
Time to Interactive 10%
Total Blocking Time 30%
Cumulative Layout Shift 15%

Of course, this score is often asked: “yesterday I was 80 points, how come today is 60 points”, in fact, this is very normal, because we will be affected by various factors when testing performance, so far, I encountered the please pass is basically caused by the network status. Officials also give several common reasons:

  • A/B tests or changes in ads being served
  • Internet traffic routing changes
  • Testing on different devices, such as a high-performance
  • desktop and a low-performance laptop
  • Browser extensions that inject JavaScript and add/modify network requests
  • Antivirus software

FCP(First Contentful Pain)

This may be familiar to many of you, but this is actually the way we calculate the screen time a lot of the time. FCP is simply the time it takes for the first DOM to appear on the page. Images, non-white canvas, SVG are all considered DOM content. Of course, none of the elements in the iframe are evaluated.

FCP time(s) Color-coding
0–1.8 Green (fast)
1.8–3 Orange (moderate)
Over 3 Red (slow)

Then it will be clear how to solve the problem if we know the meaning. The official also reminds us that sometimes we use fonts, which will affect FCP very much. We should let the text appear first. ResponseEnd -fetchStart if we did it ourselves manually

TTI(Time to interactive)

This one, which is used by fewer people, refers to how long it takes for a page to be fully interactive, and fully interactive means:

  • After the FCP is completed
  • Most of the DOM already has events bound
  • Respond to user interactions within 50ms

This might be a little confusing, but when is most of the DOM already bound to events? In fact, the Google team is also constantly optimizing and replacing FMP with FCP for ease of calculation.

First FI definition

Classic forward search, looking for a task with no more than 50ms in 5s.

Second FI definition

The previous definition of 5S is not convincing because many scripts are probably still loading, and the closer you are to FMP, the more reliable you are. Therefore, consider extending the time range to verify that the key JS have been executed. As shown, 15s after FMP, there is a 3-second blank area which is a good enough signal. So in the second definition, our 5s is no longer a fixed value, but decreases at the rate of 3s from FMP15s, but not less than 1s. F (∞) = 1, which is defined as: the farther the distance from FMP, the shorter the intercept time, but the range does not fall below 1s.

F of t is equal to 4 e to the minus 0.045 t plus 1.

Third FI definition

Long tasks are usually intensive when pages perform the most critical load-related tasks. The range from FMP to firstinteractive shown in the figure is relatively intensive. Isolated tasks, usually some third-party ads or analysis scripts, should not prevent the first interaction.

If a group of long tasks can be encapsulated in a region L of less than 250ms, so that there are no long tasks that overlap with the [L.start-1s, L.start] and [L.end, L.End +1s] regions, they are called isolated tasks.

Of course, the third definition considers that there are no isolated tasks within 5 seconds after FMP, because all tasks close to FMP have a high critical probability.

Fourth FI definition

This definition is actually a combination of the second definition and the third definition, from the fixed 5s range after FMP, into a variable.

TTI time(s) Color-coding
0–3.8 Green (fast)
3.9–7.3 Orange (moderate)
Over 7.3 Red (slow)

How can I improve my TTI score? I think we can delay the execution of some low-priority JS, unpack scripts and so on.

SI(Speed Index)

This can be used as a reference, it measures the visual display speed of the page content. Capture the video of the page loading in the browser and calculate the visual progression between frames. The visual progress is calculated by comparing the distance between the current frame and the final frame. It is calculated based on the Speedline Node.js module.

SI time(s) Color-coding
0–3.4 Green (fast)
3.4–5.8 Orange (moderate)
Over 5.8 Red (slow)

Then it will be clear how to solve the problem. You can refer to the information listed on Opportunities, which is mainly:

  • Minimize main thread work
  • Reduce JavaScript execution time
  • Ensure that the text remains visible during webFont loading

TBT(Total Blocking Time)

TBT measures the total time a page is prevented from responding to user interactions, such as mouse clicks, screen clicks, or keyboard presses. The sum is calculated by adding blocking parts of all long tasks between FCP and TTI. For details, see FI in TTI, which defines any task that takes more than 50ms to execute as a long task. The amount of time after 50ms is the blocking part. For example, if a 70ms task is detected, the blocking portion will be 20 milliseconds.

TBT time(ms) Color-coding
0-200. Green (fast)
200-600. Orange (moderate)
Over 600 Red (slow)

Then it will be clear how to solve the problem. You can refer to the information listed in Opportunities in the report. The main optimization is as follows:

  • Minimize main thread work
  • Reduce JavaScript execution time
  • Ensure that the text remains visible during webFont loading

LCP(Largest Contentful Paint)

The LCP measures when the largest content element in the viewport appears on the screen. The element size reported by the LCP is usually the size visible to the user within the viewport. If the element extends beyond the viewport, or if any element is clipped or has an invisible overflow, such as overflow, then these portions do not count toward the size of the element, which will be recorded if the developer uses min-width. The scope of detection by LCP is as follows:

  • <img>
  • <svg>In the<image>
  • <video>Elements (using poster images)
  • The element with the background image loaded by the URL () function (as opposed to CSS tween)
  • Block-level elements with text nodes or inline child elements.

Take a look at the following example:


In the second example, the layout changes and the previously largest content is removed from the viewport

LCP time(s) Color-coding
0–2.5 Green (fast)
2.5–4 Orange (moderate)
Over 4 Red (slow)

CLS(Cumulative Layout Shift)

CLS is a measure of the maximum layout offset score for each unexpected layout offset that occurs over the life of a page. Resources are typically loaded asynchronously, or DOM elements are dynamically added on top of existing content, causing previous elements to become unstable.

A series of layout transitions is called a session window, which means that one or more individual layout transitions occur in rapid succession, with less than a second between each transition and a maximum window duration of 5 seconds.

Layout Shift Score = Impact Fraction * distance Fraction

What is impact Fraction

As shown here, one element occupies 50% of the viewport in one frame. Then, in the next frame, the element moves down 25% of the viewport height. The red dashed rectangle represents the union of the visible areas of the elements in the two frames, which in this case accounts for 75% of the total viewport, so its impact fraction is 0.75.

What is distance fraction

As shown, the element moves 25% of the viewport height, so the distance fraction is 0.25.

Now, you can think about how to do the following graph. Tip: The green box is in the gray box

We can reduce CLS by:

  • Instead of changing the height and width attributes, use transform: scale().
  • Avoid changing the top, right, bottom, or left attributes and use transform: Translate () instead.
CLS time(s) Color-coding
0–0.1 Green (fast)
0.11–0.24 Orange (moderate)
Over 0.25 Red (slow)

Reference documentation

  • Web. Dev/first – conte…
  • Web. Dev/interactive…
  • Web. Dev/speed – index…
  • Web. Dev/lighthouse -…
  • Web. Dev/lighthouse -…
  • Web. / dev/CLS? Utm_so…
  • Docs.google.com/document/d/…
  • Googlechrome. Making. IO/lighthouse /…