Page experience and the included Core Web Vital metrics will officially be used for ranking pages in June 2021.
The easiest way to see the metrics for your site is with the Core Web Vitals report in Google Search Console. With the report, you can easily see if your pages are categorized as “poor URLs,” “URLs need improvement,” or “good URLs.”
Inside the report, you can find more detailed information on the particular issues and a list of affected pages.
Fact 1: The metrics are split between desktop and mobile, but only mobile signals will be used for ranking pages. Google is switching to 100% mobile-first indexing in March, so it makes sense to use the mobile speed signals since 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 data from opted-in Chrome users. The metrics will be assessed at the 75th percentile of users, so if 70% of your users are in the “good” category and 5% are in the “need improvement” category, then your page is still judged as “need improvement.”
Fact 3: The metrics will be assessed for each page, but if there isn’t enough data, John Mueller states that signals from sections of a site or the overall site may be used.
Fact 4: With the addition of these new metrics, AMP is being removed as a requirement from the Top Stories feature on mobile. Since new stories won’t actually have data on the speed metrics, it’s likely that the metrics from a larger category of pages or even the entire domain may be used for this.
Fact 5: Single Page Applications don’t measure a couple of the metrics, FID and LCP, through page transitions. We’ll talk about what those are in a minute.
Fact 6: The metrics may change over time, and the thresholds might as well. 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’s entirely likely this will all change again in the future. In fact, we did some work on improving the previous metrics last year, but we need to do some work again to improve the new metrics.
Just to set expectations, remember that there are over 200 ranking factors. I wouldn’t expect much improvement from improving Core Web Vitals. It’s unknown how much they will impact rankings but it’s not likely to be a strong signal, especially considering many of the page experience components were already used by Google to determine rankings.
Let’s look at each of the core web vitals in more detail.
Here are the three current components of Core Web Vitals:
Largest Contentful Paint (LCP) — loading
LCP is the single largest visible element loaded in the viewport.
The largest element is usually going to be a featured image or maybe the <h1> tag but could be any of these:
- <img> element
- <image> element inside an <svg> element
- The image inside a <video> element
- Background image loaded with the url() function
- Blocks of text
<svg> and <video> may be added in the future.
How to see LCP
In PageSpeed Insights, the LCP element will be specified in the Diagnostics section. For the tested page, the LCP is our featured image on the blog post.
In Chrome DevTools, follow these steps:
- Performance > check “Screenshots”
- Click ‘Start profiling and reload page’
- LCP is on the timing graph
- Click the node; this is the element for LCP
With our LCP element on this and many other pages being the featured image, we can likely make this better by preloading this image or possibly inlining the whole image to make the image downloaded along with the HTML code. Basically, we want to load this image faster than we currently do.
- Optimize Largest Contentful Paint — web.dev
- Investigating Largest Contentful Paint — Paul Irish (video)
- How to Improve Page Speed from Start to Finish — Ahrefs
Cumulative Layout Shift (CLS) — visual stability
CLS measures how elements move around or how stable the page layout is. It takes into account the size of the content and the distance it moves. One major issue with the metric is that it continues to measure even after the initial page load. Google is taking feedback on this particular metric, so we’ll likely see some changes to it in the future.
It can be annoying if you try to click something on a page that shifts and you end up clicking on something you didn’t intend to. It happens to me all the time. I click on one thing, and suddenly, I’m clicking 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
- Applying fonts or styles late in the load
How to see CLS
In PageSpeed Insights, under Diagnostics, you will find a list of the elements that are shifting.
Using WebPageTest. In Filmstrip View, use the following options:
- Highlight Layout Shifts
- Thumbnail Size: Huge
- Thumbnail Interval: 0.1 sec
Notice how our font re-styles between 5.1s‑5.2s, shifting the layout as our custom font is applied.
You may want to try Layout Shift GIF Generator.
Smashing Magazine also had an interesting technique they shared where they outlined everything with a 3px solid red line and recorded a video of the page loading to identify where layout shifts are happening.
For our test page, what we may want to do is preload our custom font, drop the custom font completely (doubtful we will), or use a default font for the initial page load and only load our font on subsequent page loads. These have trade-offs in branding, style, consistency, etc, and we will have to decide what the best path is going forward.
- What forces layout/reflow — Paul Irish
- Optimize Cumulative Layout Shift — web.dev
- Debugging Layout Shifts — web.dev
- Understanding Cumulative Layout Shift — Annie Sullivan (video)
- How to avoid layout shifts caused by web fonts — Simon Hearne
First Input Delay (FID) — interactivity
FID is the time from when a user interacts with your page until the page can respond. You can also think of it as responsiveness. This does not include scroll or zoom.
- clicking on a link or button
- inputting text into a blank field
- selecting a drop-down menu
- clicking a checkbox.
It can be frustrating trying to click something and nothing happening on the page.
Not all users will interact with a page, so they may not have an FID value. This is also why lab test tools won’t have the value because they’re not interacting with the page. Use Total Blocking Time (TBT) instead.
Cause of FID
While a task is running, a page can’t respond to user input. This is the delay that is felt. The longer the task, the longer the delay experienced by the user. The breaks between tasks are the opportunities that the page has to switch to the user input task and respond to what they wanted to do.
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 based on the same conditions with the hope that the test results are repeatable.
|Chrome User Experience Report||✔||✔||✔|
|Google Search Console (Core Web Vitals report)||✔||✔||✔|
|Web Vitals Extension||✔||✔||✔|
|Chrome DevTools||✔||✘ (use TBT)||✔|
|Lighthouse||✔||✘ (use TBT)||✔|
|WebPageTest||✔||✘ (use TBT)||✔|
|PageSpeed Insights||✔||✘ (use TBT)||✔|
|web.dev||✔||✘ (use TBT)||✔|
I like the report in GSC because you can see the data for many pages at once, but the data is a bit delayed and on a 28 day rolling average so changes may take some time to show up in the report. In Chrome 88, Google is adding Core Web Vitals right in DevTools.
You can also find the scoring weights for Lighthouse at any time and see the historical changes.
You want to improve Core Web Vitals so that your users have a better experience. It remains to be seen what impact they’ll have for SEO, but as I mentioned in my page speed article, they should help you record more data in your analytics which “feels” like an increase.
Work with your developers; they are the experts here. Page speed can be extremely complex. If you’re on your own you may need to rely on a plugin or service to handle this like WP Rocket or NitroPack.