CORE WEB VITALS TUNING
Numbers that move, measured on the connection your visitors actually have.
Three numbers decide whether a page feels fast: LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds, at the 75th percentile of real visits. Lab scores in a desktop Lighthouse run are not those numbers. I work from field data where there is enough traffic to have any, and from throttled mobile runs where there is not.
The causes are boring and they repeat. LCP is almost always an unoptimised hero image or a font that blocks the first paint. CLS is an image with no intrinsic size, a late-injected banner, or a web font swapping metrics. INP is a main thread busy hydrating components that never needed to be interactive. So the fixes are boring too: image ladders with correct srcset, preloaded self-hosted fonts, less JavaScript.
On wishmaster.live an image pass took a gallery from 111 MB of originals to about 0.4 MB served, masters untouched, by generating a WebP ladder and letting srcset pick. That is the shape of this work: measure, find the one thing costing seconds, fix it, measure again. You get the before and after numbers, including the ones that did not improve.
WHAT I DO
- Baseline from the Core Web Vitals report in Search Console plus throttled mobile lab runs, recorded and dated before anything changes
- Image pipeline — WebP or AVIF ladder, width-correct srcset and sizes, explicit dimensions, lazy below the fold, preloaded for the LCP element
- Font strategy: self-hosted, subset, preloaded, font-display set, fallback metrics matched so the swap does not shift the layout
- JavaScript reduction — what becomes a server component, what drops its client bundle, and which third-party script is costing you 400ms
- Render-blocking audit: critical CSS inlined where it pays for itself, everything else deferred
- Cache and compression headers checked at the edge rather than assumed, with immutable hashing on static assets
- A before and after table per metric, plus the list of things I chose not to do and the reason
HOW I WORK
- 01
MEASURE
Capture field data and throttled lab runs for the templates that matter, so every later claim has a dated number behind it.
- 02
DIAGNOSE
Identify the actual LCP element, the nodes that shift, and the long tasks blocking input — rather than working down a generic checklist.
- 03
FIX
Change one class of problem at a time, biggest first, re-measuring after each so the cause of every improvement is known.
- 04
VERIFY
Re-run both lab and field measurement, hand over the comparison, and name what is left and what it would cost to chase.
BEST FOR
- Sites failing the Core Web Vitals report in Search Console with enough real traffic for the failure to matter
- Image-heavy portfolios, galleries and catalogues where nearly all the page weight is media
- React or Next.js apps where the first load is slow because almost everything is a client component
NOT THIS
- Not a Lighthouse score service. Chasing 100 on a desktop run while real phone visitors wait four seconds is theatre — I optimise the field metrics instead.
- Not a rewrite. If the site is twelve plugins arguing with each other, I will tell you the ceiling before taking the work rather than bill you for a plateau.
- Not server capacity work. Slow queries, undersized instances and database indexing belong on the Next.js platforms and portals page.
THE PROOF
Published case studies from digital experience work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF DIGITAL EXPERIENCE
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.