Core Web Vitals
When it comes to measuring the speed of a website, one comes across the term "Core Web Vitals" from Google, see "Google Search Console" (GSC). These were introduced in 2021. They are now considered another ranking factor, which is why you should definitely deal with them. But what exactly is meant by the "Core Web Vitals"?
The "Core Web Vitals" are a combination of 3 individual metrics:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
These metrics are used to analyze load speed, responsiveness, and visual stability of a page, and then generate the "Core Web Vitals" report.
This results in a rating for each URL:
- good
- optimization required
- poor
This rating, in turn, is necessary for the "User Experience Report". Without this rating, a URL cannot be displayed in the "User Experience Report".
At this point it should be mentioned that the data from the "Core Web Vitals" report is usually only imported into the "User Experience Report" after a few days. Accordingly, the rating of a URL can be displayed there with a slight delay.
A "good" Core Web Vitals rating is required for a "good" status in the Usability Report.
But let's take a look at the "Core Web Vitals" in detail!
What are the Core Web Vitals?
Largest Contentful Paint (LCP)
This metric indicates how quickly a page loads on a screen (smartphone, tablet, desktop) and the visitor sees the portion of the page visible to them without scrolling the page. The speed (loading time) is therefore measured.
First Input Delay (FID)>
This metric indicates how quickly a website responds to user input (such as tapping a button or entering data into a field). -> Responsiveness (interactivity)
Cumulative Layout Shift (CLS)
This metric indicates whether the layout of the page shifts in a way that impacts the visitor's experience of the website. It also indicates the number of shifts that the visitor sees. So the visual stability on the page is measured (layout shift).
Thresholds for the individual ratings
| good | optimization required |
poor | |
| LCP | ≤ 2.5 s | 2.5 - 4 s | > 4 s |
| FID | ≤ 100ms | 100 - 300ms | > 300ms |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
Note: Since "Mobile Web" and "Desktop Web" have different limitations for users (e.g. device, viewport size, network connection, etc.), both versions are analyzed independently. Accordingly, there are values for mobile devices as well as for desktop computers.
How to measure Core Web Vitals?
The following providers can display the Core Web Vitals
- Google Search Console
- Google PageSpeed Insights
- Semrush Site Audit
- GTmetrix
- Lighthouse
There are also the following options
- Chrome DevTools
- Chrome UX Report
- Web Vitals Extension
Please note! It may be that some tools show errors while others don't show errors. For example, the "Google Search Console" shows a page's performance based on the real-world usage data from the CrUX report, while Lighthouse uses the so-called "lab data". Because "lab data" is collected in a controlled environment, it can be used to troubleshoot performance issues during the development phase of a website. Bottlenecks in the real world may not be captured. Thus, the information each report provides is different.
Bad Core Web Vitals?
What if a page doesn't meet the advertised performance metrics from Core Web Vitals?
Still, a page's content and its correspondence to the information a user is looking for is certainly a very strong signal for ranking. Good performance metrics are useless if no one is interested in the information on a web page and a page is therefore not clicked on in the first place. On the other hand, the "Core Web Vitals" shouldn't be so bad that visitors leave the website immediately, for example because it takes a long time to load.
Optimize Core Web Vitals!
Improving the metrics of a website requires web development skills. It can therefore make sense to contact a specialist if you do not have this knowledge. Below are some tips on possible causes of bad "Core Web Vitals" and how to optimize them.
Optimate Largest Contentful Paint (LCP)
Possible causes for bad LCP values
- Slow server / long response time
- JS und CSS block rendering
- Slow loading resources such as images, videos, widgets, social media buttons, newsletters...
Optimization measures
- Use a suitable server with modern and fast technology
- Combine and compress JS and CSS files and remove unnecessary files
- Asynchronous loading of resources
- Optimize images and videos in terms of number, size and format. Use lazy load
- Show placeholders instead of videos
- Minimize http requests
- Use caches
- Use Content Delivery Network (CDN) if the website has a lot of international visitors
- Load unnecessary widgets and co. later
Optimate First Input Delay (FID)
Possible causes for bad FID values
- Long main thread tasks in JavaScript
- Long JavaScript execution time
- Large JavaScript packages
- JavaScript blocking rendering
Optimization measures
- Reduce number of loaded scripts
- Split longer tasks into smaller tasks
- Reduce JavaScript execution time
- Third-party tags: If possible, load on demand
Optimate Cummulative Layout Shift (CLS)
Possible causes for bad CLS values
- Images, videos and iframes without size specifications
- Ads that shift layout
- Cookie banner
- Web fonts that cause FOIT or FOUT
Optimization measures
- Add size attributes to images, videos and iframes
- Do not overlay content
- Use CSS property "font-display"
- Preload fonts. Attention: Performance deteriorates
More performance values
In addition to the "Web Core Vitals", there are a number of other performance values that are useful when analyzing a page.
Total Blocking Time (TBT)
"Total Blocking Time" measures the total time a site is blocked. During this time, the user cannot interact with the site. This metric was introduced by Lighthouse. It can be viewed as a replacement for the FID metric such as that used in PageSpeed Insights.
TBT has a huge impact on a page's score, making it one of the most important metrics to optimize. Optimizing them can effectively improve the responsiveness of a page.
Strictly speaking, "Total Blocking Time" is the total time between "First Contentful Paint" (FCP) and "Time to Interactive" (TTI) that the main thread was blocked long enough to prevent the input from being responsive. The main thread is used by the browser to parse HTML, construct the DOM, execute CSS and JS, handle user events, and perform other tasks. The main thread is considered "blocked" if one of the tasks lasts longer than 50ms. A running task cannot be interrupted by the browser. As long as the main thread is blocked, a website cannot respond to user input (e.g. mouse clicks, keyboard clicks, ... etc.).
The times that exceed 50ms are referred to as blocking times. The total blocking time of a page results from their sum.
Thresholds for "Total Blocking Time" (TBT)
| good | moderate | poor | |
| TBT | < 300ms | 300 - 600ms | > 600ms |
Optimization measures
There are several ways to minimize the "Total Blocking Time" (TBT). In principle, the same improvement measures (JS optimization) apply here as for the "First Input Delay" metric. For details, see the top of the page under the heading "Optimize Core Web Vitals"!
Difference between "Total Blocking Time" and "First Input Delay"
As already mentioned, "Total Blocking Time" (TBT) is a replacement for "First Input Delay" (FID), which belongs to the "Core Web Vitals". FID is a field metric that uses real user data to measure. These come from the Chrome User Experience Report (CrUX), whose data is collected from real Chrome users.
Difference between "Total Blocking Time" and "Time to Interactive"
"Time to Interactive" (TTI) is another value that refers to the interactivity of a page:
- TTI signals when a page is fully interactive
- TTI considers a page fully interactive as soon as the main thread has been free of long tasks for at least 5s
TBT, on the other hand, indicates exactly which JavaScript tasks took the longest to execute.
Time To First Byte (TTFB)
"Time to First Byte" (TTFB) is the total time from the start of a request to the receipt of the first byte of the response. It is the sum of Redirect Duration + Connection Duration + Backend Duration. This metric is one of the key indicators of web performance.
Explanations
- Redirect Duration: Time to redirect from example.com to www.example.com, or http to https, or to a mobile version or a language version of a page.
- Connection Duration: Time it takes to connect to the server to send the request to the page. The connection duration is usually the combination of blocking time, DNS time, connection time and send time of the request.
- Backend Duration: After the request, the server generates a response for the page. The time it takes to do this is called the backend duration.
Optimization measures
- Optimizing the code
- Use of caching
- Upgrading the server hardware
- Fine tuning of the web server configuration
First Paint
"First Paint" is the point at which the browser begins rendering a page. The browser then only displays an empty page. For the visitor to the website, this is an indicator that the page is now loading. Otherwise, "First Paint" has no further relevance.
First Contentful Paint (FCP)
"First Contentful Paint" measures how quickly visitors to a web page see the first element of content. This can be e.g. headings, texts, images ... etc.
Srictly speaking, "First Contentful Paint" is the total time from when a page starts loading to when content is rendered on screen. Content that is delivered quickly (low FCP time) contributes to a positive user experience.
DOM Interactive Time
"DOM Interactive Time" is the time when the browser has finished loading and parsing HTML and the DOM tree structure has been built. DOM = Document Object Model
DOM Content Loaded Time
"DOM Content Loaded Time" is the time when the DOM is ready and there are no stylesheets blocking JS execution.
By the way, if no stylesheets are blocking JS execution and no parser is blocking JavaScript either, then "DOM Content Loaded Time" is the same as "DOM Interactive Time".
Important: It is important that the style and script order are optimized and the parsing of JavaScript is delayed. Otherwise there may be delays in rendering.
Alternate expressions: DOM Loaded, DOM Ready
Onload Time
"Onload Time" is the time when processing of a page is complete and all resources (e.g. CSS, images, ... etc.) have been downloaded. Then the page fires the "windows.onload" JS trigger event.
However, there may be JavaScript that triggers subsequent requests for more resources. "Onload Time" can therefore indicate a page is slower as well as faster than it really is. "Fully Loaded Time" is more meaningful.
Fully Loaded Time
"Fully Loaded Time" is the point in time after all of the following events have occurred:
- First Contentful Paint has fired
- Onload has fired
- Network and CPU are idle (5.25s)
In legacy reports, "Fully Loaded Time "is measured when:
- Onload has fired
- Network is inactive (2s)
There is a hard time of 30s after onload is fired.
If the above conditions are met, GTmetrix, for example, will use maximum values of
- First Paint
- First Contentful Paint
- Onload Time
- Largest Contentful Paint
- Total Time to Interactive
- Last request captured
Essentially, GTmetrix waits until your page finishes transferring data before completing a test, resulting in more consistent page load times.
Nevertheless, various problems can arise, which will not be discussed in detail here. The "Fully Loaded Time" may therefore not be an optimal indicator of user-perceived performance. It is therefore better to focus on optimizing the 6 performance evaluation metrics.
"Fully Loaded Time" in legacy reports
Legacy reports have a slightly different definition for "Fully Loaded Time" because they don't measure the "Time to Interactive" metric. "Fully Loaded Time" means the point in time after 2 seconds of network inactivity after the onload event was triggered.
Due to the different definitions, the "Fully Loaded Time" in a legacy report may not match the time in the new report (e.g. from GTmetrix).
