Core Web Vitals Explained

Core Web Vitals are three measurements Google takes of real visits to your pages: Largest Contentful Paint (LCP), how long the main content takes to appear; Interaction to Next Paint (INP), how quickly the page responds when someone taps or clicks; and Cumulative Layout Shift (CLS), how much the layout jumps around while loading. A page passes when at least 75 percent of visits meet the “good” threshold for all three. The metrics are a ranking signal, a smaller one than content and links, and a direct measure of whether your site is annoying to use. This guide explains what each one means, how to read the reports, and what to fix.

The three metrics

Each metric has a “good” threshold, a “poor” threshold and a band in between labelled “needs improvement”. Scores are taken at the 75th percentile of real visits, so a page that is fast for most people but slow for the slowest quarter still fails.

Metric	What it measures	Good	Poor	What usually causes a bad score
LCP (Largest Contentful Paint)	Time until the largest visible element, usually a hero image or heading block, has rendered	2.5 seconds or less	Over 4 seconds	Slow server response, large or late-loaded hero images, render-blocking CSS and scripts, web fonts
INP (Interaction to Next Paint)	Delay between a user’s tap, click or key press and the next visual update, across the whole visit	200 milliseconds or less	Over 500 milliseconds	Heavy JavaScript on the main thread, third-party scripts, large DOMs, event handlers that do too much
CLS (Cumulative Layout Shift)	How much visible content moves unexpectedly during the visit	0.1 or less	Over 0.25	Images and embeds without reserved space, injected banners and ads, late-loading fonts, content inserted above existing content

INP replaced the earlier First Input Delay metric. The difference matters: FID measured only the first interaction’s delay, while INP looks at interactions throughout the visit and reports one of the slowest, so a page can pass FID and fail INP. The thresholds above are the current published ones; check Google’s web.dev documentation if you are reading this much later, because definitions have changed before.

Reading the reports

Two reports matter, and they answer different questions.

Search Console: which pages fail

The Core Web Vitals report in Google Search Console groups your URLs into poor, needs improvement and good, for mobile and desktop separately, based on real-visit data from Chrome users. It tells you which groups of pages have a problem and which metric is failing, but not why. Pages with little traffic may not appear at all because there is not enough data.

PageSpeed Insights: why a page fails

Paste a URL into PageSpeed Insights and you get two sections. The top section, “Discover what your real users are experiencing”, is field data: the same real-visit numbers Search Console uses, for that URL and for the whole origin. The lower section is lab data: a single simulated load on a throttled mobile connection, with a diagnostic list of what slowed it down. The lab run is where you find causes; the field data is what Google judges.

Three reading rules save a lot of confusion. First, the lab performance score out of 100 is not a Core Web Vitals pass or fail; only the field data decides that. Second, lab INP is not measured directly, so a page can look fine in the lab and fail INP in the field because of what users do after load. Third, the field data lags: after a fix, expect the 28-day window to take weeks to reflect it. For deeper work, Chrome DevTools’ performance panel and the Lighthouse report show the same lab data with more detail.

Fixes for LCP

LCP is a loading problem. Work through the chain in order, because a slow start makes everything after it late.

1. Cut server response time. Measure time to first byte. Use page caching so the server returns a stored copy instead of building the page each time, put a content delivery network in front of the site, and fix slow database queries. Hosting that is overloaded cannot be fixed in the front end.
2. Make the LCP element load early. Find which element is the LCP element in the lab report. If it is an image, serve it at the size it is displayed, in a modern format such as WebP or AVIF, with a preload hint and without lazy loading. Lazy-loading the hero image is one of the most common self-inflicted LCP failures.
3. Remove render-blocking resources. Inline the small amount of CSS needed for the first screen and defer the rest; load scripts with defer or async; remove plugins and tag-manager scripts that nobody can justify.
4. Handle web fonts. Self-host fonts, preload the one or two files used above the fold, and set font-display so text shows in a fallback font while the web font loads.
5. Reduce what loads at all. Fewer scripts, smaller CSS, no slider carousels on the home page, compressed images everywhere.

Fixes for INP

INP is a responsiveness problem, and the cause is almost always JavaScript occupying the main thread when the user interacts.

1. Find the slow interactions. Use the performance panel in Chrome DevTools, or a real-user monitoring tool, to see which interactions are slow and which scripts run during them. Common culprits: menu toggles, filters, add-to-cart buttons and form validation that trigger large re-renders.
2. Cut third-party scripts. Chat widgets, analytics bundles, A/B testing tools, social embeds and ad tags often run on every interaction. Remove the ones that are not earning their cost, and load the rest after the page is interactive.
3. Break up long tasks. Any script that runs for more than 50 milliseconds blocks input. Split work into smaller chunks, yield to the browser between them, and move heavy computation to a web worker.
4. Shrink the DOM. Pages with thousands of elements take longer to re-render after every interaction. Page builders are a frequent cause; simplify the markup or the template.
5. Give immediate visual feedback. If an action takes time, show a state change at once (a pressed button, a spinner) and do the work afterward, so the next paint happens quickly.

Fixes for CLS

CLS is a layout problem and the cheapest of the three to fix, because the causes are visible.

1. Reserve space for images and embeds. Set width and height attributes, or a CSS aspect ratio, on every image, video, iframe and ad slot so the browser allocates the space before the content arrives.
2. Stop inserting content above existing content. Cookie banners, notification bars and promotional strips that push the page down are classic shifts. Overlay them or reserve their space.
3. Fix font swaps. A fallback font that is much wider or narrower than the web font shifts every line when the swap happens. Use size-adjust metrics or choose a closer fallback.
4. Load dynamic content into fixed containers. Reviews, related posts and product grids that arrive after load should fill a box of known height.
5. Prefer transform animations. Animating top, left, width or height triggers layout; animating transform does not.

WordPress specifics

Most of the sites we are asked to speed up run WordPress, and the causes repeat.

• Theme and page builder weight. Heavy themes and builders ship CSS and JavaScript for every feature on every page, and the resulting markup can run to thousands of nodes. Use the builder’s options to disable unused features, or move high-traffic templates to lighter blocks.
• Plugin sprawl. Each plugin can add scripts and styles site-wide. Audit the list; remove what is unused; for the rest, use an asset-management plugin to load scripts only on pages that need them.
• Caching and hosting. Use a page cache (host-level or a caching plugin), object caching for dynamic sites, and a CDN. Managed WordPress hosting usually handles the first two; a shared server rarely does.
• Images. Turn on WebP generation, set explicit dimensions (WordPress adds them for images inserted through the editor, but not always for theme and builder images), and make sure the hero image is excluded from lazy loading.
• Sliders, animations and pop-ups. Home-page sliders hurt LCP, scroll animations hurt INP, and pop-ups that push content hurt CLS. Most can be removed with no loss.
• Updates and PHP version. Keep WordPress, the theme, plugins and the PHP version current; newer PHP versions are measurably faster and old plugins often load legacy scripts.

Page speed optimization on WordPress is usually a cleanup rather than a rebuild. The exception is a site whose theme or builder cannot be tamed, where a rebuild on a lighter base is the honest answer and the website redesign checklist applies.

Where PS3G fits

PS3G builds websites to pass Core Web Vitals from launch and fixes the ones that do not. Our website maintenance and support service covers the ongoing work that keeps a site fast: updates, plugin audits, caching and hosting changes, image and script cleanup, and monitoring the Search Console report. Our SEO services include website speed optimization as part of technical SEO for the sites we build or maintain. We do SEO only for websites we build or maintain, because most speed fixes need a developer with access to the theme, the server and the code; we do not offer paid advertising, social media or email marketing. For a new site, the SEO checklist for a new website puts the speed work in the build plan from the start. The work is the same for a founder’s five-page site and for a department’s large WordPress installation; only the scale differs.

Related reading

• SEO Checklist for a New Website: Before and After Launch
• Website Redesign Checklist: 40 Steps That Protect Your Rankings
• Website maintenance and support services

Frequently asked questions

What are Core Web Vitals in simple terms?

Three measurements of how a page feels to a real visitor: how long the main content takes to show up (LCP), how quickly the page reacts when they tap or click (INP), and how much things jump around while it loads (CLS). Google collects them from real Chrome visits and uses them as one of many ranking signals.

How much do Core Web Vitals affect rankings?

They are a ranking signal, but a modest one compared with relevance, content quality and links. A fast page with weak content will not outrank a slow page with strong content. The practical effect is at the margins and in user behavior: visitors leave slow, jumpy pages, and that affects conversions regardless of rankings. Treat the metrics as a user-experience floor rather than a ranking strategy.

Why does PageSpeed Insights show a good lab score but failing field data?

The lab test is one simulated load; the field data is a 28-day collection of real visits on real devices and networks, including slow phones and interactions after load. INP in particular cannot be measured in a single lab load. Trust the field data for pass or fail and use the lab diagnostics to find causes.

How long after a fix does the Search Console report change?

Field data is collected over a rolling 28-day window, so a fix starts to appear within days and fully replaces the old data after about four weeks. Confirm the fix in the lab immediately, then watch the field numbers in PageSpeed Insights before expecting the Search Console groups to update.

Can a plugin fix Core Web Vitals on WordPress?

Caching, image and asset plugins help, and are often enough for LCP on a modest site. They cannot remove a heavy theme, a bloated page builder, a dozen third-party scripts or a slow server, which are the usual causes of INP and persistent LCP failures. Those need configuration changes, code changes or a hosting move, which is developer work.