Core web vitals are at the center of how Google measures a new ranking signal call page experience. The rationale behind this signal is that all other things being equal, great page experiences should stand out when users are looking for content, simply because users will enjoy them more, will engage with them more, will make the publishers more successful, and everybody will be happier.
The page experience signal is a combination of page-level metrics that include the core web vitals, and also other aspects that are very important.
Mobile-friendly, safe browsing, HTTPS security, lack of intrusive interstitials, and so on. All of these elements are combined and are used as a ranking factor, one of many. But all things equal, the better the page experience is, the greater the chance of ranking higher on Google search results.
If a site meets the Core Web Vitals thresholds, users are 24% less likely to abandon the page before the first content is painted.
— Garima Mimani, Web Ecosystems Consultant at Google.
When we talk about Web Vitals, we refer to three main aspects – a set of user-centric metrics that we can track during the execution of our web pages, tools that allow us to measure and report on the performance of our pages in terms of this web vitals, and incentives so that we have clear and compelling reasons to strive for healthy core web vitals for our site.
I have mentioned Core Web Vitals in my previous article – What you need to know about Google’s Core December update.
Let’s take a brief look at each of them. In terms of metrics, there are many web vitals and many web performance metrics in general. We are interested in a subset of these metrics that are referred to as core web vitals. These are page-level metrics. And ideally, all the pages of our site should do well with respect to them. Each core web vital represents a distinct facet of the performance of our site directly related to the experience of our user.
Specifically, load time, how fast our pages are loading into the devices of our users, interactivity, how long does it take until users can start interacting with the content of our pages, and content stability, how stable or unstable the content of our pages behave when users engage with it.
Now, the core web vitals associated with these facets are the following.
Web Vitals: Largest Contentful Paint
The Largest Contentful Paint, or LCP, measure load time performance. It seeks to quantify the rendering time of the largest component visible within the viewport of the user.
To provide a good experience, LCP should occur within 2.5 seconds from when the page first starts loading. If LCP is between 2.5 and 4 seconds, so things are not terrible, but we need to improve.
And if LCP is larger than 4 seconds, then we know that our users are having a bad time as they try to load our content into their device.
Web Vitals: First Input Delay
First Input Delay, or FID, measures our site’s responsiveness. It quantifies the experience our users get when trying to interact with the components of our pages. To provide a good user experience, pages should have an FID of less than 100 milliseconds.
If the FID is between 100 and 300 milliseconds, then things are not tragic yet, but we need to improve.
If FID is longer than 300 milliseconds, again, we know that our users are having a bad time and frustration when they’re trying to interact with our content.
Web Vitals: Cumulative Layout Shift
Then we have Cumulative Layout Shift, or CLS, which measures visual stability of our content. The way that it is computed is by detecting when a given element that is visible in the viewport changes the position between two rendering frames.
A range is bound between 0 and 1, where 1 means that all of the visible content shifted, and 0 means none of the visible content shifted. The overall CLS score is then computed as a cumulative value of all the happening on page load.
Now, if we want to provide a good user experience, then our base should have a CLS of less than 0.1. If CLS is between 0.1 and 0.25, things are not tragic, but we need to do better. And if CLS is larger than 0.25, then we know that there is a lot of content shifting, our users are probably clicking on places that they do not intend to, and they are super annoyed.
Be sure to read: How to Do an Effective SEO Audit
Best tools to measure Google Core Web Vitals
The next aspect of core web vitals is tools. We know that how our sites perform in terms of core web vitals correlates to the experience that we bring to our users. Therefore, it’s very important that we are able to measure them, reason about them, track them.
Now, that’s why all core web vitals are supported by all the popular Google tools for a developer. This includes PageSpeed Insights, the Chrome UX Report, Google Search Console, Chrome Dev Tools, as well Lighthouse. And there is also a chrome web extension that we can use.
And the final aspect is an incentive. We need a compelling reason for us to strive for our goals of great core web vitals in all our pages. The first and foremost incentive is that we don’t want our users to be sad.
We want to bring to them great experiences. And we know that if we do that, they will reward us with their engagement, with the time, their loyalty to the content that we bring to them.
Another incentive has to do with having a greater chance of our content being easily found when users search for it.
The greater the chance that your pages will be able to take advantage of all the possibilities where page experience plays a role. So this is great.
With core web vitals and page experiences, we know exactly what we want to strive for. We know that if we ensure that our site meets the threshold defined for core web vitals, then we are on the right track to make our users happy, and consequently, to be successful web-content.
Garima Mimani’s Core Web Vitals tips:
- Do not insert content above existing content unless it is in response to user interaction. Provide a smooth and predictable experience to the user.
- Two, if content needs to shift in response to user interaction, do so immediately. Do not wait for the network request to finish.
- For requests that may take more than 500 milliseconds to complete, use placeholders to reserve space as the content loads.
- And, three, for all interactive elements on the page, ensure that if it looks interactive, it actually is interactive.
- If you use server-side rendering consider rendering your pages in a loading or disabled state, and then uploading them to look interactive.