Google FAQ Provides Core Web Vitals Insights

Google published an FAQ that provides insights into how Core Web Vitals (CWV) works, what it doesn’t measure and the value for ranking purposes.

CWV Intended to Encourage a  Healthy Web Experience

Goal for Core Web Vitals is to have a shared metric for all sites in order to improve user experience across the web.

Q: Is Google recommending that all my pages hit these thresholds? What’s the benefit?

A: We recommend that websites use these three thresholds as a guidepost for optimal user experience across all pages.

Core Web Vitals thresholds are assessed at the per-page level, and you might find that some pages are above and others below these thresholds.

The immediate benefit will be a better experience for users that visit your site, but in the long-term we believe that working towards a shared set of user experience metrics and thresholds across all websites, will be critical in order to sustain a healthy web ecosystem.”

AMP is a Fairly Reliable Way to Score Well

AMP is an acronym for Accelerated Mobile Pages. It’s an HTML framework for delivering to mobile devices web pages that are slimmed down, load fast and are attractive.

AMP was originally developed by Google but is open source. AMP can accommodate ecommerce sites as well as informational sites. There are for examples, apps for the Shopify ecommerce platform as well as plugins for WordPress sites that make it easy to add AMP functionality to a website.

Google will show preference to a website’s AMP version for the purposes of calculating Core Web Vitals score. So if a site is having a difficult time optimizing for core web vitals, using AMP is a fast and easy way to gain a high Core Web Vitals score.

Nevertheless, Google warned that there are factors like a slow server or un-optimized images that can still negatively impact the core web vitals score.

“Q: If I built AMP pages, do they meet the recommended thresholds?

A: There is a high likelihood that AMP pages will meet the thresholds. AMP is about delivering high quality, user-first experiences; its initial design goals are closely aligned with what Core Web Vitals measure today.

This means that sites built using AMP likely can easily meet Web Vitals thresholds.

Furthermore, AMP’s evergreen release enables site owners to get these performance improvements without having to change their codebase or invest in additional resources.

It is important to note that there are things outside of AMP’s control which can result in pages not meeting the thresholds, such as slow server response times and un-optimized images.”

First Input Delay Does Not Consider Scrolling or Bounce/Abandon

First Input Delay (FID) is a metric that measures the time it takes from when a site visitor interacts with a site to when the browser responds to that interaction.

Once a site appears to be downloaded and interactive elements appear to be ready to be interacted with, a user should ideally be able to start clicking around without delay.

A bounce is when a visitor visits a site but then soon after abandons the page, presumably returning back to the search page.

The question is about bounced sessions but the answer incorporates scrolling as well.

Google answers that bounce and abandonment are not a part of the FID metric, presumably because there was no interaction.

“Q: Can sessions that don’t report FID be considered “bounced” sessions?
A: No, FID excludes scrolls, and there are legitimate sessions with no non-scroll input.

Bounce Rate and Abandonment Rate may be defined as part of your analytics suite of choice and are not considered in the design of CWV metric”

Core Web Vitals Impacts Ranking

This section reiterates and confirms that Core Web Vitals will become a ranking signal in 2021.

“Starting May 2021, Core Web vitals will be included in page experience signals together with existing search signals including mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines.”

Importance of Core Web Vitals Ranking Signal For Ranking

Ranking signals are said to have different weights. That’s a reflection that some ranking signals have more importance than other ranking signals.

So when it’s said that a ranking signal is weighted more than another ranking signal, that means that it’s more important.

This is an interesting section of the FAQ because it deals with how much weight the Core Web Vitals ranking signal has compared to other ranking signals.

Google appears to say that the Core Web Vitals ranking signal is weaker than other ranking signals that are directly related to satisfying a user query.

So it’s almost like there is a hierarchy of signals, with intent related signals given more importance than user experience signals.

Here’s how Google explains it:

“Q: How does Google determine which pages are affected by the assessment of Page Experience and usage as a ranking signal?
A: Page experience is just one of many signals that are used to rank pages. Keep in mind that intent of the search query is still a very strong signal, so a page with a subpar page experience may still rank highly if it has great, relevant content.

Q: What can site owners expect to happen to their traffic if they don’t hit Core Web Vitals performance metrics?
A: It’s difficult to make any kind of general prediction. We may have more to share in the future when we formally announce the changes are coming into effect. Keep in mind that the content itself and its match to the kind of information a user is seeking remains a very strong signal as well.”

Field Data in Search Console Core Web Vitals Reporting

This next section explains possible discrepancies between what a publisher experiences in terms of download speed and what users on different devices and Internet connections might experience.

That’s why Google Search Console may report that a site scores low on Core Web Vitals despite the site being perceived as fast by the publisher.

More importantly, the Core Web Vitals metric is concerned with more than just speed.

Furthermore, the Search Console report is based on real-world data whereas Lighthouse data is based on simulated users on simulated devices and simulated internet connections.

Real-world data is called Filed Data while the testing based on simulations is called Lab Data.

“Q: My page is fast. Why do I see warnings on the Search Console Core Web Vitals report?
A: Different devices, network connections, geography and other factors may contribute to how a page loads and is experienced by a particular user. While some users, in certain conditions, can observe a good experience, this may not be indicative of other user’s experience.

Core Web Vitals look at the full body of user visits and its thresholds are assessed at the 75th percentile across the body of users. The SC CWV report helps report on this data.

…remember that Core Web Vitals is looking at more than speed. For instance, Cumulative Layout Shift describes users annoyances like content moving around…

Q: When I look at Lighthouse, I see no errors. Why do I see errors on the Search Console report?

A: The Search Console Core Web Vitals report shows how your pages are performing based on real world usage data from the CrUX report (sometimes called “field data”). Lighthouse, on the other hand, shows data based on what is called “lab data”. Lab data is useful for debugging performance issues while developing a website, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. “

Google published a Frequently Asked Questions section about Core Web Vitals that answers many questions. While the above questions were the ones I thought were particularly interesting, do take a moment to review the rest of the FAQ as there is much more information there.”

Citation:

Core Web Vitals & Page Experience FAQs