Google Core Web Vitals

Author
Published

Google Core Web Vitals

Since May 2021, Google has been using Core Web Vitals as ranking factors. Core Web Vitals are metrics designed to assess a website's user experience. Google aims to track the user experience of a website by focusing on technical aspects. All pages of a website are analyzed, and according to John Mueller, even noindex pages can be included in the Core Web Vitals assessment.

Core Web Vitals are part of the Page Experience factors, which also include the HTTPS security protocol that Google has considered in its ranking factors since 2014. If your site hasn't been updated yet, you should address this as soon as possible. Additionally, websites with popular pop-up appearances will be penalized in the future. This reduces user interaction with the website, as one less click is needed to engage with the site. However, this does not necessarily mean that the user experience will be worse. By using good content, call-to-actions, chatbots, sidebars, etc., the site should be made as attractive and engaging as possible to provide users with a good user experience and interaction.

Core Web Vitals were not used as a ranking factor before 2021. It is still recommended to address the topic of Core Web Vitals as soon as possible, as optimizations are complex and require a certain amount of time. Furthermore, early optimization is better for customer satisfaction. Websites with short load times that are user-friendly not only positively influence the Google algorithm but also increase the satisfaction of their users.

 

Contents of the article:

  1. Impact of positions by Core Web Vitals
  2. The metrics LCP, FID, and CLS
  3. How to measure Core Web Vitals
  4. How to optimize Core Web Vitals
  5. Which CMS achieves the best results
  6. WordPress plugins to improve Core Web Vitals
  7. Tips to improve WordPress performance
  8. Conclusion

 

Impact of positions by Core Web Vitals

A study by Screaming Frog shows that less 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 indicate that the majority of users who access content on websites have to deal with load times of more than 2.5 seconds and even see content shifting before their eyes.

 

Results of the current Screaming Frog study

The following figure shows the percentage success rates for mobile devices and desktop devices concerning their respective positions in Google. The figure clearly shows that URLs in the first position on Google have a success rate of 19% on mobile devices and 20% on desktop devices.
For positions two to five, the success rate consistently decreases. This means that for each lower position, the success rate drops by 2% each.
The success rates in tests for mobile devices in positions five to nine are mostly 10%, and for desktop devices, it is 11%.
URLs in the first rank on Google therefore have a 10% higher chance of meeting the Core Web Vitals criteria than those in the ninth position.

Source: Screaming Frog

Based on the study results, it is very likely that Core Web Vitals affect positions on Google, although they are not officially ranking factors yet. Screaming Frog considers the likelihood to be very low but does not want to completely rule out this assumption.

Load speed plays an important role in Web Vitals. This criterion is already included in the Google ranking. Faster websites also have better rankings. The lower the position today, the less likely it is to meet the Core Web Vitals criteria. Since load speed is not a primary factor for ranking, better quality content also plays an important role.

Google uses the following three metrics to measure Core Web Vitals.

 

The metrics LCP, INP, and CLS

Largest Contentful Paint (LCP)

This metric determines the time until the primary content of the website appears for the user in the browser. In the past, Google assessed the content that was visible first. Now, the moment when the primary content becomes visible is used for assessment. The calculation of this time span is done in seconds. Google defines ≤ 2.5 seconds as good. Up to 4 seconds are considered improvable, and more than 4 seconds is labeled as poor by Google.

 

Changes to LCP calculation from Chrome 112

In April 2023, it was announced that the calculation of the Largest Contentful Paint would change with Chrome 112. Images with little content in relation to their size will be ignored in the future. Instead, the LCP will now be calculated more based on text or images with more text. 
This means that very large background images, placeholders, or graphics will be excluded from the calculation. Images with very little content relative to their display size (threshold = 0.05 bits of image data per pixel) will also be ignored. 
Conclusion: This can be especially beneficial for websites with backgrounds without or with little content.

 

First Input Delay (FID)

The FID measures the interaction time between the user and the page. When the content of a website is fully visible, a visitor wants to interact with the page as quickly as possible. How fast this interaction succeeds is determined by the First Input Delay. The FID calculates the time it takes for the browser to respond to a user request. According to Google, a value of less than or equal to (≤) 0.1 seconds is good, up to 0.3 seconds needs improvement, and interaction times over 0.3 seconds are considered 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)

The Interaction to Next Paint measures the responsiveness of a website. If an interaction causes the page or certain functions to malfunction, it results in a poor user experience. 

For example, if an accordion does not expand properly upon a click (interaction) but collapses instead, this will be measured by the INP.

This 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.

More information on the new Interaction to Next Paint (INP) metric.

 

Cumulative Layout Shift (CLS)

This metric focuses on the visual stability of a website. Some complex websites load portions of content asynchronously to ensure shorter load times for the user. However, if these loading processes are not coordinated, the displayed content may jump around as it loads, which can be frustrating for users trying to read the content. Google considers a CLS value of less than or equal to (≤) 0.1 as good, up to 0.25 as needing improvement, and more than 0.25 as poor.

The following illustration shows the Core Web Vitals with an example. The poor URLs, the ones needing improvement, and the good URLs are visible and further detailed.

The following example shows a specifically selected URL, displaying the metrics CLS, FID, and LCP.

However, Google is considering changes regarding the Core Web Vitals and does not want to rely solely on these three metrics for evaluation. Any changes or additions to the metrics will be announced in advance.

 

How are Core Web Vitals measured?

Google uses two approaches to measure the Core Web Vitals: lab data and field data. A combination of both approaches is recommended to achieve the best possible result for measuring the Core Web Vitals.

Lab Data

As the name suggests, these measurements are taken in a controlled lab environment. Lab data is estimated data generated in a simulated environment.
An advantage of lab data is that it consistently produces the same results unless changes are made to the settings or conditions. The quality of this data depends on the established measurement conditions. However, lab data does not reflect actual user behavior, which can be seen as a downside.

Field Data

Field data is collected from real users of the website. This can be done through individual JavaScript integrations or automated measurements. Google itself collects field data for the Core Web Vitals report from the Google Search Console.

 

How to optimize Core Web Vitals?

There is no immediate simple solution to improve the Core Web Vitals (Page Experience Factor) because each website is unique. One must understand their own Core Web Vitals and then individually optimize them to achieve the desired goal. Understanding these Core Web Vitals requires a certain level of expertise, as they can be technically complex.

Google has documented some optimization methods, which you can view here.

 

Start Lighthouse Test via Developer Tools in Chrome

To evaluate LCP and CLS values, a Lighthouse test should first be conducted via the Developer Tools (Right-click + Inspect). After that, a direct analysis can be performed. Important: Both desktop and mobile should be analyzed.

Note: Clicking on "Generate report" will reload the page. This usually takes between 15 and 90 seconds.

 

Check Website Performance

For the precise analysis of individual metrics, we navigate to the "Performance" tab:

Then click on "View Original Trace":

Now we receive the following view:

 

CLS Optimization: Approach 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 issues:

  1. Images load with incorrect size after page load
    Problem: Layout shifts occur because no space was "reserved" for the image.
    Solution: Define correct size and position. If the image is within a container, define that element as well to prevent layout shifts.

     

  2. Child themes overriding parent theme styles
    Problem: Parent theme data is loaded first and then overwritten by child theme data. This custom CSS not only causes layout shifts but also increases load time.
    Solution: Insert Critical CSS in the head section of the page. Ideally, all rules should be defined in the head section to avoid additional CSS loading, enabling them to be present during page rendering.

 

Generally, with CLS, care should be taken not to change components in terms of size. Additionally, sizes of video elements or images are crucial. Also, no content should be automatically inserted at the beginning of the page.

 

LCP Optimization: Approach for a poor LCP value:

For LCP value analysis, we also check HTML elements "Timings" and "Related Load".

Often, the issue is not strictly with HTML elements. Other possible causes could include:

  • The image file size is too large
    Solution: Reduce resolution and improve compression.
  • The font was not implemented correctly
    Solution: Apply CSS property font-display: swap;.
  • General issues with server response times or HTML load times
    Solution: Use caching plugins or similar server-side optimizations.

 

Relevant to LCP are server response times, rendering blocking, resource loading times, and client-side rendering.

 

FID Optimization: Approach for a poor FID value:

For FID value analysis, there is no exact approach as it requires a "real user". However, one can orient themselves on the TBT value (Total Blocking Time). Optimizations to the TBT value generally have a positive effect on the FID value.

This value can also be found in the Developer Tools:

The TBT value indicates how long a page takes to build before a user interacts with it, such as clicking a mouse, scrolling the page, etc. This value consists of FCP (First Contentful Paint) and TTI (Time to Interactive).

The measurement here is 50ms. Any "task" taking longer than 50ms to build contains a Total Blocking Time. For example, if something takes 350ms to load, the blocked time is 300ms. This is perceived by the user as a delay.

Complex JavaScript codes are often responsible for this delay.
The solution here is to reduce all scripts that are not needed for visual layout using the "defer" attribute.

Important aspects for FID include accelerating JavaScript execution, relieving the main thread, and reducing requests and file sizes.

 

Helpful tools for optimizing Core Web Vitals:

 

 

Helpful plugin for WordPress:

https://wordpress.org/plugins/accelerated-mobile-pages/

 

Which CMS achieves the best results?

CMS users often struggle to optimize their site for Core Web Vitals. The performance depends largely on the coding of the webmaster provider. This means that the user can only influence the results of their web vitals to a limited extent.

 

HTTP Archive analyzed the top 5 CMSs:
 

Largest Contentful Paint
When the page and its content become visible

Winner: Drupal | Loser: Wix

Results:

  • Drupal – 47%
  • Joomla – 38%
  • WordPress – 25%
  • Squarespace – 12%
    • Wix – 9%
  • Drupal – 91%
  • Joomla – 88%
  • WordPress – 76%
  • Squarespace – 71%
  • Wix – 46%
  • Drupal – 70%
  • Joomla – 63%
  • WordPress – 59%
  • Squarespace – 57%
  • Wix – 44%
  • Minifizierung von Bildern, HTML und CSS
  • Optimierung und Lazy Loading (Verzögerung) von Bildern
  • Optimierung von Google Fonts
  • …
  • Optimierung von HTML, CSS und JavaScript
  • Komprimierung von Bildern (unterstützt Google Guetzli und WebP)
  • Lazy Loading von Bildern
  • Erweitertes Caching mit PHP Opcache möglich
  • Und vieles mehr…
  • Textkomprimierung
  • Effizientes Caching
  • Optimierung der JavaScript-Ausführung
  • Verschiebung von kritischem JavaScript und ungenutztem CSS
  • Minifizierung von CSS und JavaScript
  • Viele weitere Features
  • Optimierung und Komprimierung von Bildern
  • Lazy loading
  • und vieles mehr
  • PageSpeed Insights (von Google)
  • Pingdom Website Speed Test
  • GTmetrix
  • Theme und Einstellungen überprüfen (z.B. Slider, Kommentarfunktion, etc.)
  • Standard-Loop verwenden:
  • style.css bereinigen (Addon für Firefox: CSS-Usage)
  • style.css optimieren (mit bspw. einem Plugin wie CSS Minify)
  • Inline CSS statt CSS-Datei – vorher prüfen!
  • unnötiges JavaScript entfernen (meist im Head-Bereich)
  • CDN-Dienst nutzen
  • überflüssige Plugins löschen
  • unnötige Links im Head entfernen
  • Kommentare abschalten
  • Thumbnail-Qualität regulieren
  • RSS Feeds abschalten
  • HTML minifizieren
  • HTTP Verbindungen blocken: define('WP_HTTP_BLOCK_EXTERNAL', true);
  • WordPress Heartbeat API deaktivieren
  • Emoji-Support deaktivieren
  • Embeds und Responsive Images deaktivieren (mehr dazu)
  • XML-RPC deaktivieren