Since May 2021, Google has been using Core Web Vitals as a ranking factor. Core Web Vitals are metrics designed to evaluate a website’s user experience. Google aims to track the user experience of a website with a focus on technical aspects. All pages of a website are analyzed – even noindex pages can be included in the Core Web Vitals, according to John Mueller.
The Core Web Vitals are among the Page Experience Factors. This includes the HTTPS security protocol, which Google has included in its ranking factors since 2014. Anyone who hasn’t yet switched over their site should do so as soon as possible. Furthermore, websites with popular pop-up ads will be penalized in the future. This reduces user interaction with the website, as one less click is required to engage with the page. However, this doesn’t mean that the user experience will also be worse. With the help of good content, calls to action, chatbots, sidebars, etc., the site should be designed to be as attractive and engaging as possible to provide users with a good user experience and interaction.
Web Vitals weren’t used as a ranking factor before 2021. It’s still recommended to address Core Web Vitals as soon as possible, as the optimizations are more complex and therefore require a certain amount of time. Furthermore, early optimization is also better for customer satisfaction. Websites that have a short loading time and are user-friendly not only positively influence the Google algorithm but also increase user satisfaction.
Influencing positions through Core Web Vitals
A study by Screaming Frog shows that fewer than 15% of websites meet Google’s criteria.
For the Largest Contentful Paint metric, 43% of mobile URLs and 44% of desktop URLs meet the criteria. For the Cumulative Layout Shift metric, 46% of mobile URLs and 47% of desktop URLs meet the criteria. These findings demonstrate that the majority of users accessing content on websites experience loading times of more than 2.5 seconds and even experience content that jumps in front of their eyes.
Results of the current study by Screaming Frog
The following figure shows the percentages of mobile devices and desktop devices in relation to the success rates of the respective positions in Google. The figure clearly shows that URLs in the first position in Google have a success rate of 19% on mobile devices and 20% on desktop devices.
For positions two to five, the success rate decreases steadily. This means that for each lower position, the success rate drops by 2%.
The success rates in the tests for mobile devices for positions five to nine are predominantly 10% and for desktop devices 11%.
URLs that rank first in Google are therefore 10% more likely to meet the Core Web Vitals criteria than those in position nine.
Based on the study’s findings, it’s highly likely that Core Web Vitals impact Google rankings, even though they aren’t officially ranking factors yet. Screaming Frog considers the probability very low, but doesn’t want to completely rule out this possibility.
Loading speed plays a key role in Web Vitals. This criterion is already factored into Google’s rankings. Faster websites also rank better. The lower the ranking today, the lower the likelihood of meeting the Core Web Vitals criteria. Since loading speed is not a primary factor for ranking, better content quality also plays an important role.
Google defines the following three metrics to measure Core Web Vitals.
The measured values LCP, INP, and CLS
Largest Contentful Paint (LCP)
This metric determines the time it takes for the website’s primary content to appear in the user’s browser. In the past, Google evaluated the content that was visible first. Now, however, the moment the primary content becomes visible is used as the evaluation time. This time is calculated in seconds. Google defines less than or equal to (≤) 2.5 seconds as good. Up to 4 seconds is considered to need improvement, and more than 4 seconds is considered poor.
New LCP calculation starting with Chrome 112
In April 2023, it was announced that the Largest Contentful Paint calculation would change with Chrome 112. Images with little content relative to their size will be ignored in the future. Instead, the Largest Contentful Paint calculation will now focus much more on text or on images with more text.
This means that very large background images, placeholders, or graphics, for example, will be excluded from the calculation. Images with very small content relative to their display size (limit = 0.05 bits of image data per pixel) will also be ignored.
Conclusion: This can be particularly beneficial for websites with backgrounds with little or no content.
First Input Delay (FID)
The FID measures the interaction time between the user and the page. When a website’s content is fully visible, visitors want to interact with the page as quickly as possible. The speed of this interaction is determined by the First Input Delay. The FID calculates the time it takes for the browser to respond to a user request. For Google, this metric defines interaction times of less than (≤) 0.1 seconds as good, up to 0.3 seconds as poor, and interaction times of more than 0.3 seconds as poor.
NOTE: The FID metric will be replaced by the new Interaction to Next Paint metric starting in March 2024.
Interaction to Next Paint (INP)
Interaction to Next Paint is a metric that evaluates a website’s responsiveness. If an interaction causes the page or certain features to stop working properly, this automatically leads to a poor user experience.
So if an accordion, for example, does not open properly when clicked (interaction), but folds back, this is measured with the INP.
The new metric will be implemented in March 2024. From this point on, the FID metric will no longer be available or displayed in the Google Search Console.
Cumulative Layout Shift (CLS)
This metric focuses on the visual stability of a website. Some very complex websites load portions of their content asynchronously. This can ensure shorter loading times for the user. If these loading processes are not coordinated, the displayed content of the page can start jumping up and down in front of the user’s eyes, even though the user is already eager to read it. For the CLS, Google defines a value of less than (≤) 0.1 as good, up to 0.25 as requiring improvement, and more than 0.25 as poor.
The following figure shows an example of the Core Web Vitals. It shows the poor URLs, those in need of optimization, and the good URLs, and explains them in more detail below.
The following example shows a specifically selected URL. The CLS, FID, and LCP metrics are visible.
However, Google is still considering changes to Core Web Vitals and does not want to commit exclusively to these three metrics for evaluation. Any changes or additions to the metrics will be announced on time.
How do you measure Core Web Vitals?
Google uses two approaches to measuring Core Web Vitals: lab data and field data. A combination of both approaches is recommended to achieve the best possible results for measuring Core Web Vitals.
Laboratory data
As the name suggests, this type of data acquisition involves conducting measurements in the lab under self-controlled conditions. Laboratory data is, therefore, estimated data generated in a simulated environment.
One advantage of this type of data is that it always generates the same results unless changes are made to the variables or conditions. The quality of this data, therefore, depends on the specified measurement conditions. However, laboratory data does not reflect real user behavior, which can be considered a negative aspect.
Field data
For field data, Core Web Vitals values from real users of your website are gathered and processed. This may be done via custom JavaScript integrations or through automated measurements. Google itself takes field data in the Core Web Vitals report from the Google Search Console.
How do you optimize Core Web Vitals?
There’s no easy, straightforward solution to improving Core Web Vitals (Page Experience Factor), as every website is unique. Each website needs to understand its own Core Web Vitals and then optimize them individually to achieve the desired goal. Gaining the necessary understanding of these Core Web Vitals sometimes requires in-depth expertise, as Core Web Vitals can be technically very complex.
Google itself has identified some optimization options, which you can see here.
Start Lighthouse test via Developer Tools in Chrome
To evaluate the LCP and CLS values, you should first create a Lighthouse test using the Developer Tools (right-click + Inspect). Then, perform the direct analysis. Important: Both desktop and mobile versions should be analyzed.
Note: Clicking “Generate report” will reload the page. This typically takes between 15 and 90 seconds.
Check website performance
For a detailed analysis of the individual measured values, we go to the “Performance” tab:
And then click on “View Original Trace”:
Now we get the following view:
CLS optimization: Procedure for a poor CLS value:
To analyze the CLS value, we check the following different elements:
- Timing: LCP, FP, FCP, DCL, and L
- Experience: all layout shifts (clear reload recording)
- Performance: Rendering frames
This results in the two most common CLS errors:
- Images only load at the correct size after the page has loaded.
Problem: The layout shifts because no space has been reserved for the image.
Solution: Define the correct size and position. If the image is in a container, this element can also be specified to prevent the layout from shifting. - Child themes that overwrite the parent theme’s style.
Problem: The parent theme’s data is loaded first and then overwritten with the child theme’s data. This custom CSS not only causes layout shifts but also increases loading times.
Solution: Insert critical CSS in the page’s header. Ideally, all rules should be defined in the page’s header so they don’t have to be loaded via additional CSS. This way, they are immediately available when the page is rendered.
In general, care should be taken with CLS to avoid changing the size of the components. The size specifications of video segments or images also play an important role. Furthermore, no automated content should be inserted at the beginning of the page.
LCP optimization: Procedure for a poor LCP value:
When it comes to the LCP value, we also check the HTML elements “Timings” and “Related Load”.
Often, the problem isn’t necessarily related to the HTML elements. In these cases, other possible causes come into play:
- The image file is too large.
Solution: Reduce resolution and improve compression. - The font was not implemented correctly.
Solution: Set the CSS property font-display: swap; - General problems with server response times or HTML loading times
Solution: Use caching plugins or similar server-side optimizations
Relevant for the LCP are the server response times, rendering blocking, resource loading times, and client-side rendering.
FID optimization: Procedure for a poor FID value:
There’s no precise procedure for analyzing the FID value, as this requires a “real user.” However, you can use the TBT (Total Blocking Time) value as a guide. Optimizing the TBT value usually has a positive effect on the FID value.
We also find this value in the Developer Tools:
The TBT value indicates how long a page takes to load before a user interacts with it for the first time, for example, a mouse click, scrolling the page, etc. This value is made up of FCP (First Contentful Paint) and TTI (Time to Interactive).
The measured value here is 50ms. Any task that takes longer than 50ms to load contains a total blocking time. For example, if something takes 350ms to load, the blocked time is 300ms. This, in turn, is perceived by the user as a delay.
Complex JavaScript code is usually responsible for this.
The solution here is to reduce all scripts that aren’t required for the visual layout. This is done using the “defer” attribute.
The following aspects are therefore important for the FID: accelerating JavaScript execution, relieving the load on the main thread, and reducing requests and file size.
Which CMS achieves the best results
CMS users often find it difficult to optimize their sites for Core Web Vitals. Good performance depends on the coding of the webmaster provider. This means that users have only limited influence on their Web Vitals results.
HTTP Archive analyzed the top 5 CMS:
Largest Contentful Paint
When the page and its contents are visible
Winner: Drupal | Loser: Wix
The results:
- Drupal – 47%
- Joomla – 38%
- WordPress – 25%
- Squarespace – 12%
- Wix – 9%
First Input Delay
The first time of a possible interaction
Winner: Squarespace | Loser: Wix
The results:
- Drupal – 91%
- Joomla – 88%
- WordPress – 76%
- Squarespace – 71%
- Wix – 46%
Cumulative Layout Shift
The visual stability of the website
Winner: Drupal | Loser: Squarespace
The results:
- Drupal – 70%
- Joomla – 63%
- WordPress – 59%
- Squarespace – 57%
- Wix – 44%
Overall, all systems have room for improvement, as they all perform well for the FID value. However, the CLS and LCP values aren’t so great.
WordPress Plugins to Improve Core Web Vitals
Additionally, some plugins support improving Web Vitals in terms of loading speed, image compression, and much more. While a plugin won’t be able to optimize everything, it can still contribute immensely to improvements.
The following WordPress plugins support the website about the new 2025 ranking factor:
Autoptimize
- Minification of images, HTML, and CSS
- Optimization and lazy loading of images
- Optimization of Google Fonts
- …
WordPress FEO
- Optimization of HTML, CSS, and JavaScript
- Image compression (supports Google Cookies and WebP)
- Lazy loading of images
- Advanced caching with PHP Opcache is possible
- and much more…
Humming Bird
- Text compression
- Efficient caching
- Optimization of JavaScript executions
- Moving critical JavaScript and unused CSS
- Minification of CSS and JavaScript
- many other features
Smush
- Optimization and compression of images
- Lazy loading
- and much more
Tips for WordPress users to improve performance
The following tools can be used to test WordPress performance:
- PageSpeed Insights (from Google)
- Pingdom Website Speed Test
- GTmetrix
Optimize overall WordPress performance using:
- Check theme and settings (e.g., slider, comment function, etc.)
- Use standard loop:
- Clean up style.css (Addon for Firefox: CSS Usage)
- Optimize style.css (e.g., with a plugin like CSS Minify)
- Inline CSS instead of CSS file – check first!
- Remove unnecessary JavaScript (usually in the head area)
- Use the CDN service
- Delete unnecessary plugins
Snippets for better WP performance:
- Remove unnecessary links in the head
- Turn off comments
- Adjust thumbnail quality
- Turn off RSS feeds
- Minify HTML
- Block HTTP connections: define(‘WP_HTTP_BLOCK_EXTERNAL’, true);
- Disable WordPress Heartbeat API
- Disable emoji support
- Disable embeds and responsive images
- Disable XML-RPC
Conclusion
It makes a lot of sense to start making adjustments now. Optimization helps visitors and improves the user experience. And improved usability contributes to better rankings today and will likely significantly improve your Google ranking tomorrow.
Frequently asked questions about Core Web Vitals.
What are the Core Web Vitals metrics, and why are they important to the user?
The Core Web Vitals metrics provide a relevant tool for better understanding and optimizing the user experience of your website. The Core Web Vitals metrics are Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift.
Does Google recommend that all my pages meet these thresholds? What benefit will I get from doing so?
It is recommended to use all three thresholds for a website as a guideline to achieve the best possible user experience. These values are viewed at the page level. Many web pages fall below or above these values. Users will notice this and conclude the user experience. It is important to pursue a common goal for these metrics and associated thresholds to maintain a healthy web ecosystem. The benefit of achieving the thresholds is clear: it ensures a better user experience.
Does an AMP page (Accelerated Mobile Page) meet the recommended values?
Since AMP pages are designed to improve mobile speed, they are very likely to meet the metric thresholds. AMP pages have a timeless nature and provide users with the added value of faster loading times on mobile pages for a long time. Therefore, one advantage of these pages is that performance improvements can be achieved without fundamentally changing the foundation. However, there are certain points that AMP pages do not cover regarding the thresholds, which is why pages may not meet these thresholds.
Can a page reach the thresholds without AMP?
A page can meet the recommended thresholds even without AMP. Using AMP allows you to incorporate web development best practices into the framework without additional effort.
Does my website meet the recommended thresholds if it is a progressive web app?
This isn’t mandatory. It depends on the app’s implementation and the actual user experience. Therefore, it makes sense for all websites, whether progressive web apps or not, to focus on loading speed, interactivity, and layout stability. All progressive web apps should therefore follow the Core Web Vitals guidelines.
Meet recommended thresholds if it is a single-page web application?
Core Web Vitals measure user experiences. They do not consider the technologies used to deliver those experiences. Core Web Vitals metrics are just as relevant for single-page web applications as they are for other technologies. Therefore, the chosen technology or architecture is not important; what matters is the observed user experience.
My website is also mobile-friendly. However, my Core Web Vitals score for mobile is low. Why is that?
Core Web Vitals and mobile friendliness should not overlap, but rather complement each other. This ensures a holistic optimization of the user experience.
How can I improve my LCP/CLS/FID score?
The optimization options for Core Web Vitals have already been mentioned in the article. You can also read more about them at web.dev/fast. Knowledge of web development is essential for optimizing Core Web Vitals. Therefore, we recommend consulting a specialist.
Why do the scores differ between mobile and desktop?
Currently, page experience is only relevant for mobile search. Therefore, user experience only impacts mobile search rankings. Furthermore, desktop and mobile users may be limited in all areas, such as device, viewport size, or network connectivity.
Can sessions that do not report an FID be considered “bounce” sessions?
No, they can’t. Bounce rate and abandonment rate are not considered when designing Core Web Vitals metrics.
How do Core Web Vitals take websites that use older devices or slower networks into account?
Here, it is especially useful to adapt the content of these web pages to ensure that users still receive an optimal user experience and thus meet the recommended Core Web Vitals thresholds.
Is the ranking influenced by Core Web Vitals?
Starting in May 2021, Core Web Vitals will be included in the page experience signals along with existing signals such as Mobile Friendly, Safe Browsing, HTTPS Security, and Intrusive Interstitial Policies.
How does Google determine which pages are affected by the user experience evaluation and application as a ranking signal?
The user experience is a major factor in page ranking. However, search query intent still has a significant impact on rankings. This makes it possible for a website to still rank well in Google (through relevant and thematically appropriate content) even if the page experience is below average.
What if websites don’t meet Core Web Vitals scores?
Predicting this is rather difficult. However, it’s important to remember that the page’s content is still an important signal.
What can you learn about Core Web Vitals from Search Console?
Google Search Console provides the Core Web Vitals Report. This report is based on Chrome UX Report data. The report is designed to help uncover user experience issues and ensure that the Google Search Console Core Web Vitals Report aligns with the status of individual Core Web Vitals on the website.
The website is fast, but there are warnings in the Core Web Vitals report in Search Console. Why?
It’s important to note that Core Web Vitals don’t just focus on speed, but also on the website’s visual stability, for example. Furthermore, different devices, network connections, and other factors can determine how a website loads and thus appears to users.
I don’t see any errors in Lighthouse, but I do see them in the Search Console report. Why?
The Core Web Vitals report shows real-world user data. Lighthouse’s data, on the other hand, is collected using lab data, which means it’s possible that bottlenecks aren’t documented. Therefore, the information in each report differs. However, both reports can be used.