Web Performance Metrics! TTFB, FCP, LCP, FID, INP, CLS...

@ Web Performance

Introduction

Initially, I just wanted to write about the explanations of three metrics related to Core Web Vitals🔗 … but I found that it is necessary to understand all the metrics, so this article challenges to understand and explain all the web experience metrics proposed by Google.

I realized that it is not necessary to memorize all types of metrics at once, so I created a handy guide along with this article for easy reference and learning:

Measurement of Metrics

Metrics are statistical values designed to objectively measure website experience. Before diving into each metric, let’s understand the basic principles of metric measurement:

Is it happening?

Did the page navigation successfully start? Did the server respond? Related metrics: FFTB, FCP

Is it useful?Did it render enough content for users to engage? Related metric: LCP
Is it usable?

Is the page busy? Can users interact with the page? Related metrics: FID, INP, TTI, TBT

Is it delightful?

Does the page interaction feel smooth and natural? No delays or flickering? Related metric: CLS

And the extended types of metrics are as follows:

Perceived Load SpeedThe speed at which the page loads and renders all visual elements
Load ResponsivenessThe speed required for the page to load and execute any necessary JavaScript
Runtime ResponsivenessThe speed of response to user interactions after the page has loaded
Visual StabilityThe extent to which content elements change position during the page loading process
SmoothnessThe extent to which a stable frame rate and smoothness are maintained during page changes

TTFB - Time to First Byte

A good TTFB value is recommended to be within 800 milliseconds, while above 1800 milliseconds is considered poor, and improvements are needed in between

Measures the time taken from requesting a resource to the first byte response during the webpage loading process. This metric primarily helps understand the speed at which users can obtain resources and is the most fundamental metric before others. A better TTFB indicates that the webpage is “happening,” allowing users to obtain resources more quickly.

FCP - First Contentful Paint

A good FCP value is recommended to be within 1.8 seconds, while above 3 seconds is considered poor, and improvements are needed in between

Measures the time taken for the “first content to appear” during the webpage loading process. The content refers to text, images (including background images), <svg> elements, or non-white <canvas> elements. In other words, it measures how long it takes for the webpage to display its content. This metric primarily helps understand the loading speed of the webpage; a better FCP can persuade users that the webpage is “happening.”

LCP - Largest Contentful Paint 🌟

A good LCP value is recommended to be within 2.5 seconds, while above 4 seconds is considered poor, and improvements are needed in between

Measures the time taken for the “first largest content to appear” during the webpage loading process. The largest content includes:

  • <img> elements
  • <image> elements embedded in <svg> elements
  • <video> elements using cover images
  • Elements with background images loaded via the url()🔗 function
  • Child elements of block-level elements🔗 that have text nodes or other inline elements

In other words, it measures how long it takes for the webpage to display its largest content. This metric primarily helps understand the user’s experience during webpage loading; a better LCP can persuade users whether the webpage is “useful.”

FID - First Input Delay (replaced by INP) 🌟

A good FID value is recommended to be within 100 milliseconds, while above 300 milliseconds is considered poor, and improvements are needed in between

Measures the time taken for the first interaction with the website (clicking links, buttons, or using custom JavaScript controls) during the webpage loading process, specifically the “time point when the browser can respond to the interaction.” In other words, it measures how long it takes for the webpage to respond to user interactions, helping understand the interactivity of the webpage; a better FID can persuade users whether the webpage is “usable.”

Specifically, this metric calculates how much time it takes for the browser to react to the user’s first interaction (excluding event handling time), and the results may vary depending on user behavior.

INP - Interaction to Next Paint 🌟

A good INP value is recommended to be within 200 milliseconds, while above 500 milliseconds is considered poor, and improvements are needed in between

INP replaced FID in March 2024 and also measures how long it takes for the webpage to respond to user interactions, but INP evaluates the overall interaction quality of the webpage rather than just the delay time of the first interaction. Compared to FID, which is a page load metric, INP is more of a metric for testing the overall reliability of the website; a better INP can persuade users whether the webpage is “usable.”

Specifically, this metric observes the delay time experienced during clicks, touches, and keyboard interactions that occur during the user’s visit to the webpage, and it only counts the time from behavior trigger to the main thread being occupied to the point where rendering feedback can begin. In other words, waiting times outside the main thread (e.g., waiting time for sending a form request after pressing a button) are not included.

CLS - Cumulative Layout Shift 🌟

A good CLS value is recommended to be within 0.1, above 0.25 is considered poor, and improvements are needed in between

Measuring the “stability of web content,” which is the frequency of changes in the position of web content, this metric primarily helps understand the visual stability of a webpage. A better FID allows users to feel that the webpage is “delightful.”

TTI - Time to Interactive

A good TTI value is recommended to be within 3.8 seconds, above 7.3 seconds is considered poor, and improvements are needed in between

Measuring how long it takes for users to interact with the webpage, this metric primarily helps understand the interactivity of the webpage. A better TTI can persuade users about the webpage’s “usability.” Webpages may experience delays in execution due to blocking tasks or interfaces controlled by JavaScript that have not fully loaded, which can prevent user interaction. These issues should be measured and avoided as much as possible.

Specifically, this value starts calculating from the time of FCP and finds the end of the last long task during the webpage loading process. This interval is the calculation range for TTI; if there are no long tasks, the TTI value will be based on the FCP time.

TBT - Total Blocking Time

A good TBT value is recommended to be within 200 milliseconds, above 600 milliseconds is considered poor, and improvements are needed in between

Measuring the time the main thread is blocked between FCP and TTI that affects input responsiveness, which is the length of time the webpage is too busy to respond during loading. This metric primarily helps understand the interactivity of the webpage. A better TBT can persuade users about the webpage’s “usability.” The browser must wait for the task to complete before responding to user interactions. The calculation simulation chart is as follows:

Task DurationTask Blocking Time
Task One250 ms200 ms
Task Two90 ms40 ms
Task Three35 ms0 ms
Task Four30 ms0 ms
Task Five155 ms105 ms
Total Blocking Time345 ms

Summary

This article is my advanced digest version. Google’s documentation is already very comprehensive, and for a deeper understanding, you can refer to User-Centric Performance Metrics🔗 which provides detailed explanations and translations. As web development evolves, these metrics will also change, so this article will be updated regularly. If you spot any errors or have suggestions, please let me know!

Supplement

Long Tasks🔗

When the main thread executes a single task for more than 50 milliseconds, it is considered a long task. Both TTI and TBT are built on top of the long tasks API.

Core Web Vitals

Core Web Vitals aim to simplify the environment and help websites focus on the most important metrics. If you use Google’s site inspection tools, such as PageSpeed🔗, the above web metrics will be used: LCP, FID, or CLS to score the website, measuring the browsing experience based on performance, interactivity, and visual stability.

Web Page Score Measurement Criteria

The three web metrics mentioned above are defined by Google, with different requirements for mobile devices and computers based on performance differences. For details, you can refer to: Defining Core Web Vitals Thresholds🔗.

Additionally, it is important to note that Google’s search engine aggregates a comprehensive score based on all pages of a website. If 75% of the pages achieve a “Good” rating, then the website will be rated as “Good” under that metric. Therefore, monitoring the scores of all pages within the overall website is crucial.

References