Performance & Security

Core Web Vitals: What LCP, FID and CLS Mean for Rankings

Google's new Core Web Vitals explained in plain English: what LCP, FID and CLS measure, the thresholds to aim for, how to check your site and what the planned ranking change means.

Quick answer: Core Web Vitals are three measurements Google introduced in May 2020 to describe how a page feels to real visitors. Largest Contentful Paint (LCP) measures loading, First Input Delay (FID) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. Google has announced that these metrics will become part of a new “page experience” ranking signal, but not before 2021, and it has promised six months’ notice. You have time to measure your pages now and fix the worst problems before the change arrives.

Where Core Web Vitals came from

On 5 May 2020 the Chrome team announced Web Vitals, an effort to give site owners a small set of clear signals for user experience instead of dozens of competing speed metrics. Within that set, three metrics were picked as the “Core Web Vitals” for 2020. Google said the set may change over time as its understanding of user experience improves.

A few weeks later, on 28 May, Google Search explained how these metrics will be used for ranking. It plans a page experience signal that combines Core Web Vitals with existing signals:

  • Mobile-friendliness
  • Safe browsing (no malware or deceptive content)
  • HTTPS
  • No intrusive interstitials, such as pop-ups that block the main content

Google was clear that great content still matters most. A page with the best information can still rank well with an average page experience. Where several pages are similarly relevant, page experience may decide which one appears higher. Google also said that once the change launches, pages will no longer need to use AMP to appear in the Top Stories carousel on mobile, as long as they meet the page experience criteria.

The three metrics explained

Largest Contentful Paint (LCP): loading

LCP records the time from when the page starts loading to when the largest image or text block in the visible area has rendered. On most pages that is a hero image, a large heading or a featured video poster. It is a better stand-in for “has the main content appeared?” than older metrics such as full page load.

Thresholds:

  • Good: 2.5 seconds or less
  • Needs improvement: between 2.5 and 4 seconds
  • Poor: more than 4 seconds

Common causes of slow LCP:

  • Slow server response time, often from cheap shared hosting or no page caching
  • Render-blocking CSS and JavaScript in the head of the page
  • Large, uncompressed hero images
  • Content that only appears after JavaScript runs in the browser

Our guide to server response time covers the first of these in detail.

First Input Delay (FID): responsiveness

FID measures the delay between a visitor’s first interaction, such as a tap on a button or a click on a link, and the moment the browser can start handling it. A long delay usually means the main thread is busy running JavaScript, so the page looks ready but does not respond.

Thresholds:

  • Good: 100 milliseconds or less
  • Needs improvement: between 100 and 300 milliseconds
  • Poor: more than 300 milliseconds

FID needs a real person to interact with the page, so it can only be measured in the field. Lab tools use Total Blocking Time (TBT) instead. TBT adds up the periods where the main thread was blocked for long enough to delay input. If you bring TBT down, FID usually follows.

Typical causes of poor FID are heavy JavaScript bundles, page builders that load lots of scripts, and third-party tags for chat, ads, heatmaps and social widgets. See our guide to third-party scripts and speed for a way to audit them.

Cumulative Layout Shift (CLS): visual stability

CLS scores how much visible content moves around unexpectedly while the page loads. Everyone has tried to tap a link, only for an ad or image to load above it and push the link down. CLS puts a number on that frustration. The score combines how much of the screen moved and how far it moved.

Thresholds:

  • Good: 0.1 or less
  • Needs improvement: between 0.1 and 0.25
  • Poor: more than 0.25

Usual causes:

  • Images and video embeds without width and height attributes
  • Ads, embeds and iframes with no reserved space
  • Banners or notices injected above existing content, such as cookie bars that push the page down
  • Web fonts that swap in and change text size

Shifts that happen within half a second of a user action, such as opening an accordion after a click, do not count, because the user expects them.

How Google judges a page

Google assesses each metric at the 75th percentile of page loads, split by mobile and desktop. In plain terms, for a page to count as “good” on LCP, at least three out of four visits need an LCP of 2.5 seconds or less. This approach stops a handful of very fast visits from hiding a poor experience for many others.

The data Google uses for ranking comes from real Chrome users through the Chrome User Experience Report, not from a single lab test you run on your own fast connection. Low-traffic pages may not have enough field data, in which case reports group them with similar URLs or show no data.

How to measure Core Web Vitals on your site

Google updated several tools at the same time as the announcement.

Search Console Core Web Vitals report

The Core Web Vitals report in Search Console replaces the old Speed report. It groups your URLs into Good, Needs improvement and Poor for mobile and desktop, and shows which metric is the problem. Start here, because it uses the same field data that the ranking signal will use. If you have not set up Search Console yet, our Google Search Console guide walks you through it.

PageSpeed Insights

PageSpeed Insights shows two kinds of data for a single URL: field data from the Chrome User Experience Report at the top, and a Lighthouse lab test underneath. Field data tells you what real visitors experience. Lab data helps you find the cause and test fixes.

Lighthouse and Chrome DevTools

The latest Lighthouse release reports LCP, CLS and Total Blocking Time in its performance score. In Chrome DevTools, the Performance panel can highlight layout shifts and show which element is counted as the largest contentful paint.

The web-vitals library and Chrome extension

Developers can add Google’s small open source web-vitals JavaScript library to send each visitor’s LCP, FID and CLS to an analytics tool, such as Universal Analytics events. This is useful for pages without enough data in the public report. There is also a Web Vitals extension for Chrome that shows the metrics as you browse your own pages.

Practical fixes that move the numbers

You do not need to chase a perfect score. Focus on getting your key templates, such as the home page, service pages, product pages and blog posts, into the “good” band on mobile.

Improve LCP

  • Use good hosting and enable page caching so HTML arrives quickly
  • Put a CDN in front of static files
  • Compress and resize hero images, and serve them at the size they display
  • Inline the critical CSS and defer non-essential scripts
  • Avoid hiding the main content behind sliders that wait for JavaScript

Improve FID

  • Remove plugins and tags you no longer use
  • Defer or delay third-party scripts that are not needed for the first view
  • Break up long JavaScript tasks and load code only on pages that need it
  • Be careful with heavy page builder add-ons on simple pages

Improve CLS

  • Always set width and height on images and video embeds
  • Reserve space for ads, embeds and iframes with fixed-size containers
  • Show cookie notices as overlays at the bottom rather than pushing content down
  • Preload key web fonts and use font-display settings that limit text jumps
  • Avoid inserting content above what the visitor is already reading

Be careful with lazy loading images. It helps overall weight, but lazy loading the hero image itself can hurt LCP because the browser waits before fetching it.

What this means for your rankings right now

As of June 2020, the page experience ranking signal is announced, not live. Nothing changes overnight in search results because of Core Web Vitals. That gives you a useful window:

  1. Check the Core Web Vitals report in Search Console and note which page groups are Poor.
  2. Fix shared problems in templates first, because one change can improve hundreds of URLs.
  3. Re-test in the lab, then watch field data improve over the following weeks. The field data is based on a rolling 28-day window, so changes take time to show.
  4. Keep content quality as your first priority. Speed will not rescue a page that does not answer the search.

Faster, steadier pages also tend to convert better, so the work pays off even before any ranking effect.

FAQ

Are Core Web Vitals a ranking factor yet?

Not yet. Google has said they will become part of a page experience signal, starting no earlier than 2021, with six months’ notice.

Do I need a perfect PageSpeed score?

No. The score is a lab summary. Aim for “good” field values for LCP, FID and CLS on your important pages.

Why does my lab test look fine while Search Console shows Poor?

Lab tests run on one device and connection. Field data reflects your real visitors, many of whom use slower phones and networks.

Will Core Web Vitals change?

Google has said the set of metrics will be updated over time, so treat them as the current yardstick rather than a permanent one.

Getting your pages ready

Core Web Vitals give you a clear, shared way to measure how pages feel to real people, and a ranking reason to act on it. If you would like help finding what slows your key pages down and fixing it, see how we help businesses turn visitors into customers.

About the author

Imran M

Leave a Reply

Your email address will not be published. Required fields are marked *

Ready to improve your website?

Let's build a faster, higher performing website.