Most site speed work goes into raising a score from a testing tool. What matters is what real visitors on real phones actually experience, which is a different number, measured differently, and usually fixable with fewer changes than a tool’s recommendation list suggests.
Fix causes, not scores. A list of forty recommendations from a testing tool is how speed budgets get spent without anything feeling faster.
What Core Web Vitals are
Three measurements of how a page feels to use. Largest Contentful Paint is how long until the main content appears. Interaction to Next Paint is how quickly the page responds when someone taps or clicks it, and it replaced First Input Delay in March 2024. Cumulative Layout Shift is how much the page jumps around while it loads.
They’re measured from real visitors rather than from a test, which is why a perfect lab score and poor field data happen together all the time.
Who it’s for
This suits sites that feel slow where it counts:
- shops where the phone experience is noticeably worse than desktop
- sites flagged in Search Console’s Core Web Vitals report
- anyone who has had a developer “optimise” the site with no measurable change
- businesses whose bounce rate on mobile is much worse than desktop
The problems it usually solves
Lab scores that don’t match reality. A testing tool runs one simulated load on one connection. Field data is what your actual visitors experienced on their own devices. When the two disagree, the field data is the one that counts.
Enormous images. The most common single cause on small business sites, and the easiest to fix. A hero image several times larger than the space it occupies delays the thing every visitor is waiting for.
Lazy loading applied to the hero. A frequent and counterproductive fix, because the first thing on screen is now loading last.
Layout shift from missing dimensions. Images without width and height, or fonts and banners loading late, so the text moves as someone starts reading. It’s measurable, it’s irritating and it’s usually a template fix.
Scripts nobody can account for. Analytics, chat, review widgets, heatmaps, three tag managers. Each was added for a reason and nobody ever removes them.
INP problems from heavy JavaScript. Where the page looks ready and doesn’t respond for a moment when tapped, which is the newest of the three and the least worked on.
What’s included
- Field data review from Search Console and any real-user data you have, by template rather than by page
- Lab testing to find causes, used as a diagnostic rather than a target
- A prioritised cause list, ordered by what’s costing real visitors the most
- Image and media fixes, usually the largest single win
- Script and third-party audit, including what can be removed entirely
- Layout shift fixes, mostly at template level
- INP investigation where interactivity is the failing metric
- Implementation or a developer-ready brief, plus follow-up measurement
The approach
Fix causes, not scores. A list of forty recommendations from a testing tool includes plenty of things that are technically true and worth nothing, and working through them in order is how speed projects consume budget without changing what visitors feel.
Measurement by template also matters more than by page. Fixing one product page tells you nothing. Fixing the product template fixes every product.
What you get
- A diagnosis by template, with the actual causes named
- The fixes, implemented or specified for your developer
- Before and after field data, once enough has been collected
- A list of what deliberately wasn’t done, and why
Limitations
Field data takes time to update, so improvements don’t appear in Search Console immediately even when visitors feel them straight away.
Some causes are also platform limits. On a hosted platform there’s a floor below which you can’t go without replatforming, and where that’s the case I’d rather say so than sell months of work to shave a fraction off.
What this won’t solve
Speed isn’t a substitute for relevance. A very fast page that doesn’t answer the question won’t rank, and treating Core Web Vitals as a primary ranking lever overstates what they do. They matter for visitors first.
Talk to the person doing the work
There is no account manager here and no team to be handed to. If you get in touch, it is me who reads it, me who looks at your site, and me who does the work if we go ahead.
Get in touch, or start with a free assessment.
Engagement and price
There are no list prices here, and that is deliberate. What a piece of work costs depends on the state of the site, how much of it there is and what you actually need, none of which I know before looking at it.
So it starts with a free analysis. I look at your site, your Search Console and who you are really competing with, then come back with what I would do first and what it would cost to do. No obligation attached, and if the honest answer is that you do not need me yet, I will say so.
How the work gets done
Field data comes through the crawl and data integrations, causes are diagnosed through the technical SEO checks and page analysis, and image work runs through the image audit. This service sits under web development and pairs with image SEO.
FAQ
Do Core Web Vitals affect rankings?
They’re part of Google’s page experience signals, so they have some influence, and it’s smaller than most articles about them suggest. Relevance and content quality matter considerably more. The stronger argument for fixing them is that visitors leave slow, unstable pages.
Why does my site score well in tests but poorly in Search Console?
Because they measure different things. A test tool runs one simulated load on one connection. Search Console reports what real visitors experienced on their own devices and networks. When they disagree, the field data is the one that reflects your actual customers.
What is INP and why does it matter?
Interaction to Next Paint measures how quickly a page responds when someone taps or clicks. It replaced First Input Delay in March 2024 and is stricter, so plenty of sites that passed before now don’t. It usually points at heavy JavaScript.
What’s the quickest speed improvement?
On most small business sites, resizing and compressing the largest images on the pages people land on. A handful of files usually account for most of the page weight, so a few fixes do more than working through a long list of smaller recommendations.
Find out what’s actually slowing you down
Get in touch, or start with a free assessment, which includes a speed check.