Google expands its core web vitals and page experience update FAQs

Google updated its FAQs around the core web vitals and page experience update. This page is accessible in the Google support forums and was initially posted in December 2020 but was updated today with a lot more details.

What is new. Well, there is a lot new here compared to the original version. You can compare the old to the new by scanning both documents. Malte Ubl, Technically a Software Engineer at Google, said on Twitter “we published an FAQ on Google’s page experience ranking answering questions like: Where does the Core Web Vitals data come from? How is a score calculated for a URL that was recently published & hasn’t yet generated 28 days of data? …and many more.”

Google said “in December last year, we published a set of Core Web Vitals & Page Experience FAQs based on the questions you wanted us to answer. We received a lot of positive feedback, and many wrote to us saying they found the answers helpful. We are back with more answers to the questions we received meanwhile.  We’ve organized the questions in this post into three sections: Metrics & Tooling, Page Experience & Search, and AMP.  We hope you find these useful.”

What stands out. The one big item that stands out to me is the one on how Google will still rank the most relevant content despite how poorly it might do with its core web vitals scores. Google wrote “Our systems will continue to prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content. “

The FAQs: Here is a copy of the FAQs as they are today:

METRICS & TOOLING
Q: Where does the Core Web Vitals data that Search considers come from?A: The data comes from the Chrome User Experience Report, which is based on actual user visits and interactions with web pages. To be clear, the data is not computed based on lab simulations of loading pages or based on the visits of a non-human visitor like Googlebot.
Q: How are scores for individual URLs calculated? In other words, how is it determined if a page passes or fails the web vitals assessment?A: Metrics are calculated at the 75th percentile over a 28 day window. By using 75th percentile, we know that most visits to the site (3 of 4) experienced the target level of performance or better.  If a page hits the recommended targets for all three metrics, it passes the web vitals assessment. More details on the distribution and aggregation is here.
Q: How is a score calculated for a URL that was recently published, and hasn’t yet generated 28 days of data?A: Similar to how Search Console reports page experience data, we can employ techniques like grouping pages that are similar and compute scores based on that aggregation. This is applicable to pages that receive little to no traffic, so small sites without field data don’t need to be worried.
Q: Why am I seeing different metric values in different tools such as Lighthouse and the Chrome User Experience Report?A: Core Web Vitals are based on actual user visits, which will be influenced by users’ environmental conditions and their interactions. Tools like Lighthouse are lab simulations. While Lighthouse can provide a point in time picture of what the metrics may be for some users and what opportunities there are to improve, it may differ from the data collected based on actual users’ visits.
Q: I don’t see the page I’m looking for in the Core Web Vitals report on Search Console. A: For each issue type, Search Console lists a subset of URLs. These URLs are representative of various types of pages your site may have. The purpose of this report is to help users discover problematic page types such that they can be debugged in tools like Page Speed Insights or Lighthouse. We hope that by fixing the patterns of issues exposed through examination of individual URLs, the entire page type would be improved.
Q: Are noindex pages and pages “blocked by robots.txt” included in the CrUX dataset?A: You can access CrUX data in 2 ways: Page-level through PSI and the CrUX API or Origin-level through the Public Big Query Dataset. The former only surfaces information for publicly indexable pages that also meet a traffic threshold, while the latter may include aggregate data from all public and private pages.
Q: A 3rd Party service I utilize (such as client-side A/B Testing, Social Embed, Personalization Engines, Comment Systems etc.) is slowing down my site.  A: Sites may choose to utilize a variety of third-party code and services. Core Web Vitals metrics don’t make a distinction in these choices but only look at the total observed experience of the page as seen by the end user. Like all other features on a page, it may help to regularly assess the impact of third-party components of the experience on the Core Web Vitals. There may be an improved form of integration or configuration that improves the user experience and will be reflected with improved Core Web Vitals metrics. Check out these resources from web.dev on how to optimize third-party JavaScript on your pages. (1, 2, 3, 4)
Q: Why does Google’s guidance use the same thresholds for CWV for all types of pages? For example, a home page for a newspaper is not the same as an article and not the same as a comments page.A: Core Web Vitals are meant to be foundational metrics that apply to all types of pages. To determine the threshold ranges, we analyzed a wide variety of pages and drew upon research that focused on core user experience requirements agnostic of the page type.
PAGE EXPERIENCE & SEARCH
Q: What is the page experience update and how important is it compared to other ranking signals?
A: The page experience update introduces a new signal that our search algorithms will use alongside hundreds of other signals to determine the best content to show in response to a query. Our systems will continue to prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content.
This is similar to changes we’ve had in the past, such as our mobile-friendly update or our speed update. As with those signals, page experience will be more important in “tie-breaker” types of situations. If there are multiple pages of similar quality and content, those with better page experience might perform better than those without.
In short, publishers shouldn’t worry that when we begin using page experience, that they may suffer some immediate significant drop, if they’re still working on making improvements. But publishers should be focused on making those improvements a relative priority over time. This is because as more and more sites continue to improve their page experience, it will be the norm that publishers will want to match.
Q: Are Core Web Vitals a ranking factor when using Google Search on non-Chrome browsers?A: Yes. Page experience ranking signals, based on Core Web Vitals, are applied globally on all browsers on mobile devices.
Q: How does page experience ranking work with respect to the published guidance on what values for Core Web Vitals are considered in the “good” threshold?A: The guidance for LCP, FID, and CLS (the Core Web Vitals) each outline a specific value that constitutes a “good” score. Because closer to zero is better for all of these particular metrics, we can speak in terms of any score between zero and the documented value (inclusively) as being the “good range”.
Google’s page experience ranking assesses each of the Core Web Vitals individually as a signal for ranking. The page experience ranking impact will be the same for all pages that are in the good range for all Core Web Vitals, irrespective of their individual Core Web Vitals scores. For example, a page with an LCP of 1750 ms (better than the “good” LCP guidance) and another one with 2500 ms (at the “good” guidance) would not be distinguished on the basis of the LCP signal. However, hundreds of other signals, including the other Core Web Vitals, could result in differing ranking for the two pages in question. Outside of the good range, differing values of a Core Web Vital metric across two pages could result in differing page experience ranking.
Q: What version of a webpage, if I publish AMP and non-AMP versions, will be linked by Google?A: The AMP version. If both versions of a page are offered, Google will continue to link to the AMP version of the page on mobile, as is the case today.
Please note that for Top Stories carousel, there’s an additional requirement of compliance with Google News content policies.
Q: How does a publisher know if their pages are receiving the benefit of Core Web Vitals in ranking?A: Page experience ranking is concerned with evaluating pages based on user experience as measured by Core Web Vitals, along with other criteria. We recognize that sites may balance user experience goals with other business goals. Pages that receive a score of “good” on Core Web Vitals are achieving an aspirational level of user experience, and might get a boost in the page experience component of ranking, provided other components of the page experience signal (HTTPS, mobile-friendliness, etc) are deemed OK.
If you have pages that aren’t measuring “good” on at least one of the Core Web Vitals metrics or not passing the other page experience criteria, we recommend focusing on improvements in those dimensions over time. While all of the components of page experience are important, we will prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search.
TOP STORIES
Q: Am I eligible for Top Stories carousel if my webpage is not clearing Core Web Vitals?A: Yes. With the upcoming change to Top Stories carousel, all web pages irrespective of their page experience status or Core Web Vitals score are eligible for Top Stories carousel. When the changes go live the compliance with Google News content policies will be the only requirement, and we will use page experience as a ranking signal across all the pages.
AMP
Q: Does this mean AMP will effectively become a ranking signal? A: AMP has never been a ranking signal, and is not becoming one; it is a framework site owners can use to build beautiful and performant web pages, and can take advantage of many built-in features that help improve page experience.
Q: Will my AMP pages always have a good page experience? Do I need to do anything if I’m already on AMP? A:  AMP Project contributors around the world are committed to ensuring site owners are getting a great start toward a performant experience when creating AMP pages. However, like many other frameworks, AMP can’t implement all web development best practices. In this blog post developers can find guidance to ensure that AMP pages served from both the publisher’s site or via an AMP cache are optimized.
Q: If sites no longer want to use AMP, are there options? A: Yes, there are many paths other than AMP to achieving a great page experience. Site owners can use a variety of tools/frameworks of their choosing, and we encourage them to visit Search Console to learn more about how their site measures on the page experience criteria like Core Web Vitals. They can also check out resources at web.dev/vitals.
Publishers looking to turn off AMP pages can follow the guidance laid out here.
Q: How can I tell if my AMP pages have a good page experience?A: The AMP Project released a tool, the AMP Page Experience Guide, to help sites understand how their AMP content measures according to the Core Web Vitals.  It also provides actionable information on how to improve AMP pages. If an AMP page does not pass CWV and there is no actionable feedback available, developers are encouraged to report those issues to the AMP team using the channels in the tool.
Q: Do the page experience ranking signals only look at AMP content loaded from a cache? A: The page experience signals for a page are determined by observing the experience offered given the real traffic pages receive. In the case of AMP, this means that pages could be served from either the publisher’s origin or via an AMP cache, depending on how the user encounters the content.  This is why we encourage developers who use AMP to make sure that pages served from both these sources are optimized. We recommend that developers use AMP Optimizers to bring AMP Cache optimizations to their own site. For added guidance, publishers can use the AMP Page Experience Guide to understand where their AMP pages can be improved.
Q: How is data from the Google AMP Viewer attributed?A: The page experience signals are designed to reflect how users experience the web. Therefore, we include visits attributed to the Google AMP viewer in the data for an AMP URL. In the case of Paired AMP, the canonical non-AMP page is attributed independently.
Q: Is Google continuing to invest in AMP?A: Google Search has focused on ensuring that users have a great page experience when engaging with web content. Page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its pure information value.
The AMP Project will continue to focus on creating strong user experiences, and that includes optimizing along the lines of the page experience signals. Google will continue to invest in AMP, and strongly believes in the AMP Project’s goal to deliver web pages that provide a great user experience. Google Search will continue to direct users to the AMP versions of web pages when available. This enables users to benefit from the speed improvements that come from privacy-preserving prerendering and AMP caches.
Q: What are the considerations for publishers thinking about switching off AMP in order to have a good page experience?A: AMP’s user experience goals and page experience are closely aligned, and hence AMP is a cost-effective and simple solution for publishers looking to make web pages with good page experience with minimal ongoing effort. However, AMP does have some constraints that publishers can encounter – for example, it can be challenging to create complex interactive experiences, and third party services publishers may consider using aren’t always integrated with AMP.
On monetization, AMP balances prioritizing user experience with a publisher’s ability to earn revenue, and publishers can optimize the revenue potential of their AMP pages by following the guidelines here. If publishers do consider moving away from AMP, there is likely to be some investment needed to have a good page experience.  Publishers maintaining non-AMP pages will have no limitations on what kinds of technologies they use to build a page experience, but some elements may need optimization to ensure they allow for a good page experience.
Publishers looking to turn off AMP pages can follow the guidance laid out here.
Q: If publishers decide not to use AMP, how will they know their content is eligible for Top Stories carousel?A: With the upcoming change to Top Stories, any news publisher’s content whether via AMP or another technology is eligible provided it complies with Google News content policies. Whether content shows up in practice will depend on a number of factors that ranking considers, and page experience criteria will be one of them. To be clear, any content irrespective of its page experience metrics is eligible for Top Stories feature on Google Search.
Q: If my AMP pages don’t have a good page experience, are they still eligible for the Top Stories Carousel? A: Yes, any content that meets the Google News content policies is eligible to be displayed in the Top Stories carousel.  Page experience refers to a collection of signals that are all important to deliver a good page experience, and the signals are becoming a factor in ranking, including in the Top Stories Carousel.  This means that page experience factors, in addition to many other factors including the content itself and the match to the query, will determine its placement in the Top Stories carousel. Publishers should be focused on making improvements to page experience a relative priority over time as page experience ranking becomes the norm that users expect and other publishers would want to match.
Q: If I stop doing AMP and use a different approach to publish content, including optimizing page experience on my own, can I expect that Google will rank my content the same as when I did AMP? A: Page experience is intended as a technology agnostic ranking signal. Developers can work with the framework of their choosing. Switching from AMP to using a different approach will not factor into how the non-AMP pages are ranked.
Q: What else do I need to consider if I decide to stop using AMP?  How will it impact the way my content appears in Discover or Google News?A: While the Discover feed shows a lot of AMP content, AMP is not a requirement nor a ranking factor for serving in this space.  Article cards for AMP pages are automatically eligible to use a larger thumbnail image. These larger images have a higher click-through rate than smaller, thumbnail images.  Given this, we recommend that if you decide to go off AMP you make larger images available to Google for your non-AMP content.  You can do so by adding the max-image-preview:[large] robots meta tag setting on each page.
Please see the steps outlined here if you’re considering to stop using AMP. For Google News considerations, please see the next question.
Q: For publications who use AMP, how should they be thinking about how they will appear in the Google News app? A: Today the Google News app displays AMP content when it’s available, but is not restricted to only AMP content. Google News app team is working on further broadening the support for non-AMP web pages, and optimize based on page experience. We will support our publishing partners who are interested in switching from AMP to non-AMP if that is a change they are exploring.

Why we care. With the Google Page Experience Update coming in May, we are all getting ready to ensure our sites fair green with this update. We are not sure how big of a ranking factor this will be, but even if this is a small ranking factor, making these user experience changes to your site can help make for happier users and potentially increase site conversion rates and performance.