Core web vitals: a practical guide for webmasters

Core Web Vitals are the three field metrics Google uses to judge real-user page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google evaluates these at the 75th percentile of real visits, which means your site needs to perform well for the majority of users, not just the lucky few on fast connections. Core Web Vitals feed directly into the page experience signal, which means poor scores can cost you rankings against equally relevant competitors.

Your immediate next steps:

Check the Search Console Core Web Vitals report to see which URL groups are failing and which metric is the culprit.
Run PageSpeed Insights on your highest-traffic pages to get both field data and a lab-based diagnosis in one place.
Fix the worst metric first — typically LCP on most sites, though INP is increasingly the stubborn one.

Key takeaways

Passing Core Web Vitals requires fixing TTFB and LCP first, controlling third-party scripts for INP, and setting explicit dimensions on media to prevent layout shifts — then monitoring continuously so deployments do not undo your gains.

Point	Details
Fix in order	Address TTFB and hosting before LCP, then INP, then CLS — each layer depends on the one before it.
75th-percentile rule	Google assesses your site at the 75th percentile of real visits, so 25% of slow sessions can still cause a failing rating.
INP is the hardest	INP measures the worst interaction across the full page lifecycle; third-party scripts and long tasks are the primary causes.
Monitor with RUM	CrUX uses a 28-day rolling window — use the web-vitals JS library for immediate post-deployment verification.
TTOY Digital	TTOY Digital offers performance audits and remediation for UK small business sites, covering hosting, images, scripts, and ongoing monitoring.

What do core web vitals actually measure?
How are core web vitals measured and reported?
Which tools should you use, and when?
How to improve core web vitals: fixes per metric
How to diagnose, prioritise, and plan your fixes
Why INP is often the hardest metric to fix
Do core web vitals still matter for search rankings?
How to monitor core web vitals continuously
Authoritative resources for deeper reading
Our take on core web vitals for small businesses
TTOY Digital’s performance audit and remediation services
Sources
FAQ

What do core web vitals actually measure?

Web Vitals is a Google initiative that defines Core Web Vitals as a stable set of field metrics covering loading, interactivity, and visual stability. The three metrics are deliberately narrow: each one targets a distinct dimension of how a page feels to a real user.

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element in the viewport to render. That element is usually a hero image, a large heading, or a video poster frame. A slow LCP is the most common complaint users have without being able to name it — the page just feels like it takes forever to show anything useful.

Interaction to Next Paint (INP) replaced First Input Delay in March 2024 and measures the latency of every interaction a user makes during their visit, from clicks to taps to keyboard input. It reports the worst interaction, which makes it far more demanding than its predecessor.

Cumulative Layout Shift (CLS) measures visual instability — how much the page layout jumps around unexpectedly. Ads that load late, images without declared dimensions, and web fonts that swap in mid-render are the usual culprits.

Official thresholds

The thresholds were chosen using CrUX data to balance user experience with achievability, so they represent what is genuinely attainable across the web, not an aspirational ideal.

Metric	Good	Needs improvement	Poor
LCP	≤ 2,500 ms	2,500 ms	> 2,500 ms
INP	≤ 200 ms	200 ms	> 200 ms
CLS	≤ 0.1	0.1	> 0.1

Google assesses your site at the 75th percentile of all page loads in the CrUX dataset. It is a tougher bar than it sounds.

Common LCP elements to check:

Hero images (the most frequent offender)
Large above-the-fold headings rendered in a custom web font
Video poster images
Background images loaded via CSS (these cannot be preloaded as efficiently)

Typical CLS causes:

Images and iframes without explicit width and height attributes
Ads or embeds that inject content above existing text
Web fonts that cause a visible text swap on load
Dynamically injected banners or cookie notices

How are core web vitals measured and reported?

There are two fundamentally different ways to measure performance: field data and lab data. Confusing them is one of the most common mistakes webmasters make when trying to interpret their scores.

Field data comes from real users visiting your site. Google collects this through the Chrome User Experience Report (CrUX), a dataset of anonymised, opt-in Chrome user sessions. CrUX is what Search Console and PageSpeed Insights use to show your “real” scores. It reflects actual network conditions, devices, and user behaviour — which is exactly why Google uses it for ranking decisions rather than lab scores.

Lab data comes from tools like Lighthouse and Chrome DevTools, which simulate a page load under controlled conditions (a fixed CPU throttle, a fixed network speed). Lab data is brilliant for debugging because you can reproduce it reliably, but it does not represent your real visitors.

The practical implication: you might fix something in Lighthouse and see no improvement in Search Console for weeks. That is not a bug. CrUX uses a 28-day rolling window, so changes take time to surface in field data.

A few other things worth knowing about how measurement works:

CrUX data is segmented by device type (phone vs desktop), so your mobile and desktop scores are assessed separately.
If your site has insufficient traffic, CrUX may not have enough data to report field scores. In that case, PageSpeed Insights falls back to lab data only, and Search Console will show no data for those URLs.
The 75th-percentile rule applies per URL group in Search Console, not per individual page. So a single poorly performing template can drag down an entire section of your site.

The data flow in practice: real Chrome users generate CrUX data → Google aggregates it over 28 days → PageSpeed Insights and Search Console surface it → your site is classified as Good, Needs improvement, or Poor per metric.

Which tools should you use, and when?

Each tool in the Core Web Vitals ecosystem has a specific job. Using the wrong one for the wrong task is like using a thermometer to diagnose a broken leg — you will get a reading, but it will not tell you what you need to know.

Developer guidance recommends matching the tool to the task: field data for understanding real-user experience, lab tools for debugging, and programmatic measurement for continuous monitoring.

Google Search Console — Core Web Vitals report Use this first. It shows aggregated CrUX field data grouped by URL pattern, device type, and failing metric. It tells you which pages are failing and which metric is the problem. Start here before opening any other tool.

PageSpeed Insights Use this for per-URL investigation. It combines CrUX field data (when available) with a Lighthouse lab run, so you can see both the real-world score and a detailed diagnostic in one place. Paste in your most important URLs — product pages, service pages, your homepage.

Lighthouse / Chrome DevTools Use these for debugging. Lighthouse gives you a full audit with specific recommendations; DevTools lets you profile the main thread, inspect layout shifts frame by frame, and trace long tasks. Neither reflects real-user conditions, but both are indispensable for finding why a metric is failing.

Chrome User Experience Report (CrUX) CrUX is the raw dataset behind Search Console and PageSpeed Insights. You can query it directly via the CrUX API or Google BigQuery if you need custom reporting, historical trend analysis, or competitor benchmarking at origin level.

web-vitals JavaScript library Use this for real-user monitoring (RUM) in your own analytics. Drop the web-vitals library into your site and pipe the data to Google Analytics 4, a custom dashboard, or a technical SEO monitoring stack. This gives you immediate visibility into changes — you do not have to wait 28 days for CrUX to catch up.

A quick tool-picker checklist:

Auditing a site for the first time → Search Console report, then PageSpeed Insights on top pages
Debugging a specific metric → Lighthouse in DevTools or PageSpeed Insights lab section
Continuous monitoring after a deployment → web-vitals JS library feeding your analytics
Investigating discrepancies between lab and field → compare PageSpeed Insights field vs lab tabs; check device segmentation in Search Console

When lab and field scores disagree significantly, the field score is the one that matters for rankings. Lab scores are a debugging proxy, not a ranking input.

How to improve core web vitals: fixes per metric

The most effective order to work through fixes is: TTFB → LCP → INP → CLS. Server speed is the foundation everything else sits on. There is no point obsessing over image compression if your server takes two seconds to respond.

Start with TTFB and hosting

Time to First Byte (TTFB) is not a Core Web Vital itself, but a slow TTFB makes a good LCP score almost impossible. Upgrading from shared hosting to managed hosting with server-level caching is often the single highest-impact change you can make, particularly for WordPress sites. A well-configured managed host with a full-page cache can cut TTFB from 800 ms to under 200 ms without touching a line of code. See our guide to website caching and performance techniques for a practical breakdown of the options.

LCP fixes

Once TTFB is under control, identify your LCP element using the Lighthouse “Largest Contentful Paint” diagnostic or the DevTools Performance panel.

Add fetchpriority="high" to the LCP image tag so the browser prioritises it immediately.
Add a <link rel="preload"> in the <head> for the LCP image, especially if it is loaded via CSS or a JavaScript carousel.
Never apply loading="lazy" to the LCP element — this delays the very thing Google is measuring.
Serve images in modern formats (WebP or AVIF) and use responsive srcset so mobile users do not download a 2 MB desktop image.
Compress images aggressively. Our guide to effective image practices for mobile covers the tools and workflows in detail.
Ensure the LCP element is in the server-rendered HTML, not injected by JavaScript after load. If a JavaScript framework renders your hero image client-side, that is a significant LCP problem.

INP fixes

INP is sensitive to anything that blocks the main thread. The fixes are less visual than LCP work and often require developer involvement.

Audit long tasks using the DevTools Performance panel. Any task over 50 ms is a candidate for breaking up.
Use scheduler.yield() or requestIdleCallback to yield control back to the browser between chunks of work, allowing it to respond to user input.
Defer non-critical JavaScript with defer or async attributes, and move scripts to the bottom of the page where possible.
Lazy-initialise third-party widgets (chat widgets, marketing scripts, video embeds) so they do not block the main thread on load.
Review your tag manager setup. Every marketing tag you add increases INP risk.

Pro Tip: Third-party scripts are the silent killers of INP. A single poorly written chat widget or A/B testing script can add hundreds of milliseconds to your worst interaction. Audit your tag manager regularly and remove anything that is not actively contributing to revenue. Our guide to automating your marketing covers how to consolidate tools and reduce script bloat.

CLS fixes

Layout shifts are usually fixable without touching JavaScript at all.

Set explicit width and height attributes on every image and iframe so the browser reserves space before the resource loads.
Reserve space for ad slots and embeds using CSS min-height or aspect-ratio containers.
Use font-display: swap or font-display: optional with a carefully matched fallback font to prevent text jumping when a web font loads.
Avoid inserting content above existing content dynamically — cookie banners, notification bars, and sticky headers are common offenders.

How to diagnose, prioritise, and plan your fixes

A structured audit takes less time than you think, and it stops you wasting effort on pages that barely get any traffic. The recommended workflow is: measure first, then prioritise by traffic and impact, fix in order (TTFB → LCP → INP → CLS), and verify with RUM.

Open Search Console and navigate to the Core Web Vitals report. Note which URL groups are rated Poor or Needs improvement, and which metric is failing.
Identify your page templates — most sites have a handful of templates (homepage, service page, blog post, product page) that account for the majority of URLs. Fixing one template fixes hundreds of pages.
Run PageSpeed Insights on one representative URL from each failing template. Record the field scores and the lab diagnostics.
Capture a Lighthouse baseline in DevTools so you have a reproducible starting point for before/after comparisons.
Set up the web-vitals JS library if you have not already, so you can verify improvements immediately without waiting for CrUX.
Prioritise by traffic × conversion value × severity. A Poor LCP on your highest-traffic service page outranks a Needs improvement CLS on a blog post from three years ago.

Rough effort estimates for common fixes:

Hosting upgrade / server caching — low effort, very high impact. Often a configuration change or plan upgrade.
Image optimisation and preloading — low to medium effort, high impact on LCP.
JavaScript deferral and async attributes — low effort, medium impact on INP.
Long task refactoring — high effort, high impact on INP. Requires developer time.
Image dimension attributes — very low effort, high impact on CLS.
Font-display strategy — low effort, medium impact on CLS.

For pages that drive the most traffic, prioritise ruthlessly.

Why INP is often the hardest metric to fix

LCP and CLS fixes are largely mechanical: find the slow image, preload it, add dimensions. INP is different. It measures responsiveness across the entire page lifecycle and is sensitive to long main-thread tasks and third-party scripts, which means the problem can come from almost anywhere and change depending on what the user does.

The root cause is nearly always main-thread contention. JavaScript execution, layout recalculations, and third-party scripts all compete for the same thread. When a user clicks a button and the browser is busy running a marketing script, the interaction feels sluggish — even if the visual result appears quickly.

What makes INP particularly tricky is that it captures the worst interaction during a visit, not the average.

Practical mitigations for INP:

Use the Chrome DevTools Performance panel to record a page interaction and identify which tasks are blocking the main thread at that moment.
Break up any JavaScript function that takes longer than 50 ms into smaller chunks, yielding between them.
Lazy-initialise heavy third-party widgets so they do not compete with user interactions during the critical first few seconds.
Apply interaction-based loading for scripts that are only needed after a specific user action (a chat widget that only loads when the user clicks the chat button, for example).
Audit your tag manager. Remove tags that are no longer in active use.

Pro Tip: The web-vitals JS library can log the specific interaction that caused your worst INP score, including the element the user interacted with and the delay breakdown. This is far more useful than a single aggregate score — it tells you exactly which interaction to fix.

Do core web vitals still matter for search rankings?

Yes, though not in the way many people assume. Core Web Vitals are part of Google’s page experience signal, and they typically act as a tiebreaker between pages that are otherwise equally relevant. If your content is significantly better than a competitor’s, a poor CWV score is unlikely to cost you the ranking. But when relevance is close — which it often is for competitive local and commercial queries — page experience can be the deciding factor.

The indirect benefits are arguably more important than the direct ranking effect. Pages that load quickly and respond to interactions reliably tend to have lower bounce rates and longer dwell times, both of which reflect genuine user satisfaction. Faster sites also convert better, which is the commercial case for CWV work that goes beyond rankings entirely.

How to balance CWV work against other SEO priorities:

Fix Poor ratings on high-traffic pages first — these are the ones most likely to be costing you rankings and conversions.
Do not sacrifice content quality or link building to chase a perfect Lighthouse score. A 90 in PageSpeed Insights with excellent content beats a 100 with thin content every time.
Treat CWV as ongoing maintenance, not a one-time project. A new plugin, a new marketing tag, or a new page template can introduce regressions at any point.
Use keyword optimisation and site architecture as the primary SEO lever; CWV is the performance layer that supports it.

How to monitor core web vitals continuously

Fixing your metrics once is the easy part. Keeping them fixed after every deployment, plugin update, and new marketing tag is where most sites fall down.

A practical monitoring cadence:

Daily — set up alerts (via the web-vitals JS library or a monitoring tool) for severe regressions. A sudden spike in INP after a deployment should trigger an immediate investigation.
Weekly — review your RUM dashboard for trends. Are scores drifting? Did a new third-party script appear?
Monthly — check Search Console and CrUX for ranking-relevant changes. Remember the 28-day rolling window: a fix you deployed three weeks ago should now be visible in field data.

A release checklist to run before and after every significant deployment:

Run a Lighthouse audit on the key templates and compare against the baseline.
Verify that critical resource preloads (especially the LCP image) are still present in the HTML.
Check that no new layout shifts have been introduced by inspecting the CLS section in Lighthouse.
Confirm that no new render-blocking scripts have been added without defer or async.
If RUM is set up, monitor INP and LCP for 24–48 hours after the deployment before marking the release as stable.

The 28-day CrUX lag is a genuine operational challenge. RUM via the web-vitals JS library is the only way to get immediate feedback on whether a fix has worked. Do not wait for Search Console to tell you — it will, eventually, but you need to know now.

Authoritative resources for deeper reading

These are the sources worth bookmarking, each suited to a different need.

Google Search Central — Core Web Vitals — the authoritative reference for how CWV affects search. Start here if you need to explain the ranking connection to a client or stakeholder.
Web — Google’s own technical documentation covering metric definitions, lifecycle, and tool support. The best single reference for developers.
Web — explains the methodology behind the Good/Poor boundaries and the 75th-percentile rule. Useful when you need to understand why the thresholds are set where they are.
Search Console Core Web Vitals report help — step-by-step guidance on reading and acting on the Search Console report.
Core Web Vitals for WordPress — Optimisation Guide — the most practical WordPress-specific guide available, covering hosting, page builders, and plugin bloat.
How to pass Core Web Vitals: step by step — a workflow-focused guide for teams that want a repeatable audit and fix process.
Web — hands-on debugging guides for each metric, including the web-vitals JS library reference.
Measuring website success: KPIs, tools, and pro tips — useful for setting up RUM dashboards and connecting performance data to business KPIs.

Our take on core web vitals for small businesses

We have worked with enough small business sites to know that the gap between a passing and a failing CWV score is rarely a fundamental design problem. It is almost always a combination of the same three things: a hosting plan that was never meant to handle real traffic, images that were uploaded straight from a camera roll, and a tag manager that has accumulated three years of scripts nobody remembers adding.

The good news is that those three things are fixable without rebuilding the site. A hosting upgrade, a proper image workflow, and a tag audit will move most small business sites from Poor to Good on LCP and CLS without touching the design. INP is the one that sometimes requires deeper work — particularly on WordPress sites with heavy page builders — but even there, deferring non-critical scripts and lazy-loading third-party widgets gets you most of the way there.

What we have found is that the sites which maintain good scores long-term are the ones that treat CWV as part of their release process, not a one-off project. A quick Lighthouse check before every significant update, a monthly glance at Search Console, and a clear rule about adding new third-party scripts — that is genuinely all it takes to stay in the green. The real-world results come from consistency, not from chasing a perfect score on a single audit day.

TTOY Digital’s performance audit and remediation services

If you would rather hand the diagnosis and fixing to someone who does this every day, TTOY Digital offers performance audits and remediation for small business websites across the UK. We review your hosting setup, identify the specific elements dragging down your LCP and INP scores, optimise your images and scripts, and set up monitoring so you know immediately if a future deployment causes a regression. For WordPress sites, we cover the full stack: hosting review, plugin audit, caching configuration, and image pipeline.

The practical next step is a performance audit on your top five pages. We will tell you exactly what is failing, why, and what it will take to fix it. See our full services or get in touch directly to request your audit.

Sources

FAQ

What are Core Web Vitals?

Core Web Vitals are three field metrics Google uses to measure real-user page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Good thresholds are LCP ≤ 2,500 ms, INP ≤ 200 ms, and CLS ≤ 0.1, assessed at the 75th percentile of real visits.

Are Core Web Vitals still relevant in 2026?

Yes. They remain part of Google’s page experience signal and act as a tiebreaker between similarly relevant pages. Beyond rankings, faster and more stable pages consistently produce lower bounce rates and better conversion rates.

Is Core Web Vitals a ranking factor?

Core Web Vitals are a confirmed ranking signal, but they typically function as a tiebreaker rather than a primary ranking driver. Strong, relevant content and authoritative links still outweigh performance scores for most queries.

How do you pass the Core Web Vitals assessment?

Start by checking the Search Console Core Web Vitals report to identify failing URL groups and metrics. Fix TTFB and hosting first, then optimise your LCP element (preload, correct format, no lazy-loading), address INP by deferring non-critical scripts, and eliminate CLS by setting explicit image dimensions. Verify improvements with the web-vitals JS library rather than waiting for the 28-day CrUX window to update.

How do Core Web Vitals affect WordPress sites specifically?

WordPress sites commonly fail LCP due to slow shared hosting, page builder overhead, plugin bloat, and unoptimised images. Upgrading to managed hosting with server-level caching is usually the highest-impact single change, often cutting TTFB dramatically before any code changes are needed.