Google finally announced, that Core Web Vitals will be the new ranking factor from mid-June 2021, along with other well-known Page Experience metrics.
In the announcement, they also mentioned that they would be running a test that would provide a visual indicator to highlight pages in search results that were more Web Vitals-compliant than others. In early December, we already saw the beginning of the rollout of this test.
If the test is successful, the full launch will take place in May 2021. With that in mind, we’ll take a look at exactly what Core Web Vitals mean specifically for SEO promotion, and the steps you need to take. focus right now.
Table of contents:
- How to evaluate your site’s CWV?
- How to Prepare for CWV?
Core Web Vitals Overview
Page Experience consists of three metrics:
- Largest Contentful Paint (LCP) – a measurement of content loading speed, in particular the time it takes to render the largest element on a page.
- First Input Delay (FID) is a measure of site interactivity – the time elapsed between a user click and the browser’s response to that action.
- Cumulative Layout Shift (CLS) – an indicator of visual stability – the presence of sudden content shifts when the page is loaded.
All of these metrics were previously available through other tools such as PageSpeed Insights and are based on the report Chrome User Experience Report (CrUX), but accessing them directly in GSC opens up a few new possibilities.
Along with these three main metrics, there are other “additional metrics” that are used to help diagnose issues with Core Web Vitals:
- Time To First Byte (TTFB) and First Content Render (FCP) – Diagnosing problems with LCP.
- Total block time (TBT) and time to interaction (TTI) – Diagnosing interactivity issues.
It should also be noted that while all of these metrics are available now, they still have room to grow and evolve as more data becomes available.
In the image below you can see the main indicators of CWV. Each page of the site, depending on the download speed, is ranked in the range “Good”, “Requires improvement” and “Bad”:
At this point, the goal is for at least 75% of your site’s URLs to meet the Web Vitals requirements for each of the core metrics, desktop and mobile.
How to increase website loading speed with Core Web Vitals
- Crawl the site using Screaming Frog with the PageSpeed Insights API enabled.
- Categorize pages by type so that performance can be analyzed at the template level – blog, category, product, supporting content, etc.
- Determine if each page passes the three CWV metrics.
- Analyze your competitors. Use the same processes to determine where you stand in relation to your key competitors.
- Track your progress over time.
These processes will help you evaluate the performance of your website.
Tools you can use to evaluate Page Experience
For any analysis, we strongly recommend using a variety of tools. Having received performance estimates for each of them, and comparing with each other, you will get the result that most accurately reflects the real picture:
- Lighthouse (Chrome Dev Tools)
- Chrome User Experience Reports
- Google Analytics speed test
- Google Search Console
Write down what tools you use so you can easily replicate the analysis when it comes to verifying the implementation. When you’re doing a review, it’s important to use as few extra features as possible. This means clearing cookies, doing incognito checks, disabling any extensions you use to get the most accurate data possible.
How to use the Core Web Vitals ranking factor
With the announcement of the launch of Core Web Vitals in May 2021, there is work to be done to stay ahead of the competition and ensure that you are not only unaffected, but also in the best position to have a visual indicator of test success.
We’ve known for a long time that page load speed plays an important role in ranking algorithms, both on desktop and mobile.
So how do you really get ahead?
- Explore the new Web Vitals reports in GSC
- Identify areas in the report that need improvement, then prioritize based on effort/time spent/result.
- If you see a small impact by changing a couple of things in a lot of URLs, you will see more overall growth than if you put in a lot of effort fixing a few URLs.
- Prioritize, then optimize.
- Cross-reference to “bad” URLs labeled for each metric with other GSC and GA data, for example:
- Mobile Usability
- Impressions (per device)
- Sessions (by device)
- Page engagement metrics (by device)
- Tie the “bad” ones URLs with other tool data, for example:
- Reports on Google Ads (formerly AdWords) landing page usage. The perceptual factor of a landing page is mobile connection speed. If it’s flagged there, it’s probably also flagged in the Web Vitals report.
- PageSpeed Insights – for more metrics
- CrUX – for additional metric data
- You shouldn’t chase tenths of a second of loading by removing all plugins and extensions in a row. Most likely, the speed gain will be almost imperceptible, and significant damage to the site can be caused.
- Test, measure, implement, measure.
- Test on a sample of pages
- Measure the impact on the sample page (speed, impressions, sessions, engagement, conversions, etc.)
- Scale implementation for impacted URLs (more often than not, a template change affects the entire site)
- Measure the site impact of all affected URLs
It may not happen right away, but we all know that development and implementation takes time. The sooner you start looking at the data, potential problems, potential causes, and the time it takes to fix, the sooner you can prioritize the “problem” ones. areas and bring them into good condition before the upcoming implementation. And since we are all marketers and love competition, the sooner your site is ranked by the search engine, the harder it will be for competitors to overtake you.
Core Web Vitals Metrics and Tools
Where does the Core Web Vitals data that the search engine takes into account come from?
Answer: The data is from Chrome User Experience Report, which is based on actual user visits and web page interactions (also known as field data). To be clear, the data is not calculated based on laboratory page loading simulations, or based on visits by a non-human visitor such as a Googlebot.
How are the scores for individual URLs calculated? In other words, how is it determined whether a page passes the Web Vitals score or not?
Answer: Metrics are calculated at the 75th percentile over a 28-day window Using the 75th percentile, we know that the majority of visits to the site (3 out of 4) were at or above the target performance level. If a page meets the recommended targets for all three metrics, it passes the Web Vitals score. More information about distribution and aggregation here.
How is the score calculated for a URL that was recently published but hasn’t received 28 days of data yet?
Answer: Similar to how Search Console reports pageview data, we can use techniques such as grouping similar pages and calculating scores based on that aggregation. This applies to pages that receive almost no traffic, so small sites without field data do not have to worry.
Why do I see different metric values in different tools like Lighthouse and Chrome User Experience Report?
Answer: Core Web Vitals are based on actual user visits, which will be influenced by users’ environmental conditions and interactions. Tools like Lighthouse are lab simulations. Though Lighthouse can provide a temporary picture of how there may be metrics for some users and room for improvement, they may differ from the data collected based on actual user visits.
I don’t see the page I’m looking for in the Core Web Vitals report in Search Console.
Answer: For each type of issue, Search Console lists a subset of URLs. These URLs represent different types of pages on your site. The purpose of this report is to help users discover problematic page types so that they can be debugged using tools such as Page Speed Insights or Lighthouse. We hope that fixing the patterns of issues found when checking individual URLs will improve the whole page type.
Are noindex pages and pages “blocked by robots.txt” included in the CrUX dataset?
Answer: You can access CrUX data in two ways: at the page level via PSI and CrUX API or at the source level via large query public dataset. The former only displays information for publicly indexed pages, which also match the traffic threshold, while the latter may include aggregated data from all public and private pages.
The third party services I use (e.g. client side A/B testing, social media embedding, personalization engines, comment systems, etc.) are slowing down my site.
Why does Google’s guidelines use the same CWV thresholds for all page types? For example, a newspaper homepage is not the same as an article, nor is it the same as a comment page.
Answer: Core Web Vitals are intended to be used as a baseline metric applicable to all page types. In order to determine thresholds, we analyzed a wide range of pages and drew attention to research that focused on the core user experience requirements. experience, regardless of page type.
Page, Experience, and Search
What is page refresh and how important is it compared to other ranking signals?
Answer: Page feature refresh introduces a new signal that our search algorithms will use along with hundreds of other signals to determining the best content to display in response to a request. Our systems will continue to prioritize pages with the best information overall, even if some aspect of the page experience is not up to par. A good page experience does not negate having great and relevant content.
This is similar to the changes we’ve had in the past, such as our mobile update or speed update As with these signals, page experience will be more important in situations where the deciding question.
If there are multiple pages of the same quality and content, those that have a better page experience may perform better than those that don’t.
In short, publishers shouldn’t have to worry that once we start using the features of the page, they might immediately drop significantly if they’re still working on the improvement. But publishers should focus on making those improvements a relative priority over time. This is because as more and more sites continue to improve the quality of their pages, publishers will strive to stay compliant.
Is Core Web Vitals a ranking factor when using Google Search in browsers other than Chrome?
Answer: Yes. Page ranking signals based on Core Web Vitals are applied globally across all browsers on mobile devices.
Is a signed exchange required to refresh the page?
Answer: No, Signed Exchange (SXG) is not a requirement for the benefits of using a page. However, you can consider this technology as one of the options for improving the experience of a page. Sharing your content as a signed sharing can help optimize its delivery to end users and we have seen improvements in LCP performance as a result.
In particular, if the LCP of a page (that is, the LCP value at the 75th percentile of all visits to that page) is already at “good” level, you shouldn’t expect any further ranking boost from using a signed exchange to further optimize your LCP. This is true for other Core Web Vitals metrics as well.
How does page ranking work compared to the published guidance on what Core Web Vitals values are considered “good”? threshold?
Answer: Each manual for LCP, FID, and CLS (Core Web Vitals) specifies a specific value that constitutes a “good” value. score. Because all of these specific metrics are best approximated by zero, we can speak of any score between zero and the documented value (inclusive) as a “good range”.
When ranking pages, Google evaluates each of the major websites individually as a ranking signal. The effect of page ranking will be the same for all pages that are in a good range for all Core Web Vitals, regardless of their individual Core Web scores Vitals. For example, a page with a 1750ms LCP (better than a “good” LCP guide) and another page with 2500ms (with a “good” guide) will not be distinguished based on the LCP signal. However, hundreds of other signals, including other Core Web Vitals, may cause the two pages in question to rank differently. Out of range, different Core Web Vital scores on two pages may cause the page to rank differently.
Which version of the webpage, if I publish the AMP version and the non-AMP version, will Google link to?
Answer: AMP version. If both versions of the page are offered, Google will continue to link to the AMP version of the page on mobile, as they do today.
Please note that the Top Stories carousel has an additional requirement to comply with Google News News content guidelines.
How does a publisher know if their pages are getting the Core Web Vitals ranking advantage?
Answer: Page ranking is about ranking pages based on user experience as measured by Core Web Vitals, along with other criteria We understand that sites can balance between user experience goals and other business goals. Pages rated “good” in Core Web Vitals achieve the desired level of user experience and can get a boost in the page experience component of the ranking, provided that the other components of the page interaction signal (HTTPS, mobile friendliness, etc.) are considered in OK.
If you have pages that are not rated “good” in at least one of the Core Web Vitals metrics or fail to meet other quality criteria, we recommend focusing on improving these metrics over time. While all components of a page’s experience are important, we will prioritize pages with the best information in in general, even if some aspects of the page experience are not up to par. A good page experience does not negate the presence of great and relevant content. However, in cases where there are several pages with similar content, page usability becomes much more important for search visibility.
Am I eligible for the top stories carousel if my web page doesn’t clear Core Web Vitals?
Answer: Yes. With the upcoming change to the Top Stories Carousel, all web pages, regardless of their pageview status or Core Web Vitals score, are eligible for the Top Stories Carousel. When the changes comply compliance The Google News content policy will be the only requirement, and we will use page quality as a ranking signal on all pages.
Does this mean AMP will really become a ranking signal?
Answer: AMP was never and never will be a ranking signal; It is a platform that site owners can use to create beautiful and effective web pages, and can take advantage of many built-in features that help enhance the page experience.
Will my AMP pages always have a good page experience? What if I’m already using AMP?
Answer: AMP contributors around the world are committed to ensuring that site owners get a great start on their road to high performance when building AMP pages. However, like many other frameworks, AMP cannot implement all web best practices. developers. In this blog post, developers can find guidance on optimizing AMP pages served from both the publisher site and the AMP cache.
If sites no longer want to use AMP, are there options?
Answer: Yes, there are many other ways besides AMP to achieve the best page quality. Site owners can use various tools/frameworks of their choice and we encourage them to visit Search Console to learn more about how their site measures page interaction criteria such as Core Web Vitals. They can also test assets at web.dev/vitals .
How do I know if my AMP pages are good?
Answer: The AMP Project has released a tool AMP Page Experience Guide to help sites understand how their AMP content is measured according to Core Web Vitals. It also provides useful information on how to improve AMP pages. ;If an AMP page fails CWV and no feedback is available, developers are encouraged to report these issues to the AMP team using the channels in the tool.
Do page rank signals only look at cached AMP content?
Answer: Page experience signals for a page are determined by observing the experience offered against the actual traffic the pages receive. In the case of AMP, this means that pages can be served either from a publisher source or through the AMP cache, whichever how the user encounters the content. This is why we recommend that developers using AMP ensure that pages served from both of these sources are optimized. We recommend that developers use AMP optimizers to optimize the AMP cache on their For more guidance, publishers can use The AMP Page Guide to understand where they can improve their AMP pages.
How is data from Google AMP Viewer attributed?
Answer: Page interaction signals are intended to reflect how users experience the web. Therefore, we include visits attributed to the Google AMP viewer in the data for the AMP URL. In the case of paired AMP, the canonical page without AMP is assigned independently.
Is Google still investing in AMP?
Answer: Google Search is focused on making web content user-friendly. Page experience is a set of signals that measure how users perceive the experience of interacting with a webpage, beyond purely informational value.
The AMP Project will continue to focus on building strong user experiences, including optimization based on page interaction signals. Google will continue to invest in AMP and strongly believes in the AMP Project’s goal of providing web pages that provide a great user experience. Google Search will continue to direct users to AMP versions of web pages when they become available. This allows users to benefit from the speed improvements that come from privacy-preserving pre-rendering and AMP caching.
What should publishers consider when considering disabling AMP in order for the page to be usable?
Answer: The goals of AMP for user experience and page experience are closely related, and therefore AMP is a cost-effective and easy solution for publishers who want to create web pages with a good page experience with minimal ongoing effort. However, AMP has some limitations that publishers may encounter – for example, it may be difficult to create complex interactive experiences, and third-party publishers may consider using services that are not always integrated with AMP.
When it comes to monetization, AMP balances the prioritization of the user experience with the publisher’s ability to generate revenue, and publishers can optimize the revenue potential of their AMP pages by following the recommendations here If publishers are considering moving away from AMP, it’s likely some investment will be required to make the page usable. Publishers supporting non-AMP pages will have no restrictions on what kinds of technologies they use to create the page experience, but some elements may need to be optimized to provide usability page.
If publishers choose not to use AMP, how do they know if their content is eligible for the top stories carousel?
Answer: With the upcoming Top Stories change, any news publisher’s content, whether through AMP or other technology, will be allowed as long as it complies with Google News Content Content Policy. Whether the content is actually displayed will depend on a number of factors that are taken into account when ranking, and page acceptance criteria will be one of them. To be clear, any content, regardless of its page acceptance rates, is eligible for the Top Stories feature in Google search.
If my AMP pages are poorly received, can they still be featured in the Top Stories Carousel?
Answer: Yes, any content that complies with the Google News content policy may be featured in the top carousel. Page experience refers to a set of cues that are important for a good page experience, and those signals become a ranking factor, including in the top stories carousel. This means that perceptual factors for a page, in addition to many other factors, including the content itself and query relevance, will determine its placement in the top stories carousel. Publishers should focus on making page experience improvements a relative priority over time as page ranking becomes the norm that users expect and other publishers would like to match.
If I stop using AMP and use a different approach to publishing content, including optimizing the page myself, can I expect Google to rank my content the same way it did when I used AMP?
Answer: Perception of a page is intended to be a technology-agnostic ranking signal. Developers can work with the structure of their choice. Switching from AMP to a different approach will not affect the ranking of non-AMP pages.
What else do I need to consider if I decide to stop using AMP? How will this affect how my content appears in Discover or Google News?
Answer: While the Discover channel features a lot of AMP content, AMP is neither a requirement nor a ranking factor to serve in this space. Article cards for AMP pages can automatically use a larger thumbnail image. These larger images have higher click-through rate than small thumbnail images. With this in mind, we recommend that if you choose to opt out of AMP, you provide Google with larger images for your non-AMP content. You can do so by by adding the max-image-preview: [large] robots meta tag parameter on each page.
If you’re thinking of opting out of AMP, read the steps here To learn about Google News, see the next question.
How should posts using AMP be treated about how they will appear in the Google News app?
Answer: Today, the Google News app displays AMP content when available, but is not limited to AMP content. The Google News app team is working to further expand support for non-AMP web pages and optimize for page usability. We will support our publisher partners who are interested in moving from AMP to non-AMP if they are looking into the change.
When will Core Web Vitals become part of the algorithm?
In mid-June 2021, along with other page interaction signals such as safe browsing, HTTPS, mobile optimization, and no intrusive interstitials.
What is Core Web Vitals?
A series of new measurements that Google will use to determine how a page is perceived. There are currently three metrics: Content Render Rate (LCP), First Input Latency (FID), and Content Shift on Load (CLS).
How are they measured?
Google ranks a web page as Poor, Needs Improvement, or Good. Each metric has its own threshold, but to qualify for the “Good” category, your web page must be in the green zone of each metric for desktop and mobile.
Will Core Web Vitals be a ranking factor?
Yes, Core Web Vitals will be part of the overall search algorithm from May 2021 along with other Page Experience signals already included.
How do I check the Page Experience of a page?
You can check your scores for individual pages in the Google Search Console, just like with other performance tests. Google Search Console also has a tab dedicated to Core Web Vitals where you can see your overall scores and any performance issues.
For a faster check, you can use the PageSpeed Insights tool.
Can I check my pages in bulk?
Yes, but you’ll need a few APIs to do so. The PageSpeed Insights API and the Chrome UX Reporting API retrieve lab and performance data, and include Core Web Vitals metrics, so if you’re comfortable using the API, mass measurement should be a breeze.
Can I measure the performance of Core Web Vital over time?
Yes. Google Search Console will let you track how performance changes for each metric, just like for all other analytics. Using the APIs, you can also set up custom dashboards to track changes over time and update as they are implemented.