When we talk about front-end performance, what are we talking about

This article combines the official Google tool Lighthouse to analyze the latest front-end page performance scoring standards to help everyone better understand various performance indicators to improve and optimize related front-end projects.

1. Front-end page performance and analysis tools

The performance of front-end pages has always been an area that everyone continues to pay attention to, because user retention is closely related to page loading performance. According to statistics made by Google, the page visit time increased from 1s to 3s, and the user bounce rate increased by 32%.

The evaluation of front-end page performance is generally in two forms: one is to use performance analysis tools to score and evaluate various indicators of the web page; the other is to use performance monitoring and report to the user network through performance api or custom embedded points Real visit situation, then carry on statistical analysis.

Although it is more real by counting user data, in order to have a unified quantification standard for page performance, we often choose to use standard scoring tools to evaluate page performance.

In the early stage of performance analysis, we will analyze the web page from the chrome developer tool, including checking the time when the load and DOMContentLoaded events are triggered. Later, there were a series of performance analysis tools, such as webpage analyzer, WebPageTest, Yslow, etc.

Now that google has officially embedded the Lighthouse they developed into the tab of the developer tools, we regard Lighthouse as the standard evaluation tool.

Lighthouse is an open source web page performance analysis tool, and will give some relevant recommendations on page best practices. In addition to being directly used in chrome DevTools, it also supports the use of browser plug-ins (chrome and Firefox) or npm packages (node ​​api or CLI).

Tools like google's web page measure and PageSpeed ​​Insight both call Lighthouse to analyze the page.

Second, how to score the performance of the page

1. Lighthouse iteration and performance index changes

The first open source version of Lighthouse can be traced back to 2016. Currently (October 2020) the latest version is 6.4.1, and 89 versions have been iterated. In the past few years, Lighthouse has been updating its selection of performance indicators.

In the latest 6.X version of Google, compared with the 5.X version, three new performance indicators have been updated: FMP (First Meaningful Paint), FCI (First CPU Idle) and mpFID (Max Potential First Input Delay) are removed. );

Added TBT (Total Blocking Time), LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift). These indicators will be explained in detail later.

When we talk about front-end performance, what are we talking about

The previous 5.X version of Lighthouse

When we talk about front-end performance, what are we talking about

Current Lighthouse (version 6.X)

2. How to calculate page performance score

As shown in the figure below, in the page performance section, Lighthouse will integrate the current performance of the six key indicators to calculate the page performance score.

When we talk about front-end performance, what are we talking about

According to the latest 6.X calculation method, the value of each performance index corresponds to a score of that index. For example, the FCP, SI, LCP, TTI, TBT, CLS and other values ​​in the above figure, the corresponding individual scores are 78, 62, 37, 5, 99, 92 points in order. Generally speaking, the smaller the value, the higher the index score.

The corresponding weights of these 6 indicators are 15%, 15%, 25%, 15%, 25%, 5%, and the total performance score is calculated by weighted average of 60 points in the figure.

If you want to know the specific calculation method of each indicator value and its corresponding score, you can refer to materials 5 and 6 at the end of the article.

3. Key performance indicators

In the 6.0 version of Lighthouse, the key performance indicators that were removed are FMP (first meaningful rendering frame), FCI (first CPU idle), and user mpFID (potential maximum first input delay).

Let's start with the definition of these three obsolete indicators to better understand the basis for selecting indicators in the current version.

1. What is FMP, and what is the difference with FCP

Before talking about FMP, we must first introduce First Contentful Paint (FCP): the first content rendering time.

As the name suggests, as long as the browser's The First Page Paint event is triggered for the first time, the moment in time is FCP. But what is rendered at this time is not necessarily important page information, for example, only an action bar with a head is drawn, or even visible elements may not be rendered. Although it was retained in Lighthouse 6.0, the weight of the performance score was reduced from 23% to 15%.

Therefore, FCP cannot be used as an indicator to accurately measure page performance from the user's perspective.

In this context, FMP (First Meaningful Paint: the first meaningful rendering frame) came into being. According to the official definition, FMP refers to the point in time from when the page loads to the point where most or the main content has been rendered on the first screen.

So how to confirm the FMP time point, let's first look at the most basic calculation method:

We first calculate the number of layout objects (use the LayoutAnalyzer test calculation, see material 17 for details).

As can be seen from the figure below, the process of page loading is actually a process in which layout objects gradually enter the layout tree and render.

When we talk about front-end performance, what are we talking about

layoutAnalyzer will collect the number of layout objects, there is a counter called 

LayoutObjectsThatHadNeverHadLayout, the number of layout objects added for the first time.

Through testing, it is found that compared with other counters, the moment when it changes the most is often the moment when the most important element of the page is rendered.

Therefore, the calculation method of the FMP indicator is: LayoutObjectsThatHadNeverHadLayout (paint that follows the biggest layout change).

Of course, there are some scenarios where the above is not applicable:

a). If the page is a long page, then there will be cases where the number of invisible layout objects increases more than the number of visible objects in the first screen. At this time, FMP is inaccurate

b). In the case of loading web fonts, the text will be laid out with degraded fonts, but by default within 3s from the beginning of loadstart, no drawing will be performed, which will also affect the calculation of FMP

For scenario 1, FMP solves this problem by introducing the concept of layout signifcance (layout importance); for scenario 2, FMP delays the statistical time to make indicators more reasonably reflect the situation of the page. For more detailed solutions, please refer to material 18.

Google also tested nearly 200 pages in different scenarios of the above-mentioned FMP, and compared it with the accuracy of FMP felt by users by manually viewing screenshots of the pages. The results are as follows:

When we talk about front-end performance, what are we talking about

However, FMP was eventually abandoned in 6.0, mainly because of the following two points:

  • In a production environment, FMP is too sensitive to subtle changes on the page, which can easily lead to inconsistent results.
  • The definition of this indicator is more dependent on the specific implementation details of the browser and does not have a standard for reference.

2. The LCP replacing FMP is here

The shortcomings of FCP and FMP were mentioned in the previous chapter. Therefore, the W3C performance team has been looking for a suitable indicator to more truly reflect the time when users see the main content of the page.

Sometimes simpler is better (Sometimes simpler is better). According to many discussions on page performance, I finally found a more accurate method to measure whether the main content of the page is loaded, that is, LCP (Largest Contentful Paint).

LCP refers to the time when the largest content element is rendered in the window. This indicator was officially added in Lighthouse 6.0, and in the final performance score, it has a weight of up to 25%.

LCP should be the easiest indicator to define besides FCP. It can be seen from the definition that there are only two key points, which elements are selected for comparison and how to determine the size of the elements.

According to the official document, the following elements will be included in the consideration of the Largest Contentful element:

  • <img>
  • <image> in <svg>
  • <video>
  • Load the elements of the background image through the url() function
  • Contains block-level elements of text node or child elements of inline text

How do we determine the size of the element? Mainly the following 4 rules:

  • The size of the visible element in the viewport, if it exceeds the visible area or is clipped, obscured, etc., it will not be included in the size of the element
  • For picture elements, the size is the smaller value of the actual size and original size of the picture, namely Min (actual size, original size)
  • For text elements, only take the smallest rectangle area that can cover the text
  • For all elements, margin, padding, border, etc. are not counted

Google’s evaluation of this indicator is as follows: LCP is a very important and user-centric indicator; it reflects the loading speed of the page on the perceptual level; it marks the time point when the largest content element in the main content of the page is loaded; LCP A shorter page can make the user feel that the page is available more quickly.

3. What is the abandoned FCI and why is it so closely related to TTI

FCI (First Cpu Idle: First Cpu Idle), this indicator is used to measure how long it takes for a page to reach the minimally interactive (minimally interactive) standard.

The minimum interactive confirmation needs to meet the following two conditions:

a) Most of the UI elements on the screen are interactive

b) The page responds to most users’ input, and the average time is within a reasonable range

TTI (Time To Interactive: page interactive time) refers to the time required for a page to reach a fully interactive state.

Fully interactive means that the following three conditions are met at the same time:

a) After FCP, the page has presented useful content

b) For most visible page elements, event callbacks have been registered

c) The page's response to user interaction is within 50ms

In 2017, the First Interactive indicator was divided into two indicators: First Interactive and Constantly Interactive; in July of the following year, the First Interactive indicator was renamed FCI, and Constantly Interactive was renamed TTI. It can be seen that the two indicators, FCI and TTI, are a pair of indicators that reflect user interaction responses.

So how are the minimum and fully interactive calculations calculated? Before introducing the specific calculation method, we need to know that these two indicators are vague and can be continuously optimized and improved under different circumstances.

  • FCI minimum interactive time

In the timeline of the main thread, starting from FMP and after a certain task ends, find a time window W of length f(t). If W satisfies that there is no continuous task set with a length greater than 250ms in any period of time, and there is no long task within 1s before and after (the task with the execution time of js exceeding 50ms is a long task), then the time when the task ends is defined by us FCI. Where f(t) = 4 e^(-0.045 t) + 1.

The time point in the red box in the figure below is FCI

When we talk about front-end performance, what are we talking about

For the specific derivation process, please refer to Material 11, to understand more deeply why FCI is a vague concept.

  • TTI's fully interactive time

From the timeline of the network and the main thread, find the first 5s window period W, which is satisfied during the W time period: no more than two simultaneous network requests and no long tasks exceeding 50ms at any time. Then the end of the last long mission before W is what we call TTI.

The time point indicated in the red box in the figure below is TTI:

When we talk about front-end performance, what are we talking about

Although some people pointed out that FCI is more meaningful than TTI at some point, the difference between them is still not enough for Lighthouse to retain two similar indicators.

Therefore, in Lighthouse 6.0, the final choice is to use TTI instead of FCI.

4. mpFID and new TBT indicator

mpFID (max potential First Input Delay) refers to the potential (possible) maximum delay time from the user input to the page actually starting to process the event callback.

The specific calculation method of mpFID is to select the task with the longest execution time of js during the period from the start of FCP to the end of TTI, and subtract 50ms from the time it consumes.

However, mpFID only represents a maximum delay time, which is different from the actual delay time input by the user. The FID obtained by the user's input at different times will also be different, so mpFID does not truly reflect the response time of the page to the user input.

When calculating the performance score in the 5.X version, the weight of mpFID is 0 and it does not participate in the score. Although this indicator is no longer displayed in the report, it is actually retained in the JSON data, and mpFID is also a key user experience indicator that is still officially recognized.

So what is TBT (Total Blocking Time), and why should I choose to use it instead of FID in performance reports?

First look at the definition: TBT refers to the total time that the page has been blocked when responding to user input.

The specific calculation method is relatively clear, counting all the long tasks from FCP to TTI, and summing their blocked part time, which is TBT. The blocking time refers to the part where the execution time of the long task exceeds 50ms. For example, if a long task is executed for 70ms, the blocking time is 20ms.

It can be seen that TBT is a more stable indicator than mpFID, and it can more truly reflect the average delay of page response to user input.

5. New CLS

CLS (Cumulative Layout Shift: Cumulative Layout Shift), it is an indicator used to measure the stability of the visual interface.

The acquisition of this data is provided by the Layout Instability API (see reference 14 for details), and the calculation method is as follows:

layout shift score = impact fraction * distance fraction

The impact fraction refers to the impact on the entire window. For example, the text in the figure below occupies 50% of the entire window, and the next frame moves down 25% from the previous frame, so it affects 75% of the entire page, so the impact fraction is 0.75.

When we talk about front-end performance, what are we talking about

The distance fraction is easier to understand. It is the ratio of the changed distance to the entire window. For example, in the above example, the distance fraction is 0.25 if it moves by 25%.

In summary, the CLS value of the demo shown in the figure is 0.75 * 0.25 = 0.1875. For more detailed calculation methods, please refer to materials 13 and 14.

Take an example of how CLS actually affects the user experience: as shown in the figure below, the user wants to click the cancel button, but the page layout changes suddenly, and the confirm button appears in the previously canceled position...

When we talk about front-end performance, what are we talking about

It can be seen that CLS is a new performance evaluation index based on user experience.

At present, the weight of CLS as a new indicator is not large, only 5%, but Lighthouse is already considering increasing its weight in the next major version.

6. Speed ​​Index that has always been there

The Speed ​​Index (SI) is an index used to measure the filling speed of the visible content on the page. The calculation process uses the open source tool speedline (data 16).

Speedline calculates the value of speed Index by recording video on the page and counting the time difference between the first frame and the last frame.

It is worth mentioning that the final score of SI will be calculated by comparing the SI of the real website in the database. The current SI scores and scoring standards are shown in the following table:

When we talk about front-end performance, what are we talking about

Fourth, summary and outlook

Looking back at the replacement process of the above indicators, we can find that whether it is from FMP to LCP, FCI to TTI or FID to TBT, the selection of performance indicators is currently moving in a more stable direction: the definition of indicators is getting more and more Concise and clear, and the calculation method tends to be standardized.

But we should also know that there is no silver bullet here, and every indicator has its limitations. In many scenarios, it cannot be considered that the score is low, which necessarily means that the page experience is poor. Only when we understand the principles behind these indicators can we evaluate the page more scientifically in combination with the performance score.

As performance-related technology is updated faster, if there are any omissions in the article, please feel free to communicate and correct.

Five, reference materials

  1. Find out how you stack up to new industry benchmarks for mobile page speed 
  2. Performance.timing Api 
  3. What's New in Lighthouse 6.0
  4. Web Vitals
  5. Lighthouse Scoring Calculator
  6. Lighthouse performance scoring
  7. WebPageTest Demo
  8. Time to First Meaningful Paint
  9. First Interactive and Consistently Interactive
  10. Largest Contentful Paint (LCP)
  11. First Interactive and Consistently Interactive
  12. How Mercado Libre optimized for Web Vitals (TBT/FID)
  13. Cumulative Layout Shift (CLS)
  14. layout-instability
  15. Speed Index
  16. speedline
  17. Layout Analyzer
  18. Time to First Meaningful Paint

Author: Huang Wenjia

Guess you like

Origin blog.51cto.com/14291117/2561702