1. The scene

Scenario 1

  • Know anything about performance tuning?
  • What happens when you enter the URL to see the entire page?
  • .

Scenario 2

  • Page loading is slow. I do not know whether it is a front-end or back-end problem. How to find and solve the problem
  • Page interaction is stuck, don’t know exactly where the problem
  • .

2. What is Web performance

Definition of Web performance in MDN: Web performance User’s intuitive experience of load time and runtime. Web performance refers to the time it takes for a page to load interactively and responsively, as well as the smoothness of the page during interaction-does it scroll smoothly? Is the button clickable? Can popovers open quickly, and is the animation smooth? Web performance includes both objective measures such as load time, frames per second, and time to page interaction; It also includes the user’s subjective perception of the load time of the page content.

3. How to optimize Web performance

  1. Need to know performance metrics – how fast is fast
  2. Use professional tools to quantify the performance of a website or application
  3. Then, based on the life cycle of web page response, the reasons for the poor performance are analyzed
  4. The iterative optimization

4. Performance model

4.1 RAIL performance model

RAIL, the acronym of Response, Animation, Idle and Load, is a performance model proposed by Google Chrome team in 2015, which is used to improve the user experience and performance of the browser.

The concept of RAIL model is “user-centric, the ultimate goal is not to make the site run fast on any particular device, but to make the user happy”

The name is the first letter 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: The site should Load and start user interaction in less than 1s

Why 50ms?

W3C standards stipulate

Users’ understanding of performance latency varies depending on network conditions and hardware. For example, users are used to loading websites on powerful desktops over a fast wifi connection in less than a second. Loading a website on a mobile device with a slow 3G connection takes more time, so mobile users are generally more patient, and loading a 5S on a mobile device is a more realistic goal.

These four words represent four aspects of the user’s intuitive experience 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 ~ 16 ms The human eye can perceive animation at 60 frames per second, or 16ms per frame, leaving the web site with about 10ms to generate a frame, in addition to the time it takes a browser to draw a frame onto the screen
0 ~ 100 ms Responding to user actions within this time range makes the user feel smooth and responsive
100ms~300ms You will feel a slight delay
300 ms to 1000 ms Within this range, the user will feel that a task is being performed in the browser
>1s The user’s attention is taken away from performing the task
>10s Users get frustrated and may abandon the task

The response

Goal: Should respond to users as quickly as possible, should respond to user input within 100ms or less.

The responsiveness aspect of web site performance is to receive feedback on operations before users perceive delays. For example, the user must receive feedback within 100ms after text input, button click, form switch, and start animation. If the feedback exceeds 100ms, the user will perceive the delay. When performing expensive work, try to do it asynchronously in the background. Even if the backend process takes hundreds of milliseconds to complete, it should give the user immediate feedback.

animation

Objective: When displaying animations, each frame should be rendered in 16ms to maintain consistency and avoid stuttering.

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. So according to the calculation, a frame time of 1000/60 is approximately 16.7ms, in which script execution, reflow, redraw, etc. Browser rendering takes about 6ms to render the page, leaving about 10ms to generate a frame.

free

Goal: 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.

Browsers are known to be single-threaded (although Web workers support background threads). This means that user interaction, rendering, and script execution are all on the same thread. If the thread is executing complex javascript, the main thread cannot respond to user input in a timely manner, such as clicking. Therefore, js should be broken up into blocks of code that execute at 50ms or less.

loading

Goal: Your site should load and be ready for user interaction in less than 1s.

Page load times are a cliche. In order to achieve the goal of loading within 1s, we should first consider the optimization of key rendering paths, prioritize the loading of resources needed by the first screen, and load unnecessary resources at idle time.

4.2 Web Vitals

Web Vitals is a new measurement of user experience that Google introduced in May 2020. It uses it to measure the user experience of websites and uses these measurements as part of the ranking algorithm. Google defines it as a basic indicator of a good site. There used to be too many metrics to measure the performance of a website. Web Vitals simplifies metrics, so now we just need to focus on the performance of Web Vitals metrics.

Core Web Vitals is a subset of Web Vitals that applies to all Web pages. Each Core Web Vitals represents an aspect of the user experience that is measurable in the domain and reflects the real experience of user-centered key outcomes.

  • Load performance (LCP) : The time required to display the largest content element. To provide a good user experience, LC should occur within 2.5s after the page first starts loading.
  • Interactivity (FID) : First input delay time. To provide a good user experience, the FID of the page should be 100ms or shorter.
  • Visual stability (CLS) : Cumulative layout offset. To provide a good user experience, pages should maintain CLS of 0.1 or less.

These indicators are benchmarked against important user-centered results, can be measured in the field, and have equivalent experimental indicators. For example, while LCP is a quality ceiling for page load metrics, it is also highly dependent on first content rendering (FCP) and first byte time (TTFB), which remain critical for monitoring and improvement.

5. Performance indicators

Performance itself is relative. Therefore, accurate and quantifiable indicators are very important when optimizing performance. Only with accurate and quantifiable indicators can we quickly and accurately optimize performance according to these indicators.

5.1 background

Initially, we used TTFB (Time to First Byte), DomContentLoaded, and Load to measure document loading progress, but they did not directly reflect the user’s visual experience.

In order to measure the user’s visual experience, the Web standard defines performance metrics that are standardized across major browsers, such as First Paint and First ContentfulPaint. Other performance metrics proposed by the Web Incubator Community Group (WICG) include Largest Contentful Paint, Time to Interactive, 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 have evolved with user-centric goals and are no longer recommended, implemented by various testing tools, or as a common standard provided by major browsers for measurement in production environments.

5.2 Common Indicators

TTFB(Time To First Byte)

The first byte time refers to the time between the browser sending the first request and the data returning the first byte. This time includes the network request time and the back-end processing time.

FP(First Paint)

First drawing. First draw includes any user – defined background drawing, and the moment the first pixel is drawn to the screen.

FCP (First Contentful Paint)

First content rendering, commonly known as white screen time. The time when the browser draws the first DOM element onto the page, the content must be text, a picture (including a background image), an element, or a non-white element, as well as text with a Web font that is loading.

Note, however, that this is only the first time the user sees the content on the page, and it may not be meaningful content.

FMP (First Meaning Paint)

First meaningful drawing. The time when meaningful content for users is first drawn on the page, such as the time when the search box on Baidu home page appears for the first time. The meaningful content of each page varies from page to page.

The first meaningful drawing is a measure of page usability.

LCP (Large Contentful Paint)

The rendering time of the largest visible content element in a page, used to represent user-perceived page load time.

The purpose of LCP is to measure how long it takes for the main content of a page to appear in a user’s browser, focusing on the user’s perceived experience rather than a long list of metrics that measure each step of the loading process.

FID(First Input Delay)

From the time the user first interacts with the page (that is, when they click a link, click a button, or use a custom, javascript-driven control) to the time the browser is actually able to respond to that interaction.

FID measures the response of a page to user input. Input is delayed because the browser main thread is busy with other things, parsing and executing js, loading JS, etc. So, as mentioned above, large JS files need to be sliced.

TTI(Time To Interactive)

The first time a page can interact, the browser can continuously 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.

In short, three conditions are met:

  • The calculation starts after the FCP indicator
  • No long task (execution time exceeds 50ms) and no more than two GET requests are in progress within 5s
  • Go back to the end time of the last long mission before 5s

Long tasks are tasks that take more than 50 milliseconds to complete

CLS (Cumulative Layout Shift)

Cumulative layout offset, used to measure page stability.

ClS measures the sum of all individual layout shift scores for each unexpected layout shift that occurs over the life of a page. It is based on a formula that counts the number of times components on a page move or “shift” as the page loads, and the fewer times the better.

For example, during the page loading process, there is a button that you want to click, and when you click it, the layout of the page has changed because some element of the page has loaded, and the button is not in that position, you will click on another place.

SI (Speed Index)

The time required for page content to render. The lower the value, the better. It displays the average time it takes to render the content portion of the page, depending on the viewport size. The percentage of page rendering is calculated every 100ms page until it is complete.

Total Blocking Time (TBT)

Total blocking time: Records the total blocking time of all long tasks between FCP and TTI.

Tasks larger than 50ms are called long tasks, while tasks smaller than 50ms are naturally called short tasks.

For example, suppose that the FCP to TTI pages perform both long and short tasks as shown in the figure below.

The blocking time for each long task is equal to the total time it executes minus 50ms.

Therefore, according to the above definition, we know that TBT time is equal to 200+40+105=345ms.

Indicators to summarize

The name of the note
TTFB(Time To First Byte) It is the time between the first request from the browser and the first byte of data returned. This time includes network request time and back-end processing time
FP(First Paint) First draw includes any user – defined background drawing, and the moment the first pixel is drawn to the screen
FCP(First Content Paint) First content rendering is the time the browser renders the first DOM to the screen, which can be any text, image, SVG, etc
FMP(First Meaningful Paint) The first meaningful drawing is a measure of page usability
LCP(Large Contentful Paint)(Main content Paint) Measures how long it takes for the main content of a page to appear in the user’s browser
FID(First Input Delay) The time between the user’s first interaction with the page and the page’s response to the interaction
TTI(Time To Interactive) The time when the first interaction is available
CLS(Cumulative Layout Shift) Measuring visual stability
SI(Speed Index) The amount of time the page content takes to render
TBT(Total Block Time) Total blocking time of all long tasks between FCP and TTI

6. References:

  • # Front-end Performance Optimization Guide [7]–Web Performance Metrics
  • # Performance Web Performance Critical Points (Web Vitals)
  • Speed Index
  • Still reading those old performance tuning articles? Take a look at these latest performance indicators