New here? Visit our beginner’s guide to SEO.

Core Web Vitals: Page Speed Is Now More Important for SEO

Patrick Stox
Patrick Stox is Product Advisor, Technical SEO and Brand Ambassador at Ahrefs. He’s an organizer for the Raleigh SEO Meetup, Raleigh SEO Conference, Beer & SEO Meetup, Findability Conference, and moderator on /r/TechSEO.
Article stats
  • Monthly traffic 22
  • Linking websites 73
  • Tweets 69
Data from Content Explorer

Shows how many different websites are linking to this piece of content. As a general rule, the more websites link to you, the higher you rank in Google.

Shows estimated monthly search traffic to this article according to Ahrefs data. The actual search traffic (as reported in Google Analytics) is usually 3-5 times bigger.

The number of times this article was shared on Twitter.

    Core Web Vitals are the speed metrics that are part of Google’s Page Experience signals used to measure user experience. The metrics measure visual load with Largest Contentful Paint (LCP), visual stability with Cumulative Layout Shift (CLS), and interactivity with First Input Delay (FID).

    Page experience and the included Core Web Vital metrics will officially be used for ranking pages in June 2021.

    Source: Google

    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.

    Source: web.dev/vitals

    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:

    1. Performance > check “Screenshots”
    2. Click ‘Start profiling and reload page’
    3. LCP is on the timing graph
    4. Click the node; this is the element for LCP

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

    Resources

    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.

    Source: web.dev/vitals

    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
    • Injecting content with JavaScript
    • 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.

    Optimizing CLS

    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.

    Resources

    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.

    Example interactions:

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

    Source: web.dev/vitals

    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

    JavaScript competing for the main thread. There’s just one main thread, and JavaScript competes to run tasks on it.

    Source: https://web.dev/long-tasks-devtools

    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.

    Optimizing FID

    I don’t see any concerns for our site for FID, but in general, you want to break 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 based on the same conditions with the hope that the test results are repeatable.

    Field data

     LCPFIDCLS
    Chrome User Experience Report
    PageSpeed Insights
    Google Search Console (Core Web Vitals report)
    Web-vitals JavaScript library
    web.dev
    Web Vitals Extension

    Lab data

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

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

    • Monthly traffic 22
    • Linking websites 73
    • Tweets 69
    Data from Content Explorer