Web performance metrics
We already know the importance of performance, but when we talk about performance, what does it mean to make a web page faster?
In fact performance is relative:
- A site may be fast for one user (on a fast network with powerful devices) and slower for another user (on a slow network with low-end devices ).
- Two sites may load in the exact same amount of time, but one will appear to load faster (if it loads content incrementally, rather than waiting until the end to display everything).
- A website may load quickly, but be slow on subsequent user interactions.
So when discussing performance, precise and quantifiable indicators are very important.
However, a metric is based on objective criteria and can be measured quantitatively, so just because a metric is good or bad does not necessarily mean it is useful.
For web developers, how to measure the performance of a web page has always been a difficult problem.
Initially, we used TTFB (Time to First Byte), DomContentLoaded and Load to measure the progress of document loading, but they cannot directly reflect the user's visual experience.
In order to measure the user's visual experience, some performance indicators are defined in Web standards, and these performance indicators are standardized by major browsers, such as First paint (first drawing) and First contentful paint (first content drawing). There are also some performance indicators proposed by the Web Incubator Community Group (WICG), such as Largest Contentful Paint (maximum content drawing), Time to interactive (sustainable interactive time), First input delay (first input delay), First CPU idle (first CPU is idle). In addition, there are First Meaningful Paint (first meaningful drawing) and Speed index (speed index) proposed by Google , and First Screen Paint (first screen visible time) proposed by Baidu .
These indicators are not unrelated, but are constantly evolving in the user-centered goal. Some are no longer recommended, some are implemented by various testing tools, and some can be used as general standards. There are APIs provided by major browsers that can be used for measurement in production environments.
The following is mainly introduced through three levels:
- RAIL performance model - experience standards given from the perspective of user experience (Response, Animation, Idle, Load)
- Core indicators based on user experience - based on specific indicator schemes under RAIL
- A new generation of performance indicators: Web Vitals - the simplification of the above indicator schemes, focusing on LCP (Largest Contentful Paint), FID (First input delay), and CLS (Cumulative Layout Shift).
RAIL performance model
RAIL is an acronym for Response , Animation , Idle and Load . It is a performance model proposed by the Google Chrome team in 2015 to improve the user experience and performance in the browser.
The philosophy of the RAIL model is "user-centric, the ultimate goal is not to make your website run fast on any particular device, but to make users happy".
The origin of the name RAIL is the first letter of four English words:
- Response: It should respond to the user as quickly as possible, and should respond to user input within 100ms.
- The so-called response is not to return a result, but to give a state interaction that the user can perceive.
- Animation: When displaying animation, each frame should be rendered in 16ms, so as to maintain the consistency of the animation effect and avoid stuttering.
- about 60 frames per second
- Idle: When using the JavaScript main thread, tasks should be divided into fragments whose execution time is less than 50ms, so that threads can be released for user interaction.
- Execution tasks exceeding 50ms are called **"long tasks"** in JS. Since long tasks cannot respond to user interaction during execution, try to avoid them
- Load (Load): Your website should load in less than 1 second and allow user interaction.
Depending on network conditions and hardware, users' perception of performance latency varies.
1s is an indicator based on a PC with better performance and a good network environment, and users have become accustomed to it.
And it takes more time to load the network on mobile devices with slower 3G connections, so mobile users are generally more patient, and loading 5s on mobile is a more realistic goal.
These four words represent four aspects related to the lifecycle of a website or application that affect the performance of the overall website in different ways.
User Perception of Latency
We regard the user as the center of performance optimization in the future, and we first need to understand the user's reaction to the delay.
The time at which the user perceives the delay, as shown in the following table:
| Delay | user perception |
|---|---|
| 0 ~ 16ms | The human eye can perceive animation at 60 frames per second, that is, 16ms per frame. Except for the time when the browser draws a frame to the screen, the website application takes about 10ms to generate a frame |
| 0 ~ 100ms | Responding to user actions within this time frame will result in a smooth experience |
| 100 ~ 1000ms | noticeable delay |
| > 1s | The user's attention will be taken away from the focus on performing the task |
| > 10s | User is disappointed and may abandon task |
Response
Metrics: It should respond to the user as quickly as possible, and should respond to user input within 100ms.
A responsive aspect of website performance is to receive feedback on actions before the user perceives a delay. For example, after the user performs operations such as text input, button click, form switching, and startup animation, the feedback must be received within 100ms. If the time exceeds 100ms, the user will perceive a delay.
Behind the seemingly basic user operations, there may be hidden complex business logic processing, network requests and data calculations. We should be cautious about this, and put the relatively expensive work in the background to perform asynchronously, and even if the background needs to process hundreds of milliseconds to complete the operation, we should provide timely feedback to the user.
For example, when a button is clicked to initiate a certain business processing request to the background, the user is first given a prompt to start processing, and then a prompt to complete the processing is fed back in the callback of the processing completion.
Animation Animation
Indicators: When displaying animations, each frame should be rendered in 10ms, so as to maintain the consistency of animation effects and avoid stuttering.
The animation involved in the front end not only has cool UI special effects, but also includes interactive effects such as scrolling, touch, and drag, and the performance requirement in this aspect is smoothness. As we all know, the human eye has the characteristic of persistence of vision, that is, the vision produced by light on the retina can still be retained for a period of time after the light stops acting.
Studies have shown that this is caused by the reaction speed of the optic nerve, which is 1/24s, that is, when the object we see is removed, the object will not disappear immediately in our eyes, but will continue to exist for 1/24s . For animation, no matter how high the animation frame rate is, we can only distinguish 30 frames in the end, but a higher frame rate will bring a better smooth experience, so the animation should try its best to achieve a frame rate of 60fps.
At present, the screen refresh rate of most devices is 60 times per second, so the rate at which the browser renders each frame of an animation or page needs to be consistent with the refresh rate of the device screen. Therefore, according to the calculation of the frame rate of 60fps, the generation of each frame needs to go through several steps, and the budget for generating a frame image is 16ms (1000ms / 60 ≈ 16.66ms), excluding the time for the browser to draw a new frame, it is left for the execution code The time is only about 10ms. If this budget cannot be met, the frame rate will drop and the content will jitter on the screen. This phenomenon is commonly referred to as stuttering and can negatively impact the user experience.
You can open the sample page provided by chrome to see the effect, and keep clicking add 10 until the transfer speed of the blue square becomes significantly slower: Janky Animation
Idle
Metrics: When using the JavaScript main thread, you should divide tasks into fragments that take less than 50ms to execute, which frees up threads for user interaction.
It usually takes a long processing time to make the website respond quickly and the animation is smooth, but if you look at performance issues from a user-centered perspective, you will find that not all work needs to be completed in the response and loading phases, and we can take advantage of the idle time of the browser. Time handles tasks that can be delayed, as long as the user does not feel the delay. Taking advantage of idle time to handle latency reduces the size of preloaded data to ensure that a website or app loads quickly.
In order to make more reasonable use of the browser's idle time, it is best to group processing tasks in units of 50ms. This is done to ensure that the user responds within 100ms after the operation occurs.
Load Load
Metrics: The first load should complete in less than 5 seconds and allow user interaction. For subsequent loading, it is recommended to complete within 2s.
User perception requires us to try our best to complete the page loading within 5s. If it is not completed, the user's attention will be distracted to other things, and the current processing task will have a sense of interruption. It should be noted that the requirement to complete the loading and rendering of the page within 5s is not to complete the loading of all page resources. From the perspective of user perception experience, as long as the key rendering path is completed, the user will think that all loading has been completed .
Delaying the loading of other non-critical resources until the browser is idle is a common progressive optimization strategy. Such as image lazy loading, code splitting and other optimization methods.
Performance metrics based on user experience
The core indicators based on user experience were proposed by Google in web.dev.
First Contentful Paint（FCP）
FCP (First Contentful Paint) first content drawing, the time when the browser draws content from DOM for the first time , the content must be text, pictures (including background images), non-white canvas or SVG, including web fonts that are being loaded text.
This is the first time that users start seeing page content, but just because there is content does not mean that it is useful content (such as headers, navigation bars, etc.), nor does it mean that users want to consume content.
speed indicator
| FCP time in seconds | color coding | FCP Score (HTTP Archive Percentile) |
|---|---|---|
| 0-2 | green (fast) | 75-100 |
| 2-4 | orange (medium) | 50-74 |
| >4 | red (slow) | 0-49 |
Optimization
https://web.dev/fcp/#how-to-improve-fcp
Largest Contentful Paint（LCP）
LCP (Largest Contentful Paint) maximum content drawing, the time when the largest content element in the visible area is rendered on the screen, used to estimate the time when the main content of the page is visible to the user.
Elements considered by the LCP:
<img>element<svg><image>elements within elements<video>Elements (Cover Image)url()Elements that load background images via the function- A block-level element that contains children of text nodes or other inline-level text elements
To provide a good user experience, sites should strive to use a "Maximum Content Paint" of 2.5 seconds or less. To make sure you're reaching this goal for the majority of your users, measuring the 75th percentile of page loads for mobile and desktop devices is a good measure.
Here are some examples:
In both timelines above, the largest element changes as the content loads. In the first example, new content is added to the DOM and the largest element is changed. In the second example, the layout changes and the previously largest content is removed from the viewport.
It's often the case that lazy-loaded content is larger than what's already on the page, but that doesn't have to be the case. The next two examples show the maximum content paint happening before the page is fully loaded.
In the first example, the Instagram logo loads relatively early, and even as other content gradually reveals, it remains the largest element. In the second sample Google search results page example, the largest element is a piece of text that is displayed before any images or logos have finished loading. Since all individual images are smaller than this segment, it will always be the largest element throughout the loading process.
In the first frame of the Instagram timeline, you may notice that the camera logo is not treated as the largest element (there is no green frame around it). That's because it's a
<svg>element, and<svg>elements are not currently considered candidates for LCP.
speed indicator
| LCP time in seconds | color coding |
|---|---|
| 0-2.5 | green (fast) |
| 2.5-4 | orange (medium) |
| >4 | red (slow) |
Optimization
https://web.dev/optimize-lcp/
First Input Delay（FID）
FID (First Input Delay) is the first input delay, from the user's first interaction with the page (such as clicking a link, clicking a button, etc.) to the time when the browser is actually able to respond to the interaction.
Input lag occurs because the browser's main thread is busy with other things and cannot respond to the user. A common reason for this to happen is that the browser is busy parsing and executing the computationally intensive JavaScript loaded by the application.
First input lag usually occurs between the first content paint (FCP) and the sustainable time to interact (TTI), because the page has rendered some content but cannot yet be reliably interacted with.
As shown in the figure above, when the browser receives user input, the main thread is busy executing a task that takes a long time. Only after the task is completed, the browser can respond to the user's input. The time it has to wait is the FID value for that user on this page.
For example, all of the following HTML elements need to wait for ongoing tasks on the main thread to complete before responding to user interaction:
- Text input boxes, checkboxes and radio buttons (
<input>,<textarea>) - Select drop-down menu (
<select>) - link(
<a>)
speed indicator
| FID time in milliseconds | color coding |
|---|---|
| 0-100 | green (fast) |
| 100-300 | orange (medium) |
| >300 | red (slow) |
Optimization
- https://web.dev/fid/#how-to-improve-fid
- https://web.dev/optimize-fid/
Time to Interactive（TTI）
TTI (Time to Interactive) indicates the point in time when the webpage fully reaches the interactive state for the first time , and the browser can continuously respond to the user's input. The point in time when the fully interactive state is reached is when the last long task (Long Task) is completed, and the network and main thread are idle for the next 5 seconds (no long task).
From a definition point of view, the Chinese name is sustainable interaction time or fluent interaction time is more appropriate.
Tasks that require more than 50ms to complete are called long tasks .
speed indicator
| TTI time in seconds | color coding |
|---|---|
| 0-3.8 | green (fast) |
| 3.9-7.3 | orange (medium) |
| >7.3 | red (slow) |
Optimization
https://web.dev/tti/#how-to-improve-tti
Total Block Time（TBT）
TBT (Total Block Time) measures the total time between FCP and TTI in which the main thread is blocked long enough to prevent incoming responses.
As long as there is a long task (the task is running on the main thread for more than 50ms), the main thread is considered "blocked". We say the main thread is "blocked" because the browser cannot interrupt an ongoing task. So if the user does interact with the page in the middle of a longer task, the browser has to wait for the task to complete before responding.
If the task is long enough (say, anything over 50ms), the user is likely to notice a delay and feel that the page is slow or stale.
The blocking time of a long task is the part of its duration longer than 50ms. The total blocking time of the page is the sum of the blocking time of each long task that occurred between FCP and TTI.
For example, consider the following diagram of the browser's main thread during page load:
The timeline above has five tasks, three of which are long tasks because they last longer than 50ms.
The following graph shows the blocking time of each long task:
So, while the total time spent running the task on the main thread is 560ms, only 345ms is considered blocking time.
speed indicator
| TBT time in milliseconds | color coding |
|---|---|
| 0-30 | green (fast) |
| 300-600 | orange (medium) |
| >600 | red (slow) |
Optimization
https://web.dev/tbt/#how-to-improve-tbt
Cumulative Layout Shift（CLS）
CLS (Cumulative Layout Shift) cumulative layout shift, CLS measures the sum of the unexpected layout shift scores of each element in the entire life cycle of the page. Every time the starting position of the visual element is different in the two rendering frames, it is considered to have occurred LS (Layout Shift).
Imagine a scenario where you want to click a link or button, but the instant your finger falls, the link moves and you end up clicking something else!
Unexpected shifting of page content often occurs due to asynchronous loading of resources or dynamic addition of DOM elements on top of existing content. The culprit could be an image or video of unknown size, or a third-party ad or widget that dynamically resizes itself, etc.
speed indicator
| CLS time in milliseconds | color coding |
|---|---|
| 0-0.1 | green (fast) |
| 0.1-0.25 | orange (medium) |
| >0.25 | red (slow) |
Optimization
- https://web.dev/cls/#how-to-improve-cls
- https://web.dev/optimize-cls/
Speed Index（SI）
Speed Index (SI) is an index that indicates the filling speed of the content in the visible area of the page, which can be measured by calculating the average time for the content to be displayed in the visible area of the page.
measurement method
Such a curve can be obtained by capturing the video of the browser loading the page, and then calculating the percentage of the page content filling for each 100ms interval screenshot of the page.
Both Example 1 and Example 2 on the way are filled in 10s, but Example 1 is already filled with 80% of the content in 2s, and Example 2 is only filled with 80% in 8s.
The area of the shaded part in the figure (that is, the part above the time-content filling percentage curve) can represent the filling speed of the page content in the visible area. The smaller the area, the faster the filling speed.
speed indicator
| speed metric (in seconds) | color coding | speed index score |
|---|---|---|
| 0-4.3 | green (fast) | 75-100 |
| 4.4-5.8 | orange (medium) | 50-74 |
| >5.8 | red (slow) | 0-49 |
Optimization
https://web.dev/speed-index/#how-to-improve-your-speed-index-score
Web Vitals
Google has developed many useful metrics and tools to help measure user experience and quality to uncover opportunities for optimization. An initiative called Web Vitals reduces the learning curve and provides a unified set of quality measures for website experience - Core Web Vitals, which includes loading experience, interactivity and visual stability of page content.
There are many ways to optimize the user experience of your website. Knowing the best optimization measures up front can save a lot of time and money.
On May 5, 2020, Google proposed a new user experience quantification method, Web Vitals, to measure the user experience of a website and use these measurements as part of its ranking algorithm.
Core Web Vitals vs. Web Vitals
What is Web Vitals, the definition given by Google is a basic indicator of a good website (Essential metrics for a healthy site) .
In the past, there were too many indicators to measure the quality of a website. Web Vitals can simplify the learning curve of indicators, and only need to focus on the performance of Web Vitals indicators.
Of these Web Vitals, Google identified three main metrics, the Core Web Vitals that are common across all types of websites:
Core Web vitals are the subset of Web vitals that apply to all Web pages, and are their most important core.
| index | describe | Good | Poor | Percentile |
|---|---|---|---|---|
| Loading Performance (LCP) | Time required to display the largest content element | ≤2500ms | ＞4000ms | 75 |
| Interactivity (FID) | First entry delay time | ≤100ms | >300ms | 75 |
| Visual Stabilization (CLS) | cumulative layout offset | ≤0.1 | >0.25 | 75 |
Measuring Web Vitals
- Performance testing tools, such as Lighthouse
- Using the web-vitals library
- Using the browser plugin Web Vitals