SEO

Fix Core Web Vitals Errors in 28 Days: Field First for UK Sites

Fix core web vitals errors on UK sites with a field first workflow. Apply code level quick wins, validate in CrUX and Search Console, and see results in...

Julia ParadyszDirector, AMW Media

Published 1 September 202615 min read

SEO

Core Web Vitals errors hurt your search rankings and your conversion rate, full stop. So don’t leave them unattended. The fastest first move is opening the Core Web Vitals report in Search Console and PageSpeed Insights, spotting which metric is failing (it’s usually LCP), and finding the specific element causing it. Fix that, then give it 28 days for the field data to catch up and confirm you’re actually done.

TL;DR:

Fixing LCP should prioritise improving server response times and optimising hero images for WebP or AVIF formats.

Address long JavaScript tasks and defer third-party scripts to improve INP responsiveness across all device types.

Reserve space with image dimensions and CSS aspect ratios to prevent layout shifts and reduce CLS instantly.

Validation requires waiting up to 28 days for field data to reflect improvements and monitoring for regressions over time.

Target fixes based on traffic volume and site templates, focusing first on the worst-rated pages with a structured, one-change-at-a-time approach.

What’s actually causing your core web vitals errors?

Before you touch a line of code, you need to know exactly which pages are struggling and why. Guessing wastes time, and half the “fixes” people apply target the wrong metric entirely.

Start in Search Console’s Core Web Vitals report. It groups your URLs by status, either Poor, Needs improvement, or Good, based on real visitor data from the Chrome User Experience Report (CrUX). This is field data, meaning it reflects what genuine visitors on genuine devices experienced over the past 28 days. It’s the data Google actually uses for ranking purposes, so treat it as the scoreboard that matters most.

PageSpeed Insights gives you something different: lab data, generated from a single simulated test run under controlled conditions. Lab data is brilliant for debugging because it’s reproducible and gives you a waterfall you can dig through. But it won’t always match what real users see, especially if your traffic comes from a mix of fast fibre connections and patchy mobile networks. Google itself makes this field-versus-lab distinction central to how PageSpeed Insights works: lab data tells you why something is slow, field data tells you whether it matters.

Statistic callout: the passing bar. Google marks an origin as passing Core Web Vitals when the 75th percentile of LCP, INP, and CLS all land in the “Good” range, LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under. That 75th-percentile rule matters because it means one in four of your visitors could still be having a rough time even when you’re technically “passing.”

If CrUX shows insufficient data for a page (common on lower-traffic sites), fall back to origin-level aggregates or run synthetic tests to reproduce the likely issue. You won’t get a perfect field-data match, but you’ll get a reasonable proxy.

Before you start debugging anything, write down:

The exact URL and, if it’s a template issue, which other URLs share that template
Device type (mobile skews worse almost universally)
The specific LCP element PageSpeed Insights flags
Network throttling profile used in any lab test
Time window of the data you’re looking at

Common causes and targeted fixes by metric

Each Core Web Vital fails for different reasons, and the fix for one metric can occasionally make another worse if you’re not careful. Here’s what tends to go wrong and what actually shifts the numbers. Our SEO agency Banbury page shows how a small town with a large catchment changes the keyword plan.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the biggest visible element, usually a hero image, banner, or heading, to render. Slow LCP is consistently the most common Core Web Vitals failure, and it’s frequently the one dragging an otherwise decent site into “Needs improvement” territory, according to practitioner data on typical root causes.

The usual suspects:

Slow Time to First Byte (TTFB). If your server takes too long to respond, everything downstream is delayed before the browser even starts rendering.
Unoptimised hero images. An excessively large PNG image instead of a properly compressed WebP file is one of the most common issues we see.
Render-blocking CSS and JavaScript. Stylesheets and scripts sitting in the <head> without async or defer block the browser from painting anything.
Web fonts loading late. If your LCP element is text using a custom font, the browser might wait for that font file before painting.

Fixes, in rough order of impact:

Improve TTFB first. Better hosting, a properly configured CDN, and server-side caching often shave hundreds of milliseconds off before you touch the front end at all.
Preload the LCP image. Add a <link rel=”preload”> tag for your hero image and mark it with fetchpriority=”high”, and never lazy-load it. This single change is one of the highest-impact quick wins available, sometimes worth hundreds of milliseconds on its own.
Inline critical CSS. Get the styles needed for above-the-fold content into the HTML directly, and defer everything else.
Convert and compress images. WebP or AVIF, served at the size they’re actually displayed, not the size your camera produced.

Interaction to Next Paint (INP)

INP measures how responsive your page feels when someone actually clicks, taps, or types. Unlike its predecessor (First Input Delay), INP looks at the slowest interaction across the whole visit, not just the first one, which is why sites that felt “fine” under the old metric sometimes fail INP badly.

The main culprit is long tasks, chunks of JavaScript execution that block the browser’s main thread for more than 50 milliseconds. Open Chrome DevTools, run a Performance trace, interact with the page the way a real user would, and look for the red-flagged blocks in the flame chart. Heavy third-party scripts (chat widgets, ad tech, analytics tags firing synchronously) are frequent offenders here, alongside bloated JavaScript bundles and expensive hydration in single-page apps.

Fixes that work:

Break long tasks into smaller chunks. Where the browser supports it, scheduler.yield() lets you hand control back to the main thread between chunks of work rather than hogging it in one go, a technique explored in detail by DebugBear’s guide to optimising Core Web Vitals.
Defer third-party scripts until after first interaction, or load them during idle time using requestIdleCallback.
Split large JavaScript bundles so the browser isn’t parsing and executing megabytes of code it doesn’t need yet.
Optimise event handlers so click and input listeners don’t trigger expensive re-renders or layout recalculations.

Cumulative Layout Shift (CLS)

CLS tracks how much visible content jumps around unexpectedly while a page loads. It’s worth stressing “unexpectedly” here: a layout shift triggered directly by a user action, expanding an accordion, say, doesn’t count against you. It’s the shifts nobody asked for that matter, as Google’s own guidance on common Core Web Vitals problems makes clear.

Missing image and video dimensions are the classic cause, but they’re far from the only one. Dynamically injected content, a cookie banner sliding in, a “recommended articles” widget loading late, an embedded tweet resolving its final height, shoves everything below it down the page. Web fonts cause the same problem when a fallback font renders first and then swaps to a custom typeface with different character widths, a phenomenon known as flash of unstyled text.

Fixes:

Add explicit width and height attributes, or use CSS aspect-ratio, on every image and video, so the browser reserves space before the file loads.
Reserve space for dynamic content in advance. If you know an ad slot or banner is coming, give it a minimum height with CSS rather than letting it appear and push everything down.
Use a sensible font-display strategy. font-display: optional or careful use of font-display: swap alongside font preloading reduces the visual jump when custom fonts land.

Pro Tip: Reserving layout space with aspect-ratio is usually the single fastest CLS fix available. It typically takes minutes per component and often drops your CLS score to “Good” without touching a single other metric.

A repeatable workflow for fixing and validating changes

Random fixes applied in a panic rarely stick. A repeatable sequence does.

Prioritise by severity, then by reach. Fix everything labelled “Poor” before touching “Needs improvement”. Within that, tackle the template affecting the most URLs or the highest-traffic pages first, not whichever page happens to be open in your browser.

Test in the lab properly. Document your device class (mobile mid-tier is the honest baseline for most audiences), your throttling profile, and whether you’re testing a cold load or a repeat view with cached assets. A change that looks brilliant on a fast laptop with a warm cache can still be dreadful for someone on a three-year-old Android phone.

Change one variable at a time. If you preload the LCP image and defer three scripts in the same deploy, and INP suddenly improves, you won’t know which change did it, and you might have accidentally made something else worse. Use release markers so you can line up deploy timestamps against monitoring data afterwards.

Start validation in Search Console. Once your fix is live, click “Start tracking” on the relevant URL group. That kicks off the 28-day monitoring window Search Console uses before it will mark the group as Passed, drawing on the same CrUX field data that decides your ranking treatment. Field improvements can lag behind your deploy by a couple of weeks, so don’t panic if nothing moves on day three.

Keep a rollback plan ready before you ship a performance fix, not after something breaks
Watch your conversion funnels during the validation window, not just the CWV numbers
Re-run your lab trace immediately post-deploy to confirm the fix behaves as expected before waiting on field data
Note the exact deploy timestamp against your monitoring dashboard so cause and effect stay traceable

Stage	What you do	What confirms success
Prioritise	Rank Poor-labelled URL groups by traffic and template reach	A clear, ranked fix list
Fix	Apply one targeted change per deploy	Lab trace shows the expected metric improvement
Validate	Click Start tracking in Search Console	Group status moves from Poor towards Good over 28 days
Monitor	Watch RUM and CrUX for regressions	Stable or improving P75 scores, no new alerts

Keeping an eye on things after you’ve fixed them

Fixing your Core Web Vitals errors once is easy compared to keeping them fixed. Sites regress constantly, a new marketing script gets added, a designer swaps in an unoptimised image, a third-party widget updates and suddenly ships more JavaScript.

Build monitoring from four angles: Search Console for the official ranking signal, CrUX for raw field aggregates, Real User Monitoring (RUM) for near-real-time visibility into what’s happening right now, and synthetic/lab tests for controlled reproduction when something looks off. DebugBear’s guidance on measuring Core Web Vitals makes the case plainly: field data tells you the truth, lab data helps you understand why.

Set alerts on percentile shifts (P75 crossing from Good into Needs improvement), never on raw averages, because averages hide the worst 25% of experiences entirely
A 10% degradation at P75 is a sensible trigger point for most teams before it becomes a full-blown regression
Segment alerts by device type, page template, and traffic source, since a mobile-only regression can hide completely in blended reporting
Run automated checks weekly at minimum, and treat any major deploy as a reason for an immediate manual spot check

Improvements can take two to four weeks to fully register in CrUX, so don’t judge a fix by day-two data alone. Set your monitoring cadence with that lag in mind rather than checking obsessively and drawing the wrong conclusions from noise.

How AMW Media handles core web vitals problems for clients

Fixing Core Web Vitals errors properly usually needs both a developer’s eye and someone who understands what Google actually rewards, which is exactly the overlap AMW Media works in. Our web design and development team runs performance audits alongside broader SEO work, so fixes get made with rankings and real user experience both in mind, not just a Lighthouse score.

A typical engagement runs in four stages:

A full audit against Search Console and PageSpeed Insights to map exactly which pages and templates are failing
Quick wins applied first (image preloading, dimension fixes, script deferral) for fast visible gains
Deeper engineering work where TTFB, bundle size, or third-party scripts need proper restructuring
Ongoing monitoring so a fix made in March doesn’t quietly unravel by September

This piece was put together with input from Amir, whose background in front-end performance work shapes the fix-first approach running through it.

Where to read more

Google’s own PageSpeed Insights documentation and the Search Console Core Web Vitals help page are the two canonical references, worth bookmarking before any other guide. For root-cause detail, web.dev’s rundown of common Core Web Vitals problems is the clearest breakdown of layout shift triggers specifically. If you want a fuller technical SEO angle on how performance fixes fit into a broader audit, this guide to technical SEO audits is a solid companion read, and our own website optimisation checklist covers the wider performance picture beyond just CWV.

Why the standard core web vitals advice misses the point

Most advice on this topic treats Core Web Vitals as a checklist problem: add some dimensions, preload an image, tick three boxes, done. That’s backwards. The metrics exist to approximate something Google can’t measure directly, whether a real visitor had a smooth experience, and chasing the number without understanding the cause behind it produces fragile fixes that regress the moment someone touches the codebase again.

The conventional wisdom also underrates TTFB. Everyone obsesses over image compression and lazy-loading while server response time quietly caps how fast LCP can ever be, no matter what you do to the image itself. Fix hosting and caching before you fiddle with WebP conversion.

If you take one thing from this, prioritise ruthlessly: fix whatever’s labelled Poor first, fix LCP before INP or CLS in most cases, and always validate against field data rather than trusting a single lab score. Everything else is detail work layered on top of that order.

Amir

Get your core web vitals errors fixed properly

Plenty of guides will tell you to install a plugin and hope for the best. AMW Media is the alternative to that guesswork for site owners who need someone who actually reads the trace, not just runs a scanner and hands back a PDF. We diagnose the specific element or script causing your LCP, INP, or CLS problem, fix it at the code level, and stay on the monitoring afterwards so it doesn’t quietly break again in six months.

If your site’s already failing in Search Console, that’s the moment to act, not after a rankings dip forces the issue. Our web design and development team handles the technical remediation, and our SEO services make sure the performance gains actually translate into visibility and conversions, not just a tidier Lighthouse score. Get in touch for an audit and we’ll tell you which pages need attention first and what it’ll take to fix them.

Sources

FAQ

How do I fix Core Web Vitals issues?

Start with Search Console’s Core Web Vitals report to find which metric and pages are failing, apply the targeted fix for that metric (preload the LCP image, defer scripts for INP, add dimensions for CLS), then click “Start tracking” to validate over the following 28 days.

What are the limitations of Core Web Vitals?

They measure loading, responsiveness, and visual stability well, but say nothing about content quality, accessibility, or whether a page actually answers the user’s query, and low-traffic pages may lack enough field data to be scored at all.

What counts as a good Core Web Vitals score?

Google defines “Good” as LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under, measured at the 75th percentile of real visitor experiences.

How do I pass the Core Web Vitals assessment?

You need the 75th percentile of all three metrics in the “Good” range simultaneously across your tracked URL group, confirmed through 28 days of field data after Search Console starts monitoring your fix.

Do Core Web Vitals errors really affect SEO rankings?

Yes, Core Web Vitals are a confirmed ranking factor, and poor scores are also strongly linked to higher bounce rates and lower conversion, since slow or jumpy pages frustrate real visitors regardless of how they rank.

Fix Core Web Vitals Errors in 28 Days: Field First for UK Sites

What’s actually causing your core web vitals errors?