Core Web Vitals Optimisation Service

Description

Service Core Web Vitals and page-speed optimisation

Core Web Vitals are three measurements Google takes from real Chrome users: loading (LCP), responsiveness (INP) and visual stability (CLS). WavX measures your pages with field data first, traces each failing metric to its cause in the code, hosting or third-party scripts, fixes it, and reports the before and after figures. Good scores are not a promise of rankings.

Discuss your SEO/GEO/AEO strategy Last updated 2 October 2026

The three metrics and their thresholds

Core Web Vitals are the three measurements Google uses to describe how a page feels to a real visitor. The set and the thresholds below are from web.dev and Google's documentation as of October 2026.

Metric

What it measures

Good

Needs improvement

Poor

Largest Contentful Paint (LCP)

Loading: when the largest image, text block or video in the viewport is rendered

2.5 s or less

Over 2.5 s, up to 4 s

Over 4 s

Interaction to Next Paint (INP)

Responsiveness: the delay between a click, tap or key press and the next frame the browser paints

200 ms or less

Over 200 ms, up to 500 ms

Over 500 ms

Cumulative Layout Shift (CLS)

Visual stability: how much content moves unexpectedly while the page is open

0.1 or less

Over 0.1, up to 0.25

Over 0.25

Two details matter when reading any report:

The figure is the 75th percentile. A page passes when three out of four visits meet the threshold, measured separately for mobile and desktop. An average hides the slow visits; this does not.

INP replaced First Input Delay (FID) in March 2024. A report or guide that still lists FID predates the change.

Field data and lab data

Most confusion about site speed comes from mixing two kinds of measurement.

Field data

Lab data

Where it comes from

Real visits by Chrome users, collected in the Chrome User Experience Report (CrUX)

One test run by Lighthouse on a simulated device and connection

Period

A trailing 28 days

The moment of the test

What it is used for

Google's Core Web Vitals assessment; the Core Web Vitals report in Search Console

Finding causes and testing a fix before release

Can it measure INP?

Yes

No. There is no user to interact, so Total Blocking Time is used as a stand-in

Limits

A page or site needs enough visitors to be reported. Chrome on iOS and other browsers do not contribute

One device, one network, one location. It cannot represent your actual visitors

PageSpeed Insights shows both on one screen: field data at the top, the Lighthouse lab run below it. The 0 to 100 performance score belongs to the lab run. It is not a Core Web Vital, and a page can score poorly in the lab while passing in the field, or the reverse.

web.dev's guidance is direct: field data is what you should use to prioritise, and lab data is for diagnosis. WavX follows that order.

When a page has too few visitors for CrUX, PageSpeed Insights falls back to data for the whole site, and Search Console may show no data at all. In that case WavX adds real-user measurement to the site itself, so the figures come from your own visitors instead of from a lab estimate.

How WavX runs the work

Measure. Field data for the site and for each main page template (home, listing, detail, article, checkout), on mobile and desktop. Lab runs of the same templates, to see the loading sequence.

Diagnose. Each failing metric is traced to a cause, using the breakdowns in the next section.

Fix. Changes are made in the code, the server configuration or the tag setup, on a staging copy first.

Verify in the lab. The same lab runs are repeated, so each change has a before and an after.

Verify in the field. Field data is read again once the 28-day window has moved past the release date.

Guard. A performance check is added to the release process where the stack allows it, so a later change that undoes the gain is caught before it ships.

Where the time goes

LCP

web.dev splits LCP into four parts. Each has different fixes, which is why "compress the images" works on some sites and does nothing on others.

Part

What it is

Typical fixes

Time to first byte

How long the server takes to start sending the HTML

Caching, a CDN, faster server rendering, fewer redirects

Resource load delay

The gap before the browser starts fetching the LCP image

Put the image in the HTML where the browser can find it early, mark it fetchpriority="high" , never lazy-load it

Resource load duration

How long the image itself takes to download

Correctly sized, compressed images in a modern format, served from a CDN

Element render delay

The gap between the download finishing and the image appearing

Remove render-blocking CSS and scripts; render on the server instead of in the browser

INP

An interaction has three parts: input delay before the handler starts, processing time while it runs, and presentation delay until the next frame. Slow INP almost always traces back to JavaScript holding the main thread. The usual fixes are to break up long tasks, load less script, defer what is not needed for the first interaction, and remove third-party tags nobody is using.

CLS

The causes web.dev lists are images and videos without dimensions, fonts that render at a different size from their fallback, ads and widgets that resize themselves, and content inserted above what the visitor is already reading. The fixes are to reserve the space in advance.

What you receive

A baseline report : field and lab figures per template, per device, dated.

A cause list : each failing metric, the part of it that is slow, and the specific file, script or setting responsible.

The changes , delivered as code in your repository or as configuration in your platform.

An after report : the same lab measurements, then a field reading once the 28-day window has passed.

A list of what was left , with the reason. Usually this is a third-party script the business has chosen to keep, with its cost stated in milliseconds so the decision is an informed one.

WavX does not publish a price for this work. It is quoted after the measurement stage, when the causes are known.

What it cannot promise

Rankings. Google states that Core Web Vitals are used by its ranking systems. It also states that good results in the Core Web Vitals report do not mean pages will rank at the top, and that it tries to show the most relevant content even when the page experience is sub-par. Speed is one signal among many.

A particular field result. Field data reflects your visitors' phones and networks. WavX controls what the site sends, not the device that receives it.

Instant confirmation. The field figures move over 28 days. A Search Console fix validation for this report also runs for 28 days.

Gains the platform does not allow. On a hosted store the platform's servers and checkout are outside anyone's reach but the platform's. For Shopify stores, see Shopify speed optimisation .

A fix that survives new tags. Every chat widget, pixel and A/B testing script added later costs something. The guard in step 6 exists for this reason.

When you should not pay for this

If Search Console's Core Web Vitals report already shows your URLs as good on mobile, there is nothing here to buy. Spend the money on content or on a technical audit instead.

If the site is slow for ordinary reasons, such as oversized images, too many plugins or the cheapest hosting plan, you can fix a good part of it yourself. The guides on how to make a website load faster and why a website is slow cover those steps in plain terms.

If the site is built with a heavy page builder and fails on every template, optimisation may cost more than it returns. Rebuilding the front end on a framework that renders on the server, such as Next.js , can be the cheaper route in the long run. WavX will say so if the measurements point that way.

Frequently asked questions

What are the Core Web Vitals in 2026?

Three metrics, as of October 2026: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. INP replaced First Input Delay in March 2024, so any guide or report that still lists FID is out of date.

My PageSpeed score is low but the site feels fast. Which is right?

They measure different things. The 0 to 100 score is a lab result from one simulated device and connection. Core Web Vitals are assessed on field data from real visitors over the previous 28 days. Google's own guidance is to use field data to decide priorities and lab data to find and test fixes.

Will passing Core Web Vitals improve our Google rankings?

We cannot promise that. Google says Core Web Vitals are used by its ranking systems, and also that good results in the report do not mean pages will rank at the top, because relevance comes first. The dependable gain is for visitors: pages that load, respond and hold still.

How long before the improvement shows in Search Console?

Lab measurements change as soon as a fix is deployed. Field data is collected over a trailing 28-day period, so the Core Web Vitals report and PageSpeed Insights catch up gradually over the following four weeks, provided the page has enough visitors to be reported at all.

How much does speed optimisation cost?

We do not publish a price for it. The work is quoted after the measurement stage, because the cost depends on whether the causes are a few images and scripts or the way the site is built.

Do you work on Shopify and WordPress sites, or only custom builds?

All three. The method is the same, but what can be changed differs. A custom Next.js site can be changed at any level. On a hosted platform, the theme, the apps and the images are in our hands and the platform's servers are not.

Sources

web.dev: Web Vitals · read 2 October 2026

Google Search Central: Understanding Core Web Vitals and Google search results · read 2 October 2026

Google Search Central: Understanding page experience in Google Search results · read 2 October 2026

web.dev: Interaction to Next Paint (INP) · read 2 October 2026

web.dev blog: INP launch as a stable Core Web Vital (12 March 2024) · read 2 October 2026

web.dev: Largest Contentful Paint (LCP) · read 2 October 2026

web.dev: Optimize Largest Contentful Paint · read 2 October 2026

web.dev: Cumulative Layout Shift (CLS) · read 2 October 2026

web.dev: Why lab and field data can be different · read 2 October 2026

Chrome for Developers: CrUX methodology · read 2 October 2026

Google for Developers: About PageSpeed Insights · read 2 October 2026

Search Console Help: Core Web Vitals report · read 2 October 2026

Related

Shopify speed optimisation

Technical SEO audit

Next.js development

Why is my website slow?

SEO and GEO services

Build your own software — your way, your pricing.

WavX Solutions is here to create your own software in a fully custom way, built exactly how you work — with a pricing model that fits your business. Connect now and let's build it.

Contact Now helpwavx@gmail.com