Service 04 · Performance
Core Web Vitals Optimization, Engineered From Field Data
We fix LCP, INP and CLS where Google measures them — on real devices, template by template — and keep them fixed with budgets in CI.
A green Lighthouse score doesn’t pass Core Web Vitals; your users’ 75th-percentile field data does. We segment CrUX and real-user data by template and device, trace each failing metric to the asset, script or component responsible, and ship fixes with your developers — then guard them against regression.
what-we-measure.yml
LCP
largest element render time, resource priority, TTFB
INP
long tasks, event handlers, hydration cost
CLS
unreserved space, late fonts, injected UI
FIELD
CrUX p75 by template, device and connection
GUARDRAILS
performance budgets and CI checks on every PR
Sound familiar?
Signs your vitals are holding you back.
Lighthouse scores 90+, yet Search Console still reports “Poor” URLs on mobile.
INP has failed since it replaced FID, and nobody knows which interaction is slow.
Product or category templates fail LCP while the homepage passes comfortably.
Every new marketing tag, chat widget or A/B test quietly makes the site slower.
Layout jumps as banners, fonts and ads load — and users tap the wrong thing.
You fixed performance last year and it has drifted back since.
Field data vs lab scores
Why lab scores pass and real users fail.
Core Web Vitals are assessed on field data: the 75th percentile of real Chrome users’ experiences over a rolling 28-day window, reported in CrUX and Search Console — not a single Lighthouse run.
Lighthouse is a lab test: one simulated device, one network profile, one cold page load and no real interactions. It is invaluable for debugging, but it can’t see the mid-range Android phone on a congested network, the returning visitor whose cache behaves differently, or the tap on “Add to basket” that triggers 400 ms of JavaScript. INP in particular only exists in the field, because it measures the latency of real interactions across the whole visit. Optimising for the lab score often means chasing numbers that never move the assessment that matters.
So we start from field data grouped by page template and device class — because that is how Google groups URLs and how your codebase is organised. A failing product template is one fix, not ten thousand. Where rendering architecture drives the cost, such as heavy hydration on a React or Next.js front end, we bring in our JavaScript SEO work; for large catalogues, the fixes fold into ecommerce technical SEO. And if performance is one symptom among many, a technical SEO audit is the better starting point.
What’s included
From metric to root cause to shipped fix.
Every engagement covers all three vitals and the delivery layers underneath them, scoped to the templates that carry revenue.
Field data by template
CrUX, Search Console and RUM data segmented by template, device and country to find exactly where p75 fails.
LCP: discovery & priority
Good is 2.5 s or less. We fix late-discovered hero images, render-blocking CSS, slow TTFB and missing fetchpriority hints.
INP: main-thread work
Good is 200 ms or less. We profile long tasks, heavy event handlers, hydration cost and scripts competing for the main thread.
CLS: layout stability
Good is 0.1 or less. We reserve space for media, ads and embeds, stabilise web fonts and stop late banners shifting content.
Critical CSS, images & fonts
Inlined critical CSS, responsive AVIF and WebP, correct lazy-loading boundaries, and preloaded, subset web fonts.
Third-party governance
An inventory of tags, chat, testing and consent tools with their real cost — then deferral, facades or removal.
Server, caching & CDN
TTFB by template, full-page and edge caching, cache-hit ratios, compression, HTTP/3 and 103 Early Hints.
WordPress & Elementor
Plugin and asset audits, page-builder DOM and CSS weight, conditional script loading, object caching and hosting fit.
How the engagement works
Measure, fix, then lock it in.
Deliverables
Field vitals baseline by template & device
Root-cause trace for every failing metric
Prioritised fix tickets with expected impact
Performance budgets per template
CI checks and RUM alerting setup
Before / after field validation report
Baseline the field
We pull CrUX, Search Console and any RUM you already collect, then map failing URL groups to templates and device classes so the right thing gets fixed first.
Diagnose the cause
Failures are reproduced in lab conditions that match your p75 users, then traced with performance profiles, Long Animation Frame data and waterfalls to the asset, script or component responsible.
Ship the fixes
Fixes are specified as tickets with expected metric impact, reviewed in pull requests and verified on staging. Quick wins go first; architectural changes are sequenced.
Guard & validate
Performance budgets and CI checks fail a build on regressions, and we validate the improvement in field data across the following 28-day window.
What changes
Vitals stop being a quarterly fire drill. Every template has a budget, regressions are caught in pull requests, and improvements show up where Google actually measures them.
Sample output
Field vitals by template, not one site score.
The baseline we build first: p75 field values per template on mobile, coloured against Google’s thresholds. Every failing cell becomes a ticket.
field-vitals-by-template · crux-p75 · illustrative
TEMPLATE
LCP
INP
CLS
Home
2.1 s
180 ms
0.04
Category
3.4 s
240 ms
0.18
Product
4.6 s
310 ms
0.02
Article
2.3 s
120 ms
0.27
Checkout
2.8 s
560 ms
0.06
mobile · p75 · 28 days · good ≤2.5 s / ≤200 ms / ≤0.1
→ 4 of 5 templates need work
Who it’s for
Who CWV optimization is for.
ECOMMERCE
Stores with heavy templates
Category and product pages weighed down by images, filters, reviews and tags, where speed shows up directly in conversion. See ecommerce technical SEO.
PUBLISHERS
Ad-funded content sites
Publishers balancing ad revenue against CLS and INP, where every slot and script needs a layout and loading strategy.
WORDPRESS
WordPress & Elementor sites
Sites where plugins, page-builder markup and hosting limits have built up weight that a caching plugin alone can’t remove.
Investment
Fixed scope, quoted upfront.
Scope depends on the number of templates, your stack and whether we implement or advise. After a 30-minute scoping call you’ll receive a fixed quote — diagnosis only, or diagnosis plus implementation support.
Related services
Often paired with performance work.
JavaScript SEO
When hydration and client-side rendering drive INP and LCP.
Explore JavaScript SEO →
Ecommerce Technical SEO
When slow category and product templates sit inside a wider catalogue problem.
Explore ecommerce SEO →
Technical SEO Audit
When performance is one symptom of broader crawl and index issues.
Explore the audit →
Do Core Web Vitals affect rankings?
They are part of Google’s page experience signals, used alongside relevance and content quality. Passing them rarely outranks better content, but failing them can cost you in close competitive results — and the same improvements reduce bounce and lift conversion, which is usually the bigger commercial win.
Why does Lighthouse say we’re fast when Search Console says we fail?
Lighthouse is a single simulated lab load on one device profile. Search Console uses CrUX field data: the 75th percentile of real Chrome users over 28 days, across real devices, networks and interactions. Lab tests are for debugging; field data is what gets assessed.
What is INP and why is it hard to fix?
Interaction to Next Paint measures how quickly the page visually responds to clicks, taps and key presses across the whole visit, and reports close to the worst one. It is hard because the cause is usually main-thread contention — hydration, heavy event handlers, third-party scripts — rather than one slow asset. We profile real interactions to find the long tasks behind it.
How long until improvements show in Search Console?
Field data uses a rolling 28-day window, so a fix deployed today is fully reflected after about four weeks, and Search Console validation can take longer. Where RUM or daily CrUX data is available we track the trend so you can see movement well before the report updates.
Can you optimise a WordPress or Elementor site?
Yes. Typical wins are removing unused plugins and assets, loading scripts only where they’re needed, reducing page-builder DOM and CSS weight, fixing image and font delivery, and putting proper page and object caching in front of the site. We work within your theme and hosting rather than forcing a rebuild.
How do you stop performance regressing after the project?
We set budgets per template — for LCP, total JavaScript, image weight and third-party requests — and wire them into CI so pull requests that break them fail. Combined with RUM alerts, regressions are caught within days instead of being discovered months later.
Next step
Pass Core Web Vitals where it counts.
Send your URL and the templates that are failing. You’ll get a scoped proposal with a fixed price within a few days.