Core Web Vitals Remediation

What does Core Web Vitals Remediation fix?

It fixes the three things Google measures from real visitors: how long the main content takes to appear, how quickly the page responds when someone taps or clicks, and how much the layout jumps while it loads. Behind each of those sit a handful of usual causes, and the work is finding which ones apply to your site and removing them at the source.

Images are the most common. Oversized files, no modern format, no dimensions set so the page jumps when they arrive, and a hero image that is not prioritised. Web fonts come next: fonts that block text from showing, or swap in late and shift the layout. Third-party scripts are the quietest problem, because a chat widget, a tag manager, a video embed and an analytics snippet each seem small and together add seconds and block interaction. Layout shift often comes from banners, ads and embeds that push content down after it has loaded. On sites built in the browser, the JavaScript payload itself can be the biggest issue, with the page unable to respond until it has all been downloaded and run.

Each cause is fixed once, at the template that produces it, so a fix to the service page template repairs every service page. That is what makes a fixed price possible and what keeps the work from being a page-by-page slog.

Why field data rather than a lab score?

Because the lab score is a simulation and the field data is your customers. A tool that loads a page once on an emulated phone tells you something, but it does not tell you what happened to the person on a three-year-old handset on a train. Google's ranking signal is built from the field data in the Chrome UX Report, the distribution of what real visitors experienced over the previous 28 days, and the two often disagree. We have seen pages pass every lab test and still fail in the field, and the field result is the one that counts.

So the baseline is field data per template, the diagnosis uses lab tools to isolate the cause, and the verification after release is field data again. The technical SEO guide explains where performance sits alongside crawlability and indexation, and why a fast page that cannot be crawled is still invisible.

What moves the price?

The price is from $1,800 + GST and three things decide the figure.

The platform matters most. A site in a repository we can work in directly allows any fix. A hosted platform may only allow configuration changes and plugin choices, which limits what can be done and how long it takes. We say which situation you are in before quoting.

The number of failing templates matters next. A site with one slow template is diagnosed and fixed once. A site where the home, service, location and blog templates all fail for different reasons is four pieces of diagnostic work.

Whether we implement or your developers do is the third. Where the platform is one we know and you want it done, we implement directly. Where you have a development team, we write each fix with the evidence, the expected impact and an acceptance criterion they can test, and verify each release. Both are available under the broader technical SEO service, and the price reflects which you choose.

How is the work verified?

Every fix is checked twice. The first check is in the lab, immediately, to confirm the cause was removed. The second is against field data after enough real visitors have loaded the changed template, and that is the result that goes in the before-and-after report.

Then the fix is protected. An automated performance check is added to the deployment pipeline, so a future release that reintroduces an unsized image or a heavy script fails before it reaches production. That check ships with the work as standard. On a site kept under the Website Care Plan, it runs on every release we make. On a site your own developers maintain, it is documented and handed over with everything else.

Where does this sit alongside other technical SEO work?

Performance is one layer of technical health, not the whole of it. If an audit shows the site also has blocked AI crawlers, missing structured data and pages that never state their answer, the AI readiness retrofit fixes that layer for a fixed price, and the two projects are often run together. When a site is slow because of how it was built rather than what was added to it, a rebuild with performance and testing built in from day one, the Launch Website Build, is sometimes the better spend, and we will say so rather than remediate what should be replaced.

The changes are yours: made in your repository or CMS, documented and handed over.