Core Web Vitals are three metrics Google uses to measure the real-world experience of loading and using a web page: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are measured from actual visitors in the Chrome browser, and they form part of the page experience signals Google considers when ranking pages.

To pass, a page needs a “good” score on all three metrics at the 75th percentile of visits, meaning at least three out of four real page loads meet each threshold. Google reports mobile and desktop separately, and mobile is usually the harder one to pass.

The three metrics and their thresholds

Largest Contentful Paint (LCP): loading

LCP measures how long it takes for the largest visible element in the viewport, usually a hero image, a video poster, or a large block of heading text, to finish rendering. It is a good proxy for when a visitor feels that the main content has arrived.

Good: 2.5 seconds or less. Needs improvement: 2.5 to 4 seconds. Poor: more than 4 seconds.

Interaction to Next Paint (INP): responsiveness

INP measures how quickly a page responds visually after someone clicks, taps, or presses a key, across all the interactions during a visit. It replaced First Input Delay (FID) as a Core Web Vital in March 2024, because FID only measured the delay before the first interaction was processed, not how long the page took to respond.

Good: 200 milliseconds or less. Needs improvement: 200 to 500 milliseconds. Poor: more than 500 milliseconds.

Cumulative Layout Shift (CLS): visual stability

CLS measures how much visible content moves unexpectedly while the page is in use: the paragraph that jumps down when an image loads above it, or the button that shifts just as you go to tap it. It is a unitless score based on how much of the screen moved and how far.

Good: 0.1 or less. Needs improvement: 0.1 to 0.25. Poor: more than 0.25.

Field data vs. lab data

The most common confusion about Core Web Vitals is the difference between a Lighthouse or PageSpeed Insights score and the Core Web Vitals assessment.

Lab data comes from a single simulated page load on a test device under controlled conditions. Lighthouse’s performance score (0 to 100) is lab data. It is useful for diagnosing problems and testing fixes, because it is repeatable and gives detailed recommendations.

Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. Core Web Vitals pass or fail is based on field data, and it is what Google uses for ranking purposes.

The two can disagree. A page can score 95 in Lighthouse and still fail Core Web Vitals because real visitors on slower phones and connections have a worse experience than the test device, or because a third-party script that loads after the lab test finishes hurts INP. Always check the field data in Search Console’s Core Web Vitals report or at the top of PageSpeed Insights before deciding a page is fine.

Low-traffic pages may not have enough visits to produce field data. In that case Search Console groups them with similar URLs or reports that there is not enough data, and lab testing is the best available guide.

Do Core Web Vitals affect rankings?

Yes, but not as much as relevance and content quality. Google has described page experience as a factor that matters most when several pages are similarly relevant to a query; a slow page with the best answer can still outrank a fast page with a weaker one. The larger effect is indirect. Slow, unstable pages lose visitors before they read anything, which hurts conversion rates and the engagement that follows a good result. Fast, lightweight pages are also easier for search and AI crawlers to fetch and render completely.

What causes poor Core Web Vitals

Common LCP problems

Oversized or uncompressed hero images; a hero image that is lazy-loaded when it should load immediately; images served in older formats instead of WebP or AVIF; render-blocking CSS and JavaScript in the head of the page; slow server response times; and web fonts that delay text rendering. On WordPress sites, page builders that ship large amounts of markup and styling are a frequent underlying cause.

Common INP problems

Too much JavaScript running on the main thread, especially from third-party scripts such as chat widgets, tag managers loading many tags, heatmap tools, social embeds, and advertising. Long tasks that block the browser from responding, heavy event handlers, and large, complex page structures (a very large DOM) also slow responses.

Common CLS problems

Images, videos, and iframes without width and height attributes; ads and embeds that load late without reserved space; banners and cookie notices inserted above existing content; and web fonts that swap in at a different size from the fallback font.

How to improve Core Web Vitals

Start with the failing metric on each template. Search Console groups URLs by issue. Fix the template, and every page built on it improves together.

For LCP: identify the LCP element, then preload it, serve it at the right size in a modern format, avoid lazy-loading it, and remove anything that blocks it from rendering. Inline the critical CSS, defer non-essential JavaScript, use a CDN, and improve server response with proper caching. Our guide to optimizing and minifying CSS covers the render-blocking part in detail.

For INP: reduce, defer, and split JavaScript; remove or delay third-party scripts that are not essential; break up long tasks; and simplify heavy interactive components. Our article on JavaScript best practices covers the techniques.

For CLS: give every image, video, and embed explicit dimensions, reserve space for anything that loads late, avoid inserting content above what the visitor is reading, and load fonts so that the fallback and final fonts take up similar space.

Supporting work: lazy loading below the fold, caching, minification, and a lean plugin stack. Our long-form guide, 10 ways to optimize and accelerate your WordPress website, walks through each for WordPress specifically.

Then verify in the field. Lab scores improve as soon as changes deploy. Field data takes up to 28 days to fully reflect them, because it is a rolling window of real visits. Use Search Console’s validation feature once fixes are live.

Core Web Vitals on WordPress

WordPress itself can be very fast. Most WordPress performance problems come from what is added on top of it: heavy themes and page builders, many plugins each loading their own scripts and styles on every page, large unoptimized images, and a growing list of third-party tags. Caching plugins help repeat visitors and server load, but they do not reduce what the browser has to download and run on a first visit, which is what field data mostly measures.

The results we have seen come from fixing that underlying weight. Rebuilding Dragonboat’s site on a custom theme with its design preserved cut LCP from 15.7 seconds to 2.3 seconds. Moving Hoppr from Squarespace to a custom WordPress theme took LCP from 15.2 seconds to 0.8 seconds. Replacing Fidelity Bank’s plugin stack with theme code reduced its homepage HTML from 595 KB to 87 KB. None of those changes involved adding another optimization plugin.

Tools for measuring Core Web Vitals

Google Search Console: the Core Web Vitals report shows field data for your whole site, grouped by status and issue, for mobile and desktop.

PageSpeed Insights: shows field data for a URL (when available) at the top and a Lighthouse lab test with diagnostics below.

Chrome DevTools: the Performance panel shows live LCP, INP, and CLS as you interact with a page and helps identify the specific element or script responsible.

CrUX data: the Chrome User Experience Report is the underlying field dataset, available through several dashboards and APIs for tracking trends over time.

Getting help

If your site is failing Core Web Vitals, our page speed optimization services diagnose the failing metric on each template and fix it in the code, then verify the result in Google’s field data. For sites where the theme or page builder is the underlying problem, we will tell you so and explain what a rebuild would involve. Book a discovery call and send us the URL.