01 /Web Development
Core Web Vitals Optimisation
Diagnosing and fixing what makes a site slow for real visitors, then putting a budget in place so it does not drift back. Sites rarely become slow in one commit. They accumulate a tag here and an unoptimised image there until a metric crosses a threshold nobody was watching.
What you get
A diagnosis from field data, not only lab scores
A synthetic score describes one run on one machine. What matters is the experience across your actual visitors, on their devices and connections, which is where the distribution is wider and worse than a lab run suggests.
The specific causes, ranked by impact
Which element is the largest contentful paint, what is blocking it, what is shifting layout and which script is occupying the main thread. Ranked by effect on the metric rather than by how easy each is to fix.
Implemented fixes, not a report
The recommendations get made where the engagement covers implementation, because a prioritised list handed to a busy team is a document that gets read once and then archived.
A performance budget wired into CI
Thresholds that fail a build when a change pushes past them. This is the part that makes the improvement durable, because otherwise the next marketing tag quietly undoes the work.
How it runs
- 01
Measure honestly
Establish the baseline from field data where you have it and controlled lab runs where you do not, on the pages and devices that carry your traffic rather than on the homepage on a laptop.
You provide: Analytics access and a view on which pages matter commercially
We produce: A baseline across the pages that matter
- 02
Find the actual causes
Trace each metric to its source. Most performance advice is generic; the useful version names the specific font, image, third-party script or layout decision that is costing you the number.
We produce: A ranked cause list with expected impact
- 03
Fix and verify
Changes are made and measured one meaningful group at a time, so the improvement is attributable rather than assumed. A batch of twenty changes that moves a metric tells you nothing about which nineteen were unnecessary.
We produce: Implemented changes · Before and after measurements
- 04
Hold the line
A budget in the pipeline with agreed thresholds, so future regressions fail a build rather than surfacing months later as a slow decline nobody can date.
We produce: CI performance budget
Where this stops
- Not a promise of a perfect score. A score of 100 on a synthetic test is achievable and often worthless; the target is the experience of your actual visitors, and sometimes the two disagree.
- Not backend or database performance. We work on what happens between the response leaving your server and the page being usable. If the server takes two seconds to respond, that is a different investigation.
- Not removal of your marketing stack. We will quantify what each third-party script costs you and let you make the trade, but which tags are worth their cost is a commercial decision, not ours.
- Not an SEO engagement. Speed is one input among many, and it will not outweigh thin content or an absent link graph.
Related reading
- Accessibility
The European Accessibility Act and your website: what it actually requires
The Act has applied since June 2025. What it covers, which technical standard sets the bar today, and the accessibility failures no automated checker will ever find for you.
- EU regulation
The Cyber Resilience Act’s first deadline: what changes on 11 September 2026
From 11 September 2026, manufacturers must report an actively exploited vulnerability within 24 hours. Who that binds, what the clock actually demands, and what to have in place before it starts.
FAQ
Core Web Vitals Optimisation questions we hear often
Our Lighthouse score is fine. Why are users complaining?
Because Lighthouse runs once, on one simulated device, usually on a fast connection from a developer machine. Your visitors are a distribution, and the slow tail of that distribution is where complaints come from. Field data almost always tells a less flattering story than a lab score, and it is the one worth acting on.
How much can you realistically improve?
It depends entirely on what is causing the problem, and we would rather diagnose before quoting an outcome. A site slowed by unoptimised images and render-blocking fonts can improve dramatically and cheaply. A site slowed by its own architecture improves only as far as that architecture allows, and saying so early is more useful than a number.
Will this improve our search rankings?
Possibly, marginally, and it is the wrong reason to do it. Core Web Vitals are a real but modest ranking input. The stronger argument is that slow pages lose people before they convert, which is a revenue effect you can measure directly rather than a ranking effect you can only infer.
Can you work on a site you did not build?
Usually yes. Diagnosis is largely framework-agnostic because the metrics measure what the browser does, not what generated it. Implementation depends on what we find; where the fix requires changes we cannot safely make in an unfamiliar codebase, we will hand over a precise specification instead of guessing.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.