—Service
Performance Optimisation
Core Web Vitals, loading speed, caching, code splitting, and database efficiency.
01Overview
We diagnose and fix the real causes of slow products — measuring before and after, so the improvement is verifiable rather than assumed. Frontend, backend, and database are all in scope.
02How we approach it
Every engagement starts with measurement, not opinion. During Discover we profile the product as users actually experience it — real-user Core Web Vitals data alongside lab traces — and follow slow requests through frontend, backend, and database. Define turns that evidence into a ranked plan: which fixes move the metrics that matter, what each involves, and the performance budget the system will be held to afterwards.
The Engineer stage works through that plan in order of impact. On the frontend that typically means trimming and splitting JavaScript, optimising images and fonts, and removing work that blocks rendering. On the backend it means caching what can be cached and indexing or rewriting the queries that cannot. Changes land as small, reviewable commits, each measured against the baseline, so it is always clear which change produced which improvement.
Nothing is assumed to have worked. Validate re-runs the same measurements taken at the start — lab traces and real-user data — under the same conditions, so the before-and-after numbers are directly comparable. Releases go out through staged deployment rather than one large drop, which keeps risk low on a live product and makes any regression easy to isolate and reverse.
Speed decays without a guard in place. The engagement closes with a documented performance budget — the thresholds the product must stay within — and monitoring that flags when new work threatens them. Through Evolve, we can keep holding the system to that budget ourselves, or hand the tooling and documentation to your team so the discipline continues without us.
03Suitable for
- Sites failing Core Web Vitals
- Products with slow queries
- Teams losing conversions to speed
04Problems solved
- Poor loading performance
- Layout shift and slow interactivity
- Inefficient database queries
05Deliverables
- Performance audit
- Frontend and asset optimisation
- Caching and query improvements
- Measured before/after results
06Technical considerations
- Real-user and lab measurement
- Indexed, efficient queries
- Documented performance budget
07Common questions
What determines the cost of a performance engagement?
Scope. A site failing Core Web Vitals on a handful of templates is a smaller job than a platform with slow queries across dozens of endpoints. The audit sizes the work: it identifies what is slow, why, and how much effort each fix demands. We publish no standard prices — once the brief is understood, scope and cost are set out in a written proposal, so you can see exactly what is included before anything is agreed.
Can you optimise a product you didn't build?
Yes — most performance work is on systems built elsewhere. We start by reading the codebase and profiling it rather than judging it, and fixes are made in your existing stack and conventions, not ported to ours. Where the audit finds problems optimisation cannot fix — foundations that are the bottleneck rather than the implementation — we say so plainly and set out what a rebuild would involve instead.
How do you measure whether the work succeeded?
Against the numbers taken before any change was made. We record a baseline from both lab tests and real-user data, agree the metrics that matter for the product — usually Core Web Vitals plus the response times of key journeys — and report the same measurements after the work. The deliverables include those before-and-after results, so the improvement is verifiable rather than claimed.
Will the work disrupt a live product?
It is designed not to. Changes are developed and tested away from production, released through staged deployment, and made in small increments rather than one large drop, so each step can be checked and reversed independently. If you have an in-house team, we coordinate with their release process and review flow rather than working around it. Monitoring stays in place throughout, so any regression is caught quickly.
How do we stop the product getting slow again?
By making speed a constraint rather than a one-off project. You receive a documented performance budget — the thresholds each page or endpoint must stay within — together with monitoring that measures against it, so regressions surface as they are introduced rather than months later. If you want the budget enforced for you, that continues under technical maintenance; if your team prefers to own it, handover includes the tooling and documentation to do so.
08Related
- Technical Maintenance
Monitoring, updates, issue resolution, security maintenance, and controlled improvement.
- Website Rebuilds
Complete replacement of outdated, slow, unstable, or template-dependent websites.
- Frontend Development
Responsive, accessible, high-performance interfaces built with modern component architecture.
- See it in practice: Merità
A e-commerce storefront concept study from our work gallery.
Discuss a performance optimisation project.
Tell us what you need. We'll tell you how we'd build it.