1. Introduction
We already know the importance of performance, but when we talk about performance, what does making a web page faster mean?
In fact, performance is relative:
- One site may be fast for one user (on a fast network with powerful devices) and slow for another (on a slow network with low-end devices)
- Both sites may finish loading in exactly the same amount of time, but one site seems to load faster < (if it loads content gradually, rather than waiting until the end to display anything)
- A site may appear to load quickly but then slowly respond to user interactions
When discussing performance, precise, quantifiable metrics are important
However, just because a measure is based on objective criteria and can be measured quantitatively does not necessarily mean that the measures are useful
How to measure the performance of a Web page has always been a challenge for Web developers
Initially, we used metrics such as Time to First Byte, DomContentLoaded, and Load to measure document loading progress, but they didn’t directly reflect the user’s visual experience
To measure the user’s visual experience, the Web standard defines performance metrics that are standardized across browsers, such as First Paint and First Contentul Paint.
Other performance metrics proposed by the Web Incubator Community Group (WICG) include Largest Contentful Paint, Time to LnterActive, First Input Delay, and First CPU Idle. There are also Meaningful Paint and Speed Index from Google and First Screen Paint from Baidu
These metrics are not unrelated, but have evolved in user-centric goals that are no longer recommended, implemented by various testing tools, and used as a common standard with apis provided by major browsers for measurement in production environments
2.RAIL performance model
RAIL is the acronym of Response, Animation, Idle and Load. It is a performance model proposed by Google Chrome team in 2015 to improve user experience and performance in the browser
RAIL model is “user-centric, the ultimate goal is not to make your site run fast on any particular device, but to make your users happy”
The name is derived from the first letters of four English words:
- Response: Should respond to the user as quickly as possible, should respond to the user input within 100ms
- Animation: When displaying animations, each frame should be rendered in 16ms to maintain consistency and avoid stalling
- Idle: When using the Javascript main thread, you should divide tasks into fragments that take less than 50ms to free up threads for user interaction
- Load: Your site should Load in less than 1s and be ready for user interaction
Users’ understanding of performance latency varies depending on network conditions and hardware.
For example, loading a site on a powerful desktop computer over a fast Wi-Fi connection usually takes less than a second, which users are used to.
It takes more time to load websites on mobile devices with slow 3G connections
So mobile users are generally more patient, and loading the 5S on mobile devices is a more realistic goal.
These four words represent four aspects of the life cycle of a site or application that affect the performance of the entire site in different ways
With the user at the center of our performance tuning, we first need to understand how users react to delays. The following table shows the time window for users to perceive the delay
| delay | Users to reflect |
|---|---|
| 0 ~ 16ms | The human eye can perceive animation at 60 frames per second, which is 16 ms per frame. Web applications take about 10ms to generate a frame, excluding the time it takes a browser to draw a frame onto the screen |
| 0 ~ 100ms | Responding to user actions within that time frame is a smooth experience |
| 100 ~ 1000ms | Noticeable delays can be felt |
| >1s | The user’s attention is taken away from performing the task |
| >10s | Users get frustrated and may abandon the task |
The response
Metrics: should respond to users as quickly as possible, should respond to user input within 100ms
The responsiveness aspect of web site performance is to receive feedback on actions before users perceive delays
For example, users must receive feedback within 100ms after text input, button click, form switch and animation start. If the time window exceeds 100ms, users will perceive delay
Seemingly basic user operations may hide complex business logic processing and network requests and data calculation
We should be careful to put the expensive work in the background asynchronously, and provide timely phased feedback to the user even if the background process takes hundreds of milliseconds to complete
For example, when a user clicks a button to initiate a service processing request to the background, the user is first given a prompt indicating the start of processing, and then the prompt indicating the completion of processing after the callback is completed
animation
Metrics: When displaying animations, each frame should be rendered in 10ms to maintain consistency and avoid stuttering
The front end involves animations that not only have cool UI effects, but also interactive effects such as scrolling and touch dragging, where performance is required to be smooth
It is well known that the human eye has a transient property of vision, which means that the vision produced by light on the retina remains for a period of time after the light stops acting on it
Studies have shown that this is due to the reaction speed of the optic nerve, which is 1/24s, meaning that when the object we see is removed, it does not disappear immediately but lasts for 1/24s of a second. For animation, no matter how high the frame rate of the animation is, we can only discern 30 frames in the end, but the higher the frame rate, the better the smooth experience, so the animation should strive for a frame rate of 60fps
The current screen refresh rate on most devices is 60 times per second, so the browser will need to render each frame of an animation or page at the same rate as the screen refresh rate on the device. Therefore, according to the calculation of 60fps frame rate, the generation of each frame needs to go through several steps. The generation budget of a frame is 16ms (1000ms / 60 ≈ 16.66ms), and the time for code execution is only about 10ms excluding the time for the browser to draw a new frame. If you don’t meet this budget, the frame rate drops and the content shakes on the screen. This phenomenon is commonly referred to as stalling and can negatively impact the user experience. Specific optimization strategies for this dimension will be described in the section on optimizing the rendering process
free
Metrics: When using the Javascript main thread, you should divide tasks into sections with execution times of less than 50ms to free up threads for user interaction
To make quick response and smooth animation, often require long processing time, but for the center with the user to view performance issues, will find that not all work needs to be done in response and loading stage, we can fully use the browser’s free time treatment can delay the task, so long as lets the user without delay
The idle time processing delay can reduce the size of preloaded data and ensure that websites or applications can be loaded quickly
To make better use of the browser’s idle time, it is best to group processing tasks into 50ms units. This ensures that the user responds within 100ms of the operation
loading
Metrics: The first load should be completed in less than 5s and user interaction is possible. For subsequent loads, it is recommended to complete within 2 seconds
User perception requires that we try to complete the page load within 5 seconds, if not, the user’s attention will be diverted to other things and the current task will feel interrupted. It should be noted that the requirement of loading and rendering pages 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 paths are completed, users will think that all the loading is completed
It is a common progressive optimization strategy to delay loading of other non-critical resources until the browser is idle. For example, lazy loading of pictures, code separation and other optimization methods
The specific optimization scheme of loading will be introduced in detail in a separate content later
3. Performance indicators based on user experience
User experience based performance metrics were introduced by Google in web.dev
First Contentful Paint (FCP)
FCP (First Contentful Paint) Is the time when the browser First draws content from the DOM. The content must be text, an image (including a background image), a non-white canvas or SVG, and also text with a Web font that is being loaded.
This is the first time a user is starting to see content on a page, but just because there is content doesn’t mean it’s useful content (headers, navigation bars, etc.), nor does it mean there is content for the user to consume
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. |
| More than 4 | Red (slow) | 0–49 |
Optimization scheme
- Web. Dev/FCP / # how-to…
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) Maximum content drawing. It is used to estimate how long the main content of a page is visible to the user
Elements considered by LCP:
<img>The element<image>Elements within the<svg>The element<video>Elements (Cover)- through
url()The background image element loaded by the function- Block-level elements that contain text nodes or other children of inline cascaded text elements
To provide a good user experience, aim for “maximum content painting” of 2.5 seconds or less
To ensure that you reach this goal for most users, the 75th percentile of page loads on mobile and desktop devices is a good measure
Here are some examples:
In both timelines, the largest element varies with content loading
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 is often the case that lazy-loaded content is larger than what is already on the page, but this is not necessarily the case
The next two examples show the maximum content painting that occurs before the page is fully loaded
In the first example, the Instagram logo loads relatively early and remains the largest element even as the rest of the content is gradually displayed
In the Example of the Google search results page, 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 remains the largest element throughout the loading process
In the first frame of the Instagram timeline, you might notice the absence of a green box around the camera logo. That is because it is a < SVG > element, and the < SVG > element is not currently considered an LCP candidate
Speed indicator
| LCP time (in seconds) | Color coding |
|---|---|
| 0-2.5 | Green (fast) |
| 2.5-4 | Orange (medium) |
| More than 4 | Red (slow) |
Optimization scheme
- Web. Dev/optimize – lc…
First Input Delay (FID)
First Input Delay (FID) Specifies the Delay between the First interaction with a page (such as clicking a link or button) and the time when the browser can respond to the interaction
Input is delayed because the main thread of the browser is busy doing other things and cannot respond to the user. A common reason for this is that the browser is busy parsing and executing a lot of computed JavaScript loaded by the application
The first input delay usually occurs between the first content rendering (FCP) and the sustainable interaction time (TTI), because the page has rendered some content but is not yet able to reliably interact
As shown in the figure above, when the browser receives the user’s input operation, the main thread is busy performing a time-consuming task. Only after the task is completed, the browser can respond to the user’s input operation. The time it must wait is the FID value of the user on the 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 interactions:
- Text entry fields, check boxes, and radio buttons (
The < input >, < textarea >) - Select the drop-down menu (
<select>) - Links (
<a>)
Speed indicator
Optimization scheme
- Web. / dev/fid # how-to…
- Web. Dev/optimize – fi…
Time to Interactive (TTI)
Represents the point in time when a web page is first fully interactive and the browser can consistently respond to user input
The point at which the interactible state is fully reached is when the last Long Task is completed, and the network and main thread are idle for the next 5 seconds
Long tasks are tasks that take more than 50 milliseconds to complete
By definition, the Chinese term sustainable interaction time or fluid interaction time is more appropriate
Speed indicator
| TTI indicator (in seconds) | Color coding |
|---|---|
| 0–3.8 | Green (fast) |
| 3.9–7.3 | Orange (medium) |
| More than 7.3 | Red (slow) |
Optimization scheme
- Web. Dev/tti / # how-to…
Total Block Time (TBT)
Total Block Time (TBT) Total Block Time, which measures the Total Time between FCP and TTI in which the main thread is blocked long enough to prevent input responses
The main thread is considered “blocked” whenever there is a long task running on the main thread for more than 50 milliseconds (ms).
We say the main thread is “blocked” because the browser cannot interrupt a task in progress
Therefore, if the user does interact with the page in the middle of a long task, the browser must wait for the task to complete before responding
If the task is long enough (for example, any time over 50 milliseconds), the user is likely to notice delays and feel that the page is slow or outdated
The blocking time for a given long task is one that lasts more than 50 milliseconds, and the total blocking time for a page is the sum of the blocking time for each long task that occurs between FCP and TTI
For example, consider the following image of the browser main thread during page loading:
The timeline above has five tasks, three of which are long because they last more than 50 milliseconds. The following figure shows the blocking time for each long task:
Thus, while the total time spent running the task on the main thread is 560 milliseconds, only 345 milliseconds is considered blocking time
Speed indicator
| TBT time is expressed in milliseconds | Color coding |
|---|---|
| 0-300. | Green (fast) |
| 300-600. | Orange (medium) |
| More than 600 | Red (slow) |
Optimization scheme
- Web. Dev/TBT / # how-to…
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) is the Cumulative Layout Shift (CLS), which measures the Cumulative Layout Shift score of all the individual Layout shifts for each unexpected Layout Shift in the entire life cycle of a page. It is an indicator scheme to ensure the visual stability of a page to improve user experience
Have you ever had a sudden change on a page and without warning, the text moved and you lost position? Even worse: You’re about to click a link or a button, but the moment your finger drops, the link moves and you end up clicking something else!
Unexpected movement of page content usually occurs as a result of asynchronously loading resources or dynamically adding DOM elements to a page above existing content
The culprit could be an image or video of unknown size, displaying a larger or smaller font than its back-up, or a third-party AD or widget that dynamically resizes itself
Speed indicator
| CLS time in milliseconds | Color coding |
|---|---|
| 0–0.1 | Green (fast) |
| 0.1-0.25 | Orange (medium) |
| More than 0.25 | Red (slow) |
Optimization scheme
- Web. Dev/CLS / # how-to…
- Web. Dev/optimize – cl…
Speed Index
The Speed Index is a measure of how fast content fills in the visible area of a page, measured by calculating the average time it takes to display content in the visible area of the page
Measuring way
Example 1 and Example 2 in the figure are both filled in at 10s
But Example 1 is 80% filled at 2s, while Example 2 is 80% filled at 8s
The area of the shaded part of the figure (above the time-content fill percentage curve) indicates the filling speed of the page content within the visible area. The smaller the area, the faster the filling speed
In terms of time, you can calculate it this way to represent the average time for content to be displayed in the visible area of the page
Example 1: Speed Index = (80% * 2) + (20% * 10) = 3.6 Example 2: Speed Index = (80% * 8) + (20% * 10) = 8.4Copy the codeThis average time can be used to compare the performance experience of the full display of the first screen content, but it does not calculate the time when the full display of the first screen content is not considered as a time metric
Speed indicator
| Speed index (in seconds) | Color coding | Speed index score |
|---|---|---|
| 0–4.3 | Green (fast) | 75-100. |
| 4.4–5.8 | Orange (medium) | 50-74. |
| More than 5.8 | Red (slow) | 0–49 |
Optimization scheme
- Web. Dev/speed – index…
4.Web Vitals
Google has developed a number of useful metrics and tools to help measure user experience and quality to discover optimization points. A program called Web Vitals reduces learning costs and provides a unified set of quality metrics for the Web experience — Core Web Vitals, which includes loading experience, interactivity, and visual stability of page content.
There are many ways to optimize your site’s user experience. Knowing the best optimization metrics up front can save a lot of time and cost
On May 5, 2020, Google proposed a new quantitative method of user experience, Web Vitals, to measure the user experience of websites, and used the measurement results as part of its ranking algorithm. To better understand this, let’s look at what these important indicators are
Core Web Vitals vs. Web Vitals
What is Web Vitals? Google defines it as Essential metrics for a healthy site. In the past, there were too many metrics needed to measure the quality of a website. Web Vitals can simplify the learning curve of metrics by simply focusing on the performance of Web Vitals metrics
In these Web Vitals, Google has identified three main metrics, Core Web Vitals, which is common across all types of sites
Core Web Vitals is a subset of Web Vitals that applies to all Web pages and is its most important Core.
- Load performance (LCP) – The time required to display the largest content element
- Interactivity (FID) – First input delay time
- Visual stability (CLS) – Cumulative layout configuration offset
These three indicators have been verified for a period of time, for example, LCP has been incubated in WICG for at least 1 year, FID has been implemented in Google Chrome Labs for more than 2 years, LCP and CLS (related Layout Instability API) were drafted by W3C this year
Measuring Web Vitals
- Performance testing tools, such as Lighthouse
- Use the web – vitals library
- Use the browser plug-in Web-Vitals
Optimizing Web Vitals
- Optimized Largest Contentful Paint (web.dev)
- Optimize First Input Delay (web.dev)
- Cumulative Layout Shift Cumulative Layout Offset (web.dev)
Other Performance Indicators
Redirection number: performance. Navigation. RedirectCount
Redirection time: redirectEnd – redirectStart
DNS resolution time: domainLookupEnd – domainLookupStart
TCP connection time: connectEnd – connectStart
SSL connection duration: connectEnd – secureConnectionStart
TTFB: responseStart – requestStart
Data transfer time: responseEnd – responseStart
DOM parsing time: domInteractive – responseEnd
Resource loading time: loadEventStart – domContentLoadedEventEnd
First package time: responseStart – domainLookupStart
ResponseEnd – fetchStart
First interactive time: domInteractive – fetchStart
DOM Ready time: domContentLoadEventEnd – fetchStart
Page full load time: loadEventStart – fetchStart
HTTP header size: transferSize -encodedBodySize
Time to First Byte (TTFB)
The time between the request page and the first byte received by the browser, including DNS lookup, TCP connection, and SSL connection
Frames Per Second (FPS)
Frame rate is the rate at which a video device produces images (or Frames), expressed as Frames Per Second (FPS) that can be redrawn
Redrawing may require recalculation of style, layout, and drawing. If each frame is drawn to the screen for more than 16.7ms, the number of frames drawn per second will be less than 60. The human eye will feel the page stalling, so FPS is a very important indicator of application smoothness. Can provide 16.7ms time for each drawing
Between budget
Since frame rate is related to page redrawing, we can ask two questions:
- In what cases will redrawing be triggered?
FPS are most common in movies and games, but are now widely used as a measure of the performance of websites and web applications
In Web performance, the FPS is most often used to measure the performance of an animation: if the FPS is too low, the animation will stall
FPS can also be used as a general measure of page responsiveness when the user interacts with the page
For example, if moving the mouse over a page element triggers the execution of JavaScript to update the page, this may trigger backflow and redraw, which needs to be done in frames, and will stall if the browser takes too long to process frames
For example, if scrolling triggers a lot of complex page updates, and the browser doesn’t maintain an acceptable frame rate, scrolling can be slow or stuttering
- How can I reduce redrawing time?
Redrawing to the screen may start with building a DOM tree, recalculating styles, layouts, drawing, etc., and we need to avoid triggering these processes as much as possible
For example, modifying the opacity property with CSS will not trigger a relayout, reducing the drawing time
So when implementing animations, it is recommended to use CSS properties with low performance costs rather than set elements in JavaScript
Refer to the link
- web.dev/vitals/
- Juejin. Cn/post / 684490…
- www.uisdc.com/web-vitals