Core Web Vitals Explained: LCP, INP, CLS and What to Fix First

Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how fast the main content appears, how quickly the page responds to a click or tap, and how much the layout jumps while it loads. The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

This piece is the hub for our coverage of site speed and search. It walks through what each metric measures, the "good" thresholds, the 75th percentile rule, the difference between field data and lab data, where to find your numbers, how much they matter for ranking, and the fixes that usually work on WordPress and Drupal sites.

The short version: a page passes when 75% of real visits meet all three targets, LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less. Google says Core Web Vitals are used by its ranking systems, and also says relevance still comes first. For most nonprofit, association and university sites, the fixes are ordinary: smaller and better-prioritized images, fewer third-party scripts, page caching and decent hosting.

What Core Web Vitals measure

Each metric covers one part of the visit. LCP covers loading. INP covers responsiveness. CLS covers visual stability. Google’s Web Vitals overview on web.dev lists all three as stable metrics.

web.dev sorts metrics into three stages: experimental, pending and stable. A pending metric waits at least six months before it can become stable. Stable definitions change no more than once a year.

That lifecycle is how INP arrived. It moved from experimental to pending in 2023, with the stated aim of retiring First Input Delay (FID). It became a stable Core Web Vital on March 12, 2024, when it replaced FID, according to the web.dev announcement. If an older audit or plugin still reports FID, it is out of date.

Core Web Vitals sit inside what Google calls page experience, which also covers HTTPS, mobile display, ads and interstitials. We cover that wider checklist in Technical SEO in 2026. This post stays with the three metrics.

LCP: how fast the main content shows up

Largest Contentful Paint is the time from when a page starts loading until the largest image or text block in the viewport is rendered. On most of our readers’ sites, that element is a hero image, a banner photo or the main headline.

According to web.dev’s LCP article, the candidates include images, video poster images, elements with a CSS background image, and block-level text. Good is 2.5 seconds or less. Poor is over 4 seconds.

web.dev’s guide to optimizing LCP splits the time into four parts. Time to First Byte is how long the server takes to start sending HTML. Resource load delay is the gap before the browser starts fetching the LCP image. Resource load duration is the download itself. Element render delay is the wait between download and display.

A slow server shows up in the first part. An image the browser finds late shows up in the second. The guide says download time "tends not to be a significant bottleneck for most sites." So the first places to look are the server response and how early the browser finds the image.

INP: how fast the page responds

Interaction to Next Paint measures the delay between a visitor’s action and the next visual update. If someone taps "Donate" and nothing changes for half a second, that is a slow interaction.

According to web.dev’s INP article, only clicks, taps and key presses count. Hovering, scrolling and zooming do not. Each interaction’s time includes three phases: input delay, processing time and presentation delay.

INP looks at the whole visit, not just the first interaction. For most pages, the value is the slowest interaction. On pages with many interactions, web.dev says one of the slowest is ignored for every 50, so a single odd event does not decide the score.

Good is 200 milliseconds or less. Poor is over 500 milliseconds.

INP depends on JavaScript. Every script on the main thread can delay a response, and chat widgets, tag managers, consent banners, embedded forms and page builders all compete for that thread.

FID only measured the delay before the first interaction started. INP covers every interaction through to the next paint, so sites that passed FID can fail INP.

CLS: how much the page jumps around

Cumulative Layout Shift measures unexpected movement. It is the reason a visitor goes to tap a link and hits an ad that pushed it down.

web.dev’s CLS article explains the math. Each shift gets a score based on how much of the viewport moved and how far. Shifts that happen close together are grouped into a window. A window ends after a one-second gap or when it reaches five seconds. CLS is the score of the worst window, not the total for the whole visit.

Shifts within 500 milliseconds of a click, tap or key press do not count, because the visitor caused them. Good is 0.1 or less. Poor is over 0.25.

web.dev names the common causes: images and videos without set dimensions, web fonts that render at a different size than the fallback, ads and widgets that resize themselves, and content inserted above what is already on screen.

Core Web Vitals thresholds and the 75th percentile rule

Google does not judge a page on one visit. It looks at the 75th percentile of real page loads, split by mobile and desktop. web.dev says a page passes "if it meets the recommended targets at the 75th percentile for all three" metrics.

In plain terms, sort every visit from fastest to slowest. Go three-quarters of the way down the list. If that visit meets the target, the page is good for that metric. The slowest quarter of visits can miss and the page still passes.

Your own visit on office fiber says little. The 75th percentile visit is often a mid-range phone on a busy mobile connection, and mobile is usually the harder test.

The figures above match the thresholds table in Search Console’s Core Web Vitals report help page. Search Console also rates a group of URLs by its worst metric. A group with good INP and poor CLS shows as poor.

Field data vs lab data

There are two kinds of Core Web Vitals numbers, and they answer different questions.

Field data comes from real visitors. Google’s source is the Chrome User Experience Report (CrUX). According to the CrUX methodology page, it includes Chrome users on desktop and Android who have opted in to usage statistics and sync their history. Chrome on iOS is excluded, as are other Chromium browsers such as Edge.

A page also has to be publicly indexable and popular enough to be included. Google does not publish the visitor threshold. Small sites can have origin-level data but no page-level data, or neither.

Lab data comes from a test run under fixed conditions, usually Lighthouse. It is repeatable and useful for debugging. It is not what Google uses to assess the page.

Lab tools have one big gap. Lighthouse cannot measure INP, because no one is clicking during the test. web.dev suggests Total Blocking Time (TBT) as the lab stand-in. A good TBT suggests INP may be fine. Only field data confirms it.

The two will often disagree. PageSpeed Insights’ documentation says its lab test simulates a single mid-tier mobile device on a fixed network, while field data reflects many devices and connections. When they conflict, trust the field data for the score and use the lab data to find the cause.

Where to see your Core Web Vitals

Three free tools cover most needs. All three read from CrUX for field data.

Search Console. The Core Web Vitals report groups similar URLs and rates each group good, needs improvement or poor, separately for mobile and desktop. Values cover the last 28 days. After you fix an issue, you can start validation, which runs a 28-day monitoring session. A URL group without enough data is left out. If you are investigating a drop in clicks, our Search Console walkthrough for traffic drops shows where this report fits.

PageSpeed Insights. Enter one URL and you get field data from CrUX at the top and a Lighthouse lab run below. Field data covers the previous 28-day collection period. If the page lacks enough data, PageSpeed Insights falls back to the whole origin. A page passes its Core Web Vitals assessment when the 75th percentile of all three metrics is good. If there is not enough INP data, it passes on LCP and CLS alone.

CrUX directly. Chrome’s documentation lists the CrUX API, the CrUX History API, CrUX on BigQuery and CrUX Vis. The History API and CrUX Vis are useful for showing a client a trend over months instead of a single snapshot.

For debugging, Chrome DevTools shows all three metrics for your own session, including which element is the LCP element.

How much Core Web Vitals matter for ranking

Google’s answer is careful. Its page experience documentation says it directly: "Core Web Vitals are used by our ranking systems."

The same page says there is no single page experience signal. It also says other page experience aspects beyond Core Web Vitals do not directly help a site rank higher.

Then comes the limit. Google writes: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." It adds that for many queries there is a lot of helpful content available, and that is where a great page experience can contribute to success.

On scores, Google says good results in Search Console or third-party tools do not guarantee top rankings. It also says "trying to get a perfect score just for SEO reasons may not be the best use of your time."

Google says its core ranking systems generally evaluate content on a page-specific basis, including page experience, while also using some site-wide assessments. The Core Web Vitals page on Search Central recommends that site owners achieve good scores for success with Search.

Our reading: Core Web Vitals are a real factor and a modest one. Moving from poor to good is worth doing, for visitors as much as for search. Moving from good to perfect is rarely worth an agency’s time. A slow page with the best answer can still outrank a fast page with a weak one.

Fixing LCP: images, fonts and priority

On CMS sites the LCP element is usually the hero image, so most fixes start there. The fixes from web.dev’s LCP guide are specific:

1. Never lazy-load the LCP image. Lazy loading tells the browser to wait, which is the opposite of what the main image needs.
2. Make it discoverable in the HTML. An image set in CSS or injected by JavaScript is found late. A plain image tag in the markup is found early.
3. Give it high priority. Add fetchpriority="high" to the likely LCP image, and to no more than one or two images.
4. Make it smaller. Size it for the layout, use a modern format and compress it. An image CDN can do this per device.
5. Cut render-blocking files. Reduce large stylesheets and synchronous scripts in the page head.

Fonts touch both LCP and CLS. If the main headline is the LCP element, a slow font delays it. web.dev recommends a font-display value other than auto or block, so text shows in a fallback font first.

To keep the swap from shifting the layout, its CLS guide recommends preloading critical fonts and tuning the fallback with size-adjust and related properties. Fewer font files and weights help both metrics.

Fixing INP and CLS: scripts and space

Third-party scripts are a common source of main-thread work on CMS sites. web.dev’s INP guide starts with reducing main-thread activity such as script evaluation and breaking up long tasks. On a typical association site, that means an audit of what loads on every page.

• List every tag in the tag manager and remove the ones no one uses.
• Load chat, survey and social widgets only on the pages that need them, or after the visitor interacts.
• Check heavy embeds such as donation forms, event calendars and maps, and load them below the fold when you can.
• For your own code, keep click handlers small and move non-urgent work until after the next frame.

Layout shifts mostly come from missing space. web.dev’s CLS guide says to "always include width and height size attributes on your images and video elements." Reserve space for ads, embeds and iframes with min-height or aspect-ratio.

Avoid inserting banners above existing content. Overlay them or reserve their space instead. Animate with transform rather than changing position or size. The guide also recommends keeping pages eligible for the browser’s back/forward cache, so returning visitors get the restored page without repeat shifts.

Fixing TTFB: caching, CDNs and hosting

Time to First Byte is the first part of LCP, and no front-end fix can make up for a slow server. If the HTML takes two seconds to arrive, a 2.5-second LCP is nearly out of reach.

Three things usually fix it:

1. Full-page caching. Anonymous visitors should get a cached page, not a freshly built one. Most managed WordPress and Drupal hosts offer this at the server or edge.
2. A CDN. Serving cached pages and images from a location near the visitor cuts network time. Our explainer on what a CDN is covers how that works.
3. Hosting that fits the site. Underpowered shared hosting can cause slow TTFB on its own. Our managed WordPress hosting framework and our Pantheon vs Acquia comparison for Drupal cover what to look for.

web.dev also warns against cache-busting URL parameters that stop a CDN from caching a page. Tracking parameters can do this if the CDN does not ignore them.

If your host changes its edge layer, recheck field data afterward, as we noted when Pantheon made its Cloudflare-based Global CDN the default.

Core Web Vitals fixes on WordPress

WordPress core already handles some of this. According to the WordPress 6.3 image performance note, core adds fetchpriority="high" to the image it judges most likely to be the LCP image. It also stops adding loading="lazy" to images it expects in the viewport. The note says the fetchpriority change "typically improves LCP by 5-10%."

Core’s guess can be wrong. Sliders, page builders and custom hero blocks can render the main image in a way core does not detect. Check the LCP element in PageSpeed Insights, then confirm it has high priority and no lazy loading.

WordPress 6.8 added speculative loading. The core dev note says it prefetches a page when a visitor starts clicking a link, in browsers that support the Speculation Rules API (Chrome, Edge and Opera at the time). It does not apply to logged-in users.

Other WordPress gains come from the site itself:

• Retire unused plugins, especially ones that add scripts to every page.
• Replace a heavy slider with a single static hero image.
• Use page caching from the host rather than stacking several caching plugins.
• Test the theme’s font loading and image sizes on a mid-range phone.

Core Web Vitals fixes on Drupal

Drupal has strong caching built in. Core’s Internal Page Cache stores full pages for anonymous visitors and is enabled by default, according to Drupal’s documentation. Dynamic Page Cache handles logged-in users. BigPipe sends the cacheable parts of a page first and streams personalized parts afterward.

Most Drupal fixes are configuration:

• Aggregation turned off. Check that CSS and JavaScript aggregation are on under Configuration, then Development, then Performance.
• The hero image lazy-loaded. Since Drupal 10.1, responsive image formatters can set loading="lazy", and the change record says new fields default to lazy. Set the hero image field to eager.
• No fetch priority control. Core does not offer an easy setting for fetchpriority, according to a contributed module that adds one. A template override or that module can fill the gap.
• Personalized pages that skip the cache. Member dashboards and AMS-connected blocks can make whole pages uncacheable. Isolate those blocks so the rest of the page can still cache.

If the upgrade is still ahead, our Drupal 10 to 11 migration guide covers the steps.

Where Core Web Vitals stand as of October 2026

This is the one section in this guide likely to date. The figures below were checked against Google’s pages in October 2026.

Neither page lists a new metric or a threshold change in 2025 or 2026. A new metric would spend at least six months as pending first, so there would be notice.

A working order for agencies

When a client asks about Core Web Vitals, this order keeps the work focused:

1. Start with field data. Open the Search Console report and note which metric fails, on which device, for which URL groups.
2. Pick the templates. URL groups often line up with templates: home page, articles, events, member pages. Fix the template, not single URLs.
3. Diagnose in the lab. Run PageSpeed Insights and DevTools on one example of each failing template.
4. Fix in this order: server and caching, then the LCP image, then fonts and layout space, then third-party scripts.
5. Validate and wait. Start validation in Search Console and expect about 28 days before the field data reflects the change.

Speed helps a page that already deserves to rank. Our on-page SEO checklist and our guide to schema markup for AI Overviews cover the content side.

Frequently Asked Questions