Core Web Vitals are the speed metrics that are part of Google’s Page Experience signals used to measure user experience. The statistics measure the visual load with the greatest content paint (LCP), visual stability with cumulative layout shift (CLS) and interactivity with first input delay (FID
Page experience and the included Core Web Vital statistics will be officially used for page rankings in May 2021.
Source: Google
The easiest way to see the statistics for your site is with the Core Web Vitals report in Google Search ConsoleThe report makes it easy to see if your pages are categorized as ‘bad URLs’, ‘URLs in need of improvement’ or ‘good URLs’.
The report provides more detailed information about the specific issues and a list of affected pages.
Fact 1: The statistics are split between desktop and mobile, but only mobile signals are used for page rankings. Google will switch to 100% mobile-first indexing in March, so it makes sense to use the mobile speed signals as the indexed pages will also be based on the mobile versions.
Fact 2: The data comes from the Chrome User Experience Report (CrUX), which records details of logged-in Chrome users. The metrics are rated at the 75th percentile of users, so if 70% of your users are in the ‘good’ category and 5% in the ‘need improvement’ category, your page will still be rated as ‘needs improvement’.
Fact 3: The stats are graded for every page, but if there isn’t enough data, John Mueller states that signals from sections of a site or the overall site can be used.
Fact # 4: With the addition of these new stats, AMP will be removed from the Top Stories on Mobile feature as a requirement. Since new stories don’t really contain data on the speed stats, it’s likely that the stats from a larger category of pages or even the entire domain will be used for this.
Fact 5: Single page applications do not measure some of the statistics, FID and LCP, via page transitions. We’ll talk about what those are in a moment.
Fact 6: The statistics can change over time, and the thresholds can change just as much. Google has already changed the metrics used for measuring speed in their tools over the years, as well as their thresholds for what is considered fast or not. It is very likely that this will all change again in the future. We even did some work last year to improve the previous stats, but we need to do some more work to improve the new stats.
To raise expectations, remember that there are over 200 ranking factors. I wouldn’t expect much improvement from improving Core Web Vitals. It’s not known how much they’ll affect rankings, but it’s probably not a strong signal, especially given that many of the page experience components have already been used by Google to determine rankings.
Let’s take a closer look at each of the web’s core vitals.
These are the three current components of Core Web Vitals:
- Largest content paint (LCP
- Cumulative Layout Offset (CLS
- First entry delay (FID
Largest content paint (LCP) – loading
LCP is the largest visible element loaded in the viewport.
Source: web.dev/vitals
The biggest element is usually a featured image or perhaps the
How to see LCP
In PageSpeed Insights, the LCP element is specified in the Diagnostics section. For the tested page it is LCP is our featured image on the blog post.
Follow these steps in Chrome DevTools:
- Performance> check ‘Screenshots’
- Click on ‘Start profiling and reload page’
- LCP is on the timing chart
- Click on the node; this is the element for that LCP
Optimize LCP
With our LCP element on this and many other pages that are the featured image, we can probably improve this by preloading this image or possibly inserting the entire image to create the image along with the HTML code. Basically we want to load this image faster than we currently do.
Resources
Cumulative Layout Offset (CLS) – visual stability
CLS measures how elements move or how stable the page layout is. It takes into account the size of the content and the distance it moves. A major problem with the metric is that it continues to measure even after the page is first loaded. Google is receiving feedback on this particular metric, so we’ll likely see some changes to it in the future.
Source: web.dev/vitals
It can be annoying when you try to click on something on a page that scrolls and click on something you didn’t intend to. It happens to me all the time. I click on one thing and suddenly I click on an ad and not even on the same website. It’s frustrating as a user.
Common causes of CLS include:
- Images without dimensions
- Ads, embeds, and iframes without dimensions
- Inject content with JavaScript
- Allow fonts or styles in loading
How to see CLS
In PageSpeed Insights, under Diagnostics, you will find a list of the elements that shift.
Using WebPageTestIn the filmstrip view, use the following options:
- Highlight layout shifts
- Thumbnail Size: Huge
- Thumbnail Interval: 0.1 sec
Note how our fonts are reformatted between 5.1s – 5.2s, shifting the layout as our custom font is applied.
You may want to try it Layout shift GIF Generator
Smashing Magazine also had an interesting technique they shared, where they outlined everything with a 3px solid red line and a video of the page loading to identify where the layout shifts are happening.
Optimize CLS
What we want to do for our test page is preload our custom font, drop the custom font completely (questionable), or use a default font for the first page load time and only load our font when the next page loads. These have tradeoffs in branding, style, consistency, etc., and we’ll have to decide the best path to move on.
Resources
First entry delay (FID) – interactivity
FID is the time from when a user interacts with your page until the page is able to respond. You can also think of it as responsiveness. This does not include scrolling or zooming.
Example interactions:
- clicking on a link or button
- enter text in an empty field
- by selecting a drop-down menu
- by clicking a check box.
It can be frustrating to click on something and nothing happens on the page.
Source: web.dev/vitals
Not all users will interact with a page, so they may not have FID value. This is also why lab testing tools don’t have the value because they don’t interact with the page. Use total lockout time (TBT) instead.
Cause of FID
JavaScript competes for the main thread. There is only one main thread and JavaScript competes to perform tasks on it.
Source: https://web.dev/long-tasks-devtools
While a job is running, a page cannot respond to user input. This is the delay that is being felt. The longer the task, the longer the delay the user will experience. The pauses between tasks are the options the page has to switch to the user input task and respond to what they wanted to do.
Optimize FID
I don’t see any concerns for our site before FID, but generally you want to split up long tasks and defer any JavaScript that isn’t needed until later.
Resources
The difference between lab and field data is that field data looks at real users, network conditions, devices, caching, etc. And lab data is consistently tested against the same conditions in the hope that the test results are repeatable.
Field data
Lab data
I find the report in GSC because you can see the data of many pages at once, but the data is a bit delayed and on a 28-day moving average, so changes may take time to show in the report. In Chrome 88, Google Add Core Web Vitals directly in DevTools
You can also use the score weights for Lighthouse at any time and view the historical changes.
Final thoughts
You want to improve Core Web Vitals so that your users have a better experience. It remains to be seen what impact they will have SEO, but as I mentioned in my page speed article, they should help you capture more data in your analytics that “feels” like an increase.
Collaborate with your developers; they are the experts here. Page speed can be extremely complex. If you’re alone, you may have to rely on a plugin or service to handle it the same way WP Rocket or NitroPack.
