preface

We all know the importance of website performance. Important is important, but how to measure and identify it is always a very divergent and difficult thing to say. This paper will focus on the sharing of important conferences in the industry and introduce all important data indicator definitions in the mainstream context in detail.

Historically, YSlow has been the only evaluation tool for core metrics of Internet development, and its metrics represent the core metrics. Subsequently, lighthouse and other new tool platforms and detection modes emerged. After decades of development, there have been many kinds of performance tools, and the corresponding indicators tend to be common. How to evaluate the representativeness of indicators has gradually become a problem that needs attention.

In 2018, Google mentioned at ITS I/O conference that 75% of users consider page loading speed to be the primary factor in determining their interactive experience. Ire Aderinokun (Google Web Expert) shared in 2020 #PerfMatter that “once a page loads more than 5s, users have a 90% chance of abandoning it.” 2

So, how exactly do you measure your site’s performance?

Based on the data Google posted on Web.dev, they believe that user-centric performance metrics should answer four questions:

Web. dev is the Developer community provided by Google Developer, which focuses on many of the types of metrics listed below.

1. Does it happen? Is navigation started successfully? Is the server responding?
2. Is it useful? Has enough content been rendered to interact with the user?
3. Is it available? Can the user interact with the page, or is the page still busy loading?
4. Is it enjoyable? Is the interaction smooth and natural, with no lag and lag?

Here’s how each performance metric answers these questions to reflect the performance of the site, as well as Google’s efforts to improve the performance of the site by promoting Core Web Vitals.

Part ONE, Performance Metrics

To answer these four questions, Google has come up with a series of performance metrics. According to the above thinking principle, we divide these indicators into four categories, which respectively represent the specific performance of four stages of a visit perceived by users.

① Does it happen?

When a user visits a web site, the first question of concern is always “does it happen” – does the browser successfully send my request and does the server know about it and start processing it?

TTFB, FP and FCP are indicators to answer these questions.

1. TTFB (Time to First Byte)

The time at which the first byte arrives.

2. FP (First Paint)

First drawn, marks the point in time when the browser renders any content that is visually different from the screen before navigation.

3. FCP (First Contentful Paint)

The first content rendering marks the point at which the browser renders the first content from the DOM, which could be text, images, and so on.

Metrics such as TTFB, FP, and FCP mark the point at which the browser starts drawing content, telling the user: “The browser has started processing the server’s return, your request has already happened!”

② Is it useful?

Once the user is sure that their request has happened, they begin to ask the second question: “Is it useful?”

For example, when a user uses a weather app, after confirming that the page is responsive, they start to wonder when they can display useful content to know what the weather is like today.

FMP, LCP and SI are indicators to answer these questions.

1. FMP (First Meaningful Paint)

The first effective drawing refers to the point in time when the content useful to users is first drawn. Useful content means videos on Youtube; Tweets on Twitter; Weather prediction in weather applications…… These content or Elements, also known as Hero Elements, provide useful content to the user. However, these elements were difficult to define, so later LCP was used to replace FMP.

2. LCP (Largest Contentful Paint)

The maximum content rendering time calculates the maximum element rendering time from the time the page is loaded to the time the user interacts with the page (click, scroll). This time will change with the page rendering because the maximum element in the page may change during the rendering process.

3. SI (Speed Index)

The speed indicator, the speed of filling the page content, is the integral of the incomplete page at each moment from the start of loading to the end of rendering. The visually complete of the page is calculated based on the SSIM(Structural Similarity Index).

calculation

For example, in the following example, assuming that the page rendering is completed in 6 frames, each frame is 500 ms, and the page completion of each frame is 0%, 10%, 30%, 60%, 90% and 100% respectively, SI = 500 + 450 + 350 + 200 + 50 is calculated. The lower the SI, the faster the page fills and the better the user experience.

The LCP marks the point at which the browser draws the maximum content and defaults to the fact that the largest element on the page is the most useful content for the user. The LCP tries to mark when users get useful content, and the earlier they get useful content, the better the user experience. SI reflects the speed of filling page content. For example, in the image below, although the content is filled in at the last minute, it obviously feels like the page loads faster.

③ Is it available?

After the user has received useful information, the user will react based on that information, which is the “Is the page available?” For example, after seeing the news, want to comment; Know the weather, want to forward remind friends and so on. TTI, FID and TBT are indicators to answer these questions.

Before explaining these metrics, we need to understand why pages sometimes don’t respond to users in a timely manner.

1. Long Tasks

Time-consuming tasks. Browsers are single-threaded, and all tasks are added to the main thread queue for execution one by one. If any task takes too long, the main thread is blocked, and other tasks, including those generated by user interactions, have to wait to respond to the user. According to Jakob Nielsen’s Response Times: The 3 Important Limits 4, pages should respond to user input within 100 ms or they will be considered sluggish by The user. To achieve a response of less than 100 ms, a single task must be completed in 50 ms. In this way, even if the user input behavior occurs at the beginning of a task and takes 50 ms, the main thread still has 50 ms time to respond to the user input after the task ends, and the total response time is within 100 ms.

These time-consuming tasks can be easily discovered through Chrome DevTools or the Long Task API.

2. TTI (Time to Interactive)

Interactive time, used to mark a point in time when the page has been visually rendered and can reliably respond to user input. Pages can fail to respond to user input for a variety of reasons, such as the Javascript needed to run a page component not being loaded, or a long task blocking the main thread. The TTI metric identifies the point in time when the page’s initial JavaScript is loaded and the main thread is idle (no longer consuming tasks).

3. TBT (Total Blocking Time)

The total blocking time is the total time that the main thread blocks from FCP to TTI. The blocking time refers to the portion of the main thread occupied by a single task that exceeds 50 ms.

calculation

For example, the following example shows the operation of the main thread from FCP to TTI during the page loading process. Five tasks were executed, which took 250 ms, 90 ms, 35 ms, 30 ms and 155 ms respectively, among which three tasks took more than 50 ms. Add up their blocking times 250-50 + 90-50 + 155-50 = 345 ms to get TBT. The lower the TBT, the more interactive the page is.

4. FID (First Input Delay)

First input delay refers to the time when a user first enters a response to a page. We all know the importance of first impressions, and the same goes for websites. The first input delay can be an important first impression of a site, determining whether a user is likely to become a loyal user or leave. It’s worth noting that FID only focuses on discrete user actions such as clicks, taps, and keystrokes. Other interactions such as scrolling and zoomingare not FID’s concern, as browsers typically handle them in a separate thread.

(4)Is it enjoyable?

Let’s start with an unpleasant example.

In this example, you want to click button B, the page suddenly shifts, and you hit button A. “Is it pleasant?” Is a problem that can occur throughout the application. It includes not only the Long Tasks mentioned earlier, but also some unexpected layout offsets, known as CLS.

1. CLS (Cumulative Layout Shift)

Cumulative layout offset. Measures the sum of layout offset scores for each unexpected style move that occurs throughout the life of the page.

calculation

Offset score for a layout = Impact score * Distance score. The union of the visible regions of all unstable elements from the previous frame and the current frame (a portion of the total viewport area) is the influence fraction of the current frame. For example, in the image below, one element occupies half of the viewport in one frame. Then, in the next frame, the element moves down 25% of the viewport height. The red dotted rectangle represents the union of the visible areas of the elements in the two frames, which in this case is 75% of the total viewport, so its influence score is 0.75.

The distance score is the maximum distance any unstable element can move in the frame (horizontal or vertical) divided by the maximum size of the viewport (width or height, whichever is greater). For example, in the figure below, the maximum viewport size is height, and the unstable element moves 25% of the viewport height, giving a distance score of 0.25. So, in this case, the influence score is 0.75 and the distance score is 0.25, so the layout offset score is 0.75 * 0.25 = 0.1875.

I don’t know if you are aware of a problem, what is accidental deviation? How to tell the difference between the accidental deviation and the expected expansion by clicking the search button. Therefore, the layout offset within 0.5s after user interaction is ignored in CLS calculation. CLS also ignores the animation and ignores the transform changes⁵.

Part two, Core Web Vitals

In part 1, we looked at the definition of a concept (Long Tasks) and 10 indicators, and some of the calculation methods, but you may not remember many of them by now 😂. We don’t even remember what the performance indicators are, how do we improve the performance of the website according to these indicators. To this end, Google made a selection of many metrics and came up with Core Web Vitals.

What is Core Web Vitals?

To summarize:

1. Google’s efforts to improve the overall performance of the web;
2. Is a subset of Web Vitals, its core basic indicators LCP, FID and CLS;
3. Is a new factor in the future web ranking algorithm;

In May of this year, Google launched Web Vitals in Chromium Blog, which aims to provide a unified metric to quantify the user experience on the site, encompassing previous efforts at performance metrics. At the same time, Google believed that it was not necessary for everyone to be an expert in website performance, but to pay attention to the most Core and valuable indicators, so they proposed Core Web Vitals, which is a subset of Web Vitals. Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).

Why LCP, FID and CLS?

1. Representative;
2. Simple and easy to understand;
3. Can be accurately measured;

All three reflect the user experience in different ways (loading speed, interactivity, and visual stability). LCP tests the experience of loading speed, when the main content of a page is presented; FID tests the interactive experience of how long it takes for the user to get a response after the first input; CLS tests the experience on visual stability, how much content is accidentally deviated. Because they can be accurately measured, they can be graded on how good they are, how they need to be improved, and how bad they are.

Google uses the 75-cent mark to represent the overall result of a site’s metric 6. For example, 75% of visits to a website have LCP less than 2s, so the website’s LCP index is good; On the contrary, more than 25% of the site’s visits, FID is more than 300ms, then the site’s FID is poor.

Why ≤ 2500ms, ≤ 100ms, ≤ 0.1?

First of all, based on The investigation of Google, The Science Behind Web Vitals is studied. Websites that meet The above criteria can bring good experience to users.

Secondly, these metrics are attainable. Prior to launching these metrics and thresholds, data based on the CrUX(Chrome User Experience Report) found that 10% of sites meet these metrics.

Tools and perimeters

Google is making a big push to promote Core Web Vitals. In addition to the I/O ’20 hype and the Webmaster announcement that it will incorporate Core Web Vitals into its Web ranking algorithm, A series of tools 7 are provided to help developers measure their sites against these metrics.

1. You can start by using the Search Console’s new Core Web Vitals report to see how your site is performing.
2. If you find some problems with your site, you can use PageSpeed Insights to locate performance problems.
3. You can then measure the page in your local lab environment using Lighthouse or Chrome DevTools to get specific instructions to fix performance issues. Or use the Web Vitals Chrome Extension to see your page’s Core Web Vitals in real time on the desktop.
4. If you need a dashboard for Core Web Vitals, You can get real data using the updated CrUX(Chrome User Experience Report) Dashboard or using the new Chrome UX Report API.
5. Lack of guidance? Web.dev/Measure measures your page and gives you relevant suggestions based on PSI(PageSpeed Insights) data.
6. Finally, introduce Lighthouse CI to ensure that every iteration doesn’t set your Core Web Vitals back.

---

Welcome to “Byte front end ByteFE”

Resume mailing address: [email protected]