Core Web Vitals -A Comprehensive Guide to Help You Understand

Core Web Vitals -A Comprehensive Guide to Help You Understand

Wanting to improve your user’s webpage experience? You’ve come to the right place. 

The introduction of Core Web Vitals in 2020 meant that web developers and website owners had something more than Search Engine Optimisation, mobile-friendliness, and suitably secure websites to aspire towards: they were provided with measurable values for user browsing experience. With minimum quality requirements needed for a site to score high on Google’s ranking scale – it’s essential that websites get “up to scratch” so that they can benefit from continued organic leads through the world’s biggest search engine. 

Google introduced Core Web Vitals as “a set of real-world, user-centred metrics that quantify key aspects of the user experience. They measure dimensions of web usability such as load time, interactivity, and the stability of content as it loads.”

Essentially, the Vitals are broken down into three key metrics:

  1. “Largest Contentful Paint” (A measure that states main page content should load in less than 2.5 seconds)
  2. “First Input Delay” (A measure that states webpages should become interactive in less than 100ms)
  3. “Cumulative Layout Shift” (Content should move unexpectedly by a score of less than 0.1 as you navigate around the site).

As business owners become more self-aware of the necessity of high Google ranking, web developers have to step up to the plate and understand the very fundamentals of scoring highly using Core Web Vitals. Whilst this change isn’t going to impact every website (such as those that already provide high-quality page experiences) – it will change how websites are created in the future. Google will determine if your page is loading fast enough and if it’s not: you could face a penalty in ranking. 

To avoid costly mistakes, we’ve put together our bank of Frequently Asked Questions to create a comprehensive help guide that details a range of general queries, from metrics & tooling to search features and AMP –  all with the goal of helping you on your way to success.

Part 1: Understanding Core Web Vital Metrics 


Definition: Core Web Vitals are a set of specific factors that Google considers important in a webpage’s overall user experience. Core Web Vitals are made up of three specific page speed and user interaction measurements: largest contentful paint, first input delay, and cumulative layout shift.

Q: What are the metrics? Why are they relevant to users?

A: User-centric metrics are a critical tool in understanding, measuring and improving the user experience of your website. Largest Contentful Paint measures how quickly users see content. First Input Delay measures how responsive a site is to user input like tapping a button or entering data in a form. Cumulative Layout Shift measures how often elements of the page move around while the user is trying to read or interact with it.

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. 

Q: Do Core Web Vitals impact ranking? 

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. You can read more about this in our Search Central blog post.

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.

Q: How do I improve my LCP/CLS/FID score?

A: You can find recommendations on how to improve your Core Web Vitals metrics on web.dev/fast/.  Improving metrics for your site will require web development knowledge. If you are a non-technical user, we have some suggestions in our Search Console Help Center, but you should consider contacting a professional.

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 (they are not considered in the design of CWV metrics.)

Part 2: Understanding Desktop and Mobile Rankings

More than 50% of all online traffic is currently sourced from mobile phones, and user experience and smooth loading is an essential part of every customer purchasing decision. Google has always had a strong focus on improving page experience for all users, and Core Web Vitals is their solution for happier internet browsers.

Q: Is there a difference between desktop and mobile ranking? 

A: At this time, using page experience as a signal for ranking will apply only to mobile Search.

Q: Why are there differences in scores between mobile and desktop?

A: At this time, using page experience as a signal for ranking will apply only to mobile Search. However, if you’re measuring Core Web Vitals using your RUM tool of choice, you may find that scores differ between Mobile Web and Desktop Web. While the technology used to create the site may be similar, real users of the two versions will have different constraints such as device, viewport size, network connectivity and more. 

Q: How do Core Web Vitals account for sites whose user base may be using older devices or using slower networks?

A: Core Web Vitals is meant to measure the quality of a user’s experience on a website. The user population of each site differs and some sites — not limited to any particular region — may have significant populations of users that may be using older devices, using slower networks, and so on. In such cases sites should adapt the content to ensure that such users are still receiving a great user experience and, ideally, still meet the recommended Core Web Vitals thresholds. 

Q: My website is mobile-friendly, but my Core Web Vitals score is low on mobile. How is that possible?

A: The Page Experience signal measures aspects of how users perceive the experience of interacting with a web page. Core Web Vitals is one aspect of this along with Mobile-friendliness. These are not meant to be overlapping but additive in order to provide a holistic picture of page experience.

Q: Can a site meet the recommended thresholds if it is a Single Page Application? 

A: Core Web Vitals measure the end-user experience of a particular web page and don’t take into account the technologies and architectures involved in delivering that experience. Layout shifts, input delays, and contentful paints are as relevant to a Single Page Application as they are to other architectures. Different architectures may result in different friction points to address and meet the thresholds. No matter what architecture you pick, what matters is the observed user experience.

Part 3: Understanding how Accelerated Mobile Pages and Progressive Web Apps interact with Core Web Vitals

Optimizing Core Web Vitals is key to pushing your Accelerated Mobile Page’s reach to a new, wider audience on Google. Addressing and improving server response times, reducing oversized images and finding the source of slow-loading will massively improve your ranking. 

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 that can result in pages not meeting the thresholds, such as slow server response times and un-optimized images. Learn more here.

Q: Can a site meet the recommended thresholds without using AMP?

A: Yes. You can take a look at the guidance offered on web.dev/vitals to see how you can optimize your performance against Core Web Vitals. The advantage of using AMP is that you get these web development best practices baked into the framework without added effort on your part.

Q: If my site is a Progressive Web App, does it meet the recommended thresholds?

A: Not necessarily since it would still depend on how the Progressive Web App is implemented and how real users are experiencing the page. Core Web Vitals are complementary to shipping a good PWA; it’s important that every site, whether a PWA or not, focuses on loading experience, interactivity, and layout stability. We recommend that all PWAs follow Core Web Vitals guidelines.

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

Part 4: Understanding the Search Console


The Google Search Console is a free service that helps you monitor, maintain and troubleshoot your site’s presence in Google Search results. It can help monitor and in some cases resolve server errors, site load issues, and security issues such as hacking or malware. 

Q: What information does Search Console provide about Core Web Vitals? What do these errors mean?

A: Search Console has released the Core Web Vitals Report, powered by Chrome UX Report data, to help site owners identify potential user experience problems. The intent is to ensure that the Core Web Vitals Report is consistent with and provides site owners visibility into the state of each of the Core Web Vitals on their site. You can find more information on what different errors mean and how to address them in the Help Center.

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.

Depending on how you’re evaluating “Fast”, remember that Core Web Vitals is looking at more than speed. For instance, Cumulative Layout Shift describes users annoyances like content moving around. Additionally, you may also use synthetic-based testing tools that try to emulate a user, but that representation may differ from your real users.

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

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. You can use both reports to improve the experience for your users, but the information each report provides is different.

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.  

Part 5: Understanding Metrics & Tooling

There are hundreds of tools out there that help track metrics and web results. Google Analytics has “become the standard for businesses of all shapes and sizes”. Alongside Core Web Vitals comes another issue: how does a website owner or developer measure them?

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: Are no index 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.

Part 6: Understanding Page Experience & Search Algorithms 

In particular, if a page’s LCP (meaning, the value of LCP at the 75th percentile of all visits to that page) is already at the “good” level, you should not expect to see a further ranking benefit from using Signed Exchange to further optimize the LCP. This holds true for other Core Web Vitals metrics as well.

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?

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. 

If a page loading time ranges from 1s to 5s, the probability of a bounce (or lost user) increases to 90%. Credibility falls the longer a customer has to wait for a site to load, with wait times making them feel uncomfortable shopping on or even using a certain site. High-quality page experience is becoming essential for website owners, and that’s why Core Web Vitals were introduced – to push website owners into taking progressive action to improve experiences.

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: Is Signed Exchange required for the page experience update?

A: No, Signed Exchange (SXG) isn’t a requirement for page experience benefits. However, you can consider the technology as one of the options for improving your page experience. Making your content available as Signed Exchange can help optimize its delivery to end users, and we’ve observed improvement to LCP metrics due to this. 

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.

Part 7: Understanding Top Stories


Every business dreams about scoring the top spot on Google. If you’ve been struggling to understand Core Web Vitals, don’t worry – Top Stories carousels are still available to you.

Q: Am I eligible for Top Stories carousel if my webpage is not clearing Core Web Vitals?

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.

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.

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.

Still have questions?

Although Core Web Vitals might seem a little intimidating, the likelihood is this: if you already have a great user experience on your website, you have nothing to worry about.

Metrics will only be affecting mobile rankings for the foreseeable future so there’s plenty of time to experiment, adjust and play around with your website score. As one of our last FAQs covered, “all web pages, irrespective of their page experience status, are eligible for Top Stories carousel.” That means, if you are providing new and interesting content through blogs and articles on your website – you can still hit that top spot on Google. 

Remember, whilst page experience has certainly been added to the list of priorities in building a website, search algorithms look at a variety of multiple factors such as “keywords, relevance and usability of pages, the expertise of sources and your location and settings” – meaning you can still score highly without ticking every box.

If you want direct help or advice with Core Web Vitals (or have a question that we’ve not covered), you can fill in our contact form here or email [email protected]