Stay with us to get to know the new update of GT Metrics.
With Google’s official announcement about the importance of having PX or page experience in ranking websites, the GTmetrix website, has developed its website speed analysis system using API. Updated Lighthouse and now analyzes websites based on Lighthouse variables. For this reason, many websites that were previously measured and fixed using the previous algorithm, now have problems and need to be updated and fixed the errors identified by the new method.
Table of Contents
What changes have occurred?
As you can see, performance scores have been replaced by GTmetrix grades, as a result, there is no longer any trace of page speed score and Yslow score, and Performance and Structure have taken their place. Also, in the WEB Vitals box, LCP, TBT, and CLS options have replaced Page load Time, Total Page Size, and Request in the page details box. Therefore, it is necessary to get acquainted with each of these items in the new GTmetrix reports.
What is Performance?
Performance means the performance and efficiency of your desired website. Which is measured based on the lighthouse algorithm and its results are presented to you as a percentage.
What is Structure?
“Structure” means “structure” and G-metrics means measuring the structure of your website, which is checked based on the PX algorithm, and its results are displayed as a percentage.
What are WEB vitals?
Important note: In this article, we mean Web Vital only that part of the evaluation criteria of Web Vital that has a user in the new algorithm of the GT Metrics website, so we will not provide a general and comprehensive definition of it. Click here to read more.
Web Vital is a small set of key metrics that show whether you are providing your visitors with the fast experience that Google expects. Google introduced a new concept in 2020 called “WEB Vitals” that focuses on a small set of core metrics to evaluate your page experience. Given the many timelines and audits for evaluating page performance, this small collection represents the most influential metrics to focus on to simplify the world of web performance.
Each metric represents a major aspect of the page experience, namely loading, interaction, and visual consistency.
Web Vital basically measures your page for 3 main metrics that define a fast-performing page. The importance of Web Vitals is further emphasized by the fact that they constitute half of the performance score calculation criteria.
In the following, we will describe these Google speed measurement criteria.
What are the different Web Vitals?
Web Vitals in GTmetrix focus on three performance score metrics:
- Largest Contentful Paint (LCP)
- Total Blocking Time (TBT)
- Cumulative Layout Shift (CLS)
Important Note: Note that TBT is used instead of First Input Latency (FID) because GTmetrix is a synthetic test and FID is a true metric that is only available with Chrome User Experience Reports (CrUX).
Why is Web Vital important?
There is a large set of performance metrics available and it can be difficult to understand which ones to analyze and optimize unless you are a professional web developer. Web Vital therefore serves as a simple measure of user experience in terms of perceived performance, interaction, and enjoyment.
When considering your page performance, your primary focus should be on this smaller set of metrics. In addition, Web Vital represents what visitors see when they first visit your web page, what they see first will ultimately affect their perception of your page’s performance. Focusing on these three metrics first allows you to make useful optimizations in real, understandable performance before attempting other optimizations.
In the following, we will describe these Google speed measurement criteria.
What does LCP mean in GT metrics?
LCP tells you how long it takes for the largest content element (eg a slider image or main headline) on your page to be visible to visitors. In simpler words, it shows how fast your page loads. For a great user experience, LCP should be less than or equal to 1.2 seconds.
Largest Contentful Paint overview
Largest Contentful Paint (LCP) is a performance benchmark introduced in 2020 by Lighthouse to better measure a comprehensible loading experience for users. In simpler terms, LCP measures how long it takes for the largest “content element” (eg, hero image, headline text, etc.) on your page to be visible in your visitor’s view. LCP is one of the metrics that make up Google’s Web Vitals.
What does LCP measure?
According to Google: “LCP is an important user-centric metric for measuring perceived loading speed because when the main content of a page loads, a fast LCP reassures the user that the page is useful.”
Basically, LCP measures how quickly your visitors are consuming significant content on your web page. The assumption is that loading the largest content element on your page, such as a carousel or hero image, is a key indicator of loading your page for your visitors.
A “content element” is any HTML element, such as:
- An image element
- A video element
- An element whose background image is loaded via the URL function (rather than declaring it in CSS)
- Block level elements like <h1>, <h2>, <div>, <ul>, <table> etc.
GTmetrix measures how the largest content element at the top of the page is drawn on your page. Websites with a similar structure may score very differently on the LCP metric because the largest content element will vary from page to page. LCP is an easy metric to understand because all you have to do is look at your web page, identify the largest block of text or image, and then optimize its load time.
The effect of LCP on your performance score
As a Web Vital metric, LCP accounts for 25% of the performance score and is one of the most important SEO metrics. While other metrics like First Contentful Paint (FCP) or Time-to-First-Byte (TTFB) remain in the context of page speed, LCP represents what your visitors expect in the real world when they access your website.
A faster LCP gives the impression that your page will load faster. As you can see, the green website looks visually more complete than the red website by 0.2 seconds. What that means for you is that your LCP optimization can make the biggest improvement in your website’s performance, both in terms of performance score and performance visitors.
Optimal threshold of LCP performance
LCP thresholds are measured by the render time (in seconds) of the largest visible image or text block in the visitor’s viewport.
The LCP threshold is as follows:
OK – nothing to do here = LCP 1200ms or less.
Acceptable, but consider improvement = LCP between 1200 and 1666 ms.
Greater than recommended = LCP between 1666 and 2400 ms.
Much more than recommended = LCP higher than 2400 ms.
The largest color content element (LCP) in the structure tab
You can see what GTmetrix has identified as the largest content element on your page in the Structure tab of the report. “Largest Contentful Paint Element” is mentioned in the audit list.
How can LCP be improved?
The specific audits listed below will help your LCP the most. However, your page’s LCP timing may be affected by other optimizations not listed here.
Improve your LCP time by using good web development practices, including:
Reduce server response time
Reducing server response time helps to load resources faster and deliver LCP on the page faster. Some of the things you can do here include:
Reduce initial server response time
Using a Content Delivery Network (CDN)
Use cache
Faster communication with third-party links
Eliminating render-blocking behavior
Removing render-blocking behavior on your page ensures that resources load as quickly as possible.
Optimizing images and videos
Optimize the loading of images and videos on your page to reduce the loading time of images and videos. Some of the things you can do include:
- Appropriate size of images
- Proper encryption of images
- Combine images using CSS Sprites
- Using images in new and small formats
- Use video formats for animated content
What is the TBT criterion and what is its minimum acceptable level?
TBT tells you how long the page has been blocked by scripts in the loading process. Also, for a good user experience, you should aim for a TBT of 150ms or less. In other words, this measure shows how usable your web page is during the completion of loading.
In a general view from the lighthouse perspective, Total Blocking Time (TBT) is a lighthouse performance measure that was introduced in 2020 and quantitatively evaluates the responsiveness of your page load to user input. In other words, TBT measures the total time your web page is blocked, preventing user interaction with it. This is one of Vital Web’s programs that is intended as an alternative to FID for PageSpeed Insights.
What is Total Blocking Time (TBT)?
According to Google, “TBT measures the total time between First Contentful Paint (FCP) and Time to Interactive where the main part is blocked to prevent input from responding.”
Basically, the browser uses what is called the main thread to parse HTML, build the DOM, execute CSS and JavaScript, process user events, and do other important tasks. When any of these tasks run for more than 50 milliseconds (also known as a long-running task), the main thread is considered “blocked” because the browser cannot interrupt an ongoing task.
If the main thread is blocked, your page cannot respond to user input such as screen taps, keyboard presses, or mouse clicks. Additional time of more than 50 milliseconds is considered the individual blocking time of that request. The sum of all these blocking times will be the total blocking time of your page.
Anything longer than 50 milliseconds is considered a long task. The above example has 3 long tasks (in red).
For example, in the image above, there are 5 tasks in the main topic, 3 of which are Long Tasks, because their duration is more than 50 milliseconds. The blocking time for each long task is as follows:
- Task A – 220 ms
- Task B – 70 ms
- Task E – 145 ms
TBT in this scenario is 435 mm. If, however, the main thread had only one task that took 500 milliseconds, the TBT would be 500 milliseconds.
Total blocking time vs interactive time
Time to Interactive (TTI) is another metric that relates to the engagement of your page. TBT and TTI are complementary but at the same time offer completely different views of your page experience. TTI signals when your page is fully interactive, but TBT specifically tells you which JavaScript tasks took the longest time.
The TTI metric considers a page to be fully interactive if the main topic is free of lengthy tasks for at least 5 seconds.
Consider the following scenarios for further explanation:
- Three 60-millisecond tasks are played in a 5-second period.
- A long 5-second job.
Both the above scenarios will delay the TTI equally.
However, both scenarios are very different from the user’s point of view as the first scenario has only 30ms TBT while the second scenario has 4950ms. Scenario A is mostly interactive during page load, as no long task takes up the browser’s time, while scenario B is not interactive at all while the browser is busy doing long tasks.
Comparison of total blocking time versus first input delay
As mentioned earlier, TBT is an alternative to First Input Latency (FID), which is one of Vital Web’s applications, but FID is only a field metric that requires real user data to measure. This real user data is in the form of Chrome User Experience Reports (CrUX) – a database of Chrome browser behavior collected from real-world Chrome users, something GTmetrix could not use in its testing.
Therefore, GTmetrix tests report TBT instead of FID because it serves as a suitable alternative method and recommends the same optimizations.
The extent to which TBT affects your website’s performance score
As a Web Vital metric, TBT accounts for 25% of the performance score, making it a top indicator for optimization. What this means for you is that optimizing your TBT can make one of the most impactful improvements in your website’s responsiveness.
Total Blocking Time Threshold (TBT)
TBT measures the total time between FCP and TTI when the page responds to user input and displays the result in milliseconds.
TBT thresholds are as follows:
- OK – nothing to do here = TBT 150ms or less.
- Acceptable but consider improvement = TBT between 150 and 224 ms.
- Greater than recommended = TBT between 224 and 350 ms.
- Much more than recommended = TBT higher than 350ms.
How can TBT be improved?
Note that the specific audits listed below will contribute the most to your TBT. However, your entire page blocking time may be affected by other optimizations not listed here.
Total block time has a lot to do with JavaScript performance, and any improvement in JavaScript execution (in general, optimizations that improve TTI) will likely lower your TBT. If your website is WordPress, you can reduce it by using the JS minify plugin.
Some of these optimizations are:
- Reduce JavaScript execution time
- Minimizing the work of the main subject
- Remove unused JavaScript
- Reducing the impact of third-party codes
- Replacing large JavaScript libraries with smaller alternatives
What is CLS or Cumulative Layout Change and what is its minimum acceptable score?
CLS shows how many layers visitors experience when loading your page. In fact, it shows how stable your website page is when loading and whether there are any big changes in it or not. You should consider a CLS score of 0.1 or less to have a good user experience.
Cumulative Layout Shift (CLS) is a performance metric introduced in 2020 by Lighthouse to measure the perceived visual stability of page load. Simply put, CLS measures unexpected repositioning of web elements during page rendering. This measurement is then determined as an overall score of all the individual layout changes on your page. CLS is also one of the criteria that make up Google’s WEB vitals. Learn more about Google WEB Vital functionality here.
What does Cumulative Layout Shift measure?
According to Google: “CLS is an important, user-centric metric for measuring visual consistency because it helps you determine how often users experience unexpected layout changes. A low CLS score assures you that the page is pleasing.”
Whenever a page is loaded, some elements of the page are moved unexpectedly, which affects how users interact with the web page.
As the page loads, red images cause movement, adjustment, and displacement of other elements, contributing to a bad CLS score.
These elements can be buttons, contact forms, images, videos, fonts, or other types of content. A website with low CLS has a stable display that does not move elements around and ensures consistent and predictable loading of all website content.
Green images are specified with width and height to ensure a stable and predictable display of your website when loading and to minimize layout change.
Reducing the page’s CLS is important because pages whose elements move around until they fully load can lead to a negative user experience (especially on mobile devices).
Unexpected layout changes often result in unintentional clicks/taps on unwanted content.
For example, we’ve all experienced situations where we’ve been waiting for a page to load, and found a button we’ve been meaning to interact with. However, just as we’ve clicked or tapped on it, the screen scrolls down and we’ve clicked or tapped on another link entirely, often an ad or The link is irrelevant.
The difference between what we expect versus what happens due to unexpected change
It is important to note the difference between expected and unexpected displacements. An expected layout change occurs in response to user input. For example, clicking the search icon expands an input field. On the other hand, unexpected layout changes are usually caused by third-party content, dimensionless images, or other dynamic content. For example, an ad pops up and pushes an image or content to the bottom of the page.
GTmetrix differentiates between expected and unexpected layout shifts, except layout shifts that occur within 0.5 seconds of user login.
The impact of CLS on your performance score
Even though the direct effect of CLS on performance scores is relatively small (5%). This is a major contributor to “user delight” – that is, providing your visitors with a smooth, lag-free experience. While some other performance score metrics are directly related to page load speed, CLS focuses on measuring your visitor’s page experience. Its importance is further proven by its inclusion in the Web Vital collection.
What is the CLS Cumulative Layout Change Threshold?
It’s important to note that CLS is a score – not a timing in milliseconds or seconds. This is calculated using the offsets detected in the browser, resulting in a final number between 0 and 1.
The CLS points threshold is as follows:
- OK – nothing to do here = CLS 0.1 or less.
- Acceptable, but consider improvement = CLS between 0.1 and 0.15.
- Greater than recommended = CLS between 0.15 and 0.25.
- Much more than recommended = CLS 0.25 or higher.