/webmasters/community?hl=en
This content is likely not relevant anymore. Try searching or browse recent questions.
Core Web Vitals & Page Experience FAQs (Updated: March 2021) 0 Recommended Answers 0 Replies 273 Upvotes
1 Recommended Answer
$0 Recommended Answers
1 Relevant Answer
$0 Relevant Answers
Hello everyone,

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.

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 (also known as field data). 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.
Details
Relevant Answer Relevant Answers (0)
No replies yet.
This question is locked and replying has been disabled.
Discard post? You will lose what you have written so far.
Write a reply
10 characters required
Failed to attach file, click here to try again.
Discard post?
You will lose what you have written so far.
Personal information found

We found the following personal information in your message:

This information will be visible to anyone who visits or subscribes to notifications for this post. Are you sure you want to continue?

A problem occurred. Please try again.
Create Reply
Edit Reply
Delete post?
This will remove the reply from the Answers section.
Notifications are off
Your notifications are currently off and you won't receive subscription updates. To turn them on, go to Notifications preferences on your Profile page.
Report abuse
Google takes abuse of its services very seriously. We're committed to dealing with such abuse according to the laws in your country of residence. When you submit a report, we'll investigate it and take the appropriate action. We'll get back to you only if we require additional details or have more information to share.

Go to the Legal Help page to request content changes for legal reasons.

Reported post for abuse
Unable to send report.
Report post
What type of post are you reporting?
Google takes abuse of its services very seriously. We're committed to dealing with such abuse according to the laws in your country of residence. When you submit a report, we'll investigate it and take the appropriate action. We'll get back to you only if we require additional details or have more information to share.

Go to the Legal Help page to request content changes for legal reasons.

Reported post for abuse
Unable to send report.
This reply is no longer available.
/webmasters/threads
//accounts.google.com/ServiceLogin
You'll receive email notifications for new posts at
Unable to delete question.
Unable to update vote.
Unable to update subscription.
You have been unsubscribed
Deleted
Unable to delete reply.
Removed from Answers
Marked as Recommended Answer
Removed recommendation
Undo
Unable to update reply.
Unable to update vote.
Thank you. Your response was recorded.
Unable to undo vote.
Thank you. This reply will now display in the answers section.
Link copied
Locked
Unlocked
Unable to lock
Unable to unlock
Pinned
Unpinned
Unable to pin
Unable to unpin
Marked
Unmarked
Unable to mark
Reported as off topic
/webmasters/profile/0