Search Engine Optimisation
Core Web Vitals for SEO
The diagnosis and the ranking argument. The engineering work itself sits under website speed optimisation, and the two are usually bought together.
Core Web Vitals measure loading, interactivity and visual stability — LCP, INP and CLS. The Nexclick diagnoses them from real user field data rather than a single lab test, identifies what is actually causing each failure, and hands your developers a fix list they can act on.
Is this you?
What usually prompts the call
- Search Console reports URLs as "Needs improvement" or "Poor" and nobody knows which change caused it.
- PageSpeed Insights gives you 95 in the lab and your field data still fails.
- The site feels fast on your desktop and your customers are mostly on mid-range Android phones.
- You fixed something two weeks ago and the report has not moved, so it looks like nothing worked.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Field data analysis, not lab scores
- CrUX data from real Chrome users on real connections, segmented by device. Lab scores and field data routinely disagree, and Google ranks on the field data.
- LCP element identification per template
- Which element is actually the largest contentful paint on each template, and why it is late — usually a hero image without priority, a web font, or a render-blocking script.
- INP diagnosis
- Interaction to Next Paint replaced First Input Delay in 2024 and is considerably harder to pass. Long tasks are traced to the specific script blocking the main thread.
- CLS source tracing
- Images without dimensions, injected banners, late-loading fonts and consent dialogues. Cumulative Layout Shift is the easiest of the three to fix and the most commonly ignored.
- Third-party script accounting
- Every tag, chat widget and analytics script measured for what it costs. Tag managers accumulate scripts nobody has audited in years, and the cost is rarely attributed.
- A prioritised, developer-ready fix list
- Each item names the file, the change and the expected effect. Written to be picked up in a sprint rather than interpreted.
- Verification after deployment
- Re-measured in the lab immediately and in field data at 28 days, because CrUX is a rolling 28-day average and will not show a change sooner.
Comparison
What actually causes each Core Web Vitals failure
The causes we find most often in UK site audits, with the fix and a realistic sense of effort. Work down each metric in order — the top entries account for the majority of failures.
| Metric | Common cause | Fix | Effort |
|---|---|---|---|
| LCP | Hero image not prioritised | Add fetchpriority="high"; remove lazy loading above the fold | Minutes |
| LCP | Image served far larger than displayed | Responsive sizes, AVIF/WebP, correct dimensions | Hours |
| LCP | Render-blocking CSS or JS in the head | Inline critical CSS; defer the rest | Days |
| LCP | Slow server response (TTFB over 600ms) | Caching, CDN, database query review | Days to weeks |
| LCP | Web font blocking text paint | font-display: swap, preload, self-host | Hours |
| INP | Long main-thread tasks from third-party tags | Audit tag manager; defer or remove | Hours |
| INP | Heavy JavaScript hydration on load | Code splitting; reduce client-side work | Weeks |
| INP | Expensive event handlers on scroll or input | Debounce; move work off the main thread | Days |
| CLS | Images without width and height attributes | Add explicit dimensions everywhere | Hours |
| CLS | Cookie banner or promo bar injected late | Reserve the space, or overlay rather than push | Hours |
| CLS | Web font swap changing text metrics | size-adjust and matching fallback metrics | Hours |
| CLS | Ads or embeds with no reserved container | Fixed-height containers before load | Hours |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Measure the real experience
Field data by template and device type, plus Search Console groupings. Establishes which templates actually fail rather than which page you happened to test.
- 02Week 1–2
Trace causes
Performance traces on throttled mid-range mobile hardware. Testing on a fast laptop on office broadband is how sites pass in the lab and fail in the field.
- 03Week 2–5
Specify and implement
Fix list handed over, or implemented by us. Changes go to staging and are measured there before release.
- 04Week 5–9
Wait, then verify
Field data takes 28 days to reflect a change. Anyone reporting a field improvement a week after deployment is reading lab data and calling it something else.
What you get
Reporting and ownership
- A per-template diagnosis, since fixing "the site" is not actionable but fixing the product template is.
- A developer-ready fix list naming the file, the change and the expected effect of each item.
- Before-and-after field data at 28 days, so the result is evidenced rather than asserted.
- A third-party script inventory with the measured cost of each, ready for a business decision.
- A Lighthouse CI configuration so regressions are caught at deployment rather than months later.
Tools and platforms
- Chrome DevTools performance profiler
- PageSpeed Insights & CrUX API
- Google Search Console (Core Web Vitals report)
- WebPageTest
- Lighthouse CI
- Real user monitoring where available
Timeline
How long this actually takes
Diagnosis takes one to two weeks. Fixes take two to five weeks depending on your development resource. Then you wait: Core Web Vitals field data is a rolling 28-day average, so a change deployed today cannot fully show for four weeks, and Search Console lags further behind that. Budget six to ten weeks from start to verified result. On ranking impact, the honest position is that Core Web Vitals are a genuine but weak signal — they rarely outweigh relevance, and a fast irrelevant page still loses. The stronger commercial argument is conversion, where the effect is larger and immediate.
Pricing model
Fixed-price project
Fixed-price diagnosis and fix list. Implementation is quoted separately, or handled under website speed optimisation where the engineering work is substantial.
Questions
Core Web Vitals for SEO questions
Why does PageSpeed Insights give us 95 but Search Console says we fail?
They measure different things. The score at the top of PageSpeed Insights is a lab simulation on synthetic hardware. Search Console reports field data from real Chrome users on real devices and connections — many of them mid-range Android phones on patchy mobile networks. The field data is what counts for ranking.
How much will fixing these improve our rankings?
Usually modestly, and sometimes not visibly at all. Core Web Vitals are a real ranking signal and a weak one — they act as a tie-breaker between comparably relevant pages rather than overriding relevance. The stronger case for doing the work is conversion, where a faster site produces a measurable and immediate difference.
What replaced First Input Delay, and does it matter?
Interaction to Next Paint replaced FID in March 2024, and yes, it matters — it is considerably harder to pass. FID only measured the delay before processing began. INP measures the full interaction through to the next visual update, which exposes heavy JavaScript that FID never caught.
We fixed things weeks ago and the report has not moved. Why?
Because CrUX is a rolling 28-day average, and Search Console adds further lag on top. A fix deployed today begins entering the average tomorrow and is only fully reflected four weeks later. Lab tools will confirm the fix worked immediately; the official report will not.
Do we need to pass on desktop as well as mobile?
Mobile is assessed separately and matters most for the majority of UK businesses, because that is where the traffic and the weaker hardware are. Desktop is assessed too. If you have to choose where to spend, choose mobile — a site that passes on desktop and fails on mobile is failing where the users are.
Can a WordPress site pass Core Web Vitals?
Yes, and plenty do. What causes failures is rarely WordPress itself — it is page builders generating deeply nested markup, twenty plugins each loading their own assets, and unoptimised hosting. A lean theme on decent hosting passes comfortably.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.