Measure First. Then Fix What the Numbers Point At.
Slow pages, slow APIs, a cloud bill climbing faster than your traffic. Performance work on React and Node applications that starts with evidence rather than a guess about what is probably wrong.
Most Performance Work Fixes the Wrong Thing
Not through carelessness. Through starting from an opinion about where the time goes instead of a measurement of where it actually goes.
Measure, Prioritise, Fix, Protect
1. Establish a baseline
Real user monitoring where it exists, profiling where it does not, and traces through the slow path end to end. We want the shape of the slow tail, not an average. Without a baseline there is no way to tell afterwards whether anything actually improved.
2. Find the causes, in order of size
Frontend and backend are profiled separately, because a slow page is roughly as often a slow query as it is a rendering problem. The output is a written list of causes with an estimate of effort and expected impact against each, so you can choose what is worth doing rather than being handed a bill for all of it.
3. Fix the top of the list
Highest impact for lowest effort first, each change measured against the baseline individually. Batching ten fixes into one release makes it impossible to know which one worked, and which one quietly made something else worse.
4. Leave something watching
Performance budgets in CI, monitoring on the paths that mattered, and an alert when a number moves the wrong way. A fix with no regression check is a temporary fix, and six months later it is usually gone.
Frontend, Backend, and the Bit in Between
React Frontend
- Renders triggered by unstable props and context that changes too often
- Long lists without virtualisation on mid-range phones
- Bundle size, code splitting, and what is genuinely on the critical path
- Images, fonts and layout shift during load
- Data fetching that refetches on every focus because server state is treated as client state
Node Backend
- Queries in a loop where one query would do
- Missing indexes, and indexes that exist but are not used
- Synchronous work blocking the event loop
- Absent or badly scoped caching
- Memory growth in a long-running process nobody restarts
Everything Between
- Chatty APIs that need several round trips to draw one screen
- Payload sizes nobody has looked at since the feature shipped
- Third-party scripts blocking the main thread
- Cold starts on serverless under real traffic patterns
- Background jobs doing work that is no longer needed
What This Engagement Does and Does Not Cover
Included
Measurement and Diagnosis
Baseline, profiling, a written prioritised list of causes with effort estimates, and the reasoning behind the order.
Included
Fixes and Verification
Implementation of the agreed items, each measured individually, plus budgets and monitoring so the gains hold.
Possible, Scoped Separately
Structural Change
If the honest answer is an architectural change rather than tuning, we say so and quote it as its own piece of work.
Not Included
Infrastructure Costs and Licences
Monitoring tools, cloud spend and third-party licences are billed to you directly, never marked up through us.
A One-Off Fix Is Not Always the Right Purchase
If one specific path is slow and everything else is fine, fixed scope is exactly right. Measure it, fix it, leave a check behind, done.
If performance keeps degrading every few sprints, the problem is not any single slow path — it is that nobody currently owns the number. That is a hiring problem rather than a project, and a developer joining your team with performance in their remit will serve you far better than another engagement six months from now.
Compare engagement modelsOften Booked Alongside
Code Audits
A broader read on the codebase when performance is one symptom among several.
Learn moreTesting & Automation
The regression checks that stop a fixed number quietly drifting back.
Learn moreAPI Development
When the fix is a better-shaped API rather than a faster version of the current one.
Learn moreBefore You Commission Performance Work
How do you know what to fix before you start?
We do not, and neither does anyone else who tells you otherwise on a sales call. The first part of any performance engagement is measurement: real user data if you have it, profiling if you do not, and traces through the slow path end to end. Only then is there a list worth quoting against. Teams that skip this step reliably spend a fortnight optimising something that was never the bottleneck.
Can you guarantee a specific improvement?
No, and be wary of anyone who does before looking at your code. What we will commit to is a measured baseline, a prioritised list of causes with an estimated effort against each, and honest reporting of what each change actually achieved. Sometimes the honest answer after measurement is that the biggest win is a database index rather than anything in the JavaScript at all.
Is this a fixed-scope project or a developer engagement?
It can be either. A focused audit-and-fix on a specific slow path works well as fixed scope. Ongoing performance work, the kind that stops regressions creeping back in every sprint, is better served by a developer joining your team with performance as part of their remit. We will say which one your situation actually calls for.
Our cloud bill is rising faster than our traffic. Is that a performance problem?
Usually yes, and it is one of the more satisfying kinds to work on because the result shows up on an invoice. Runaway spend is commonly caused by inefficient queries hitting the database far more often than anyone realises, missing caching, oversized instances compensating for a slow code path, or a background job doing work that no longer needs doing. The fix often pays for the engagement.
Will the improvements survive after you leave?
Only if measurement stays in place, which is why we set up budgets and monitoring as part of the work rather than as an optional extra. A performance fix with no regression check is a temporary fix. We would rather leave you with a number your team watches than a one-off improvement that quietly erodes over the next six months.
Tell Us What Feels Slow
Describe the page, the endpoint or the bill. We will tell you what we would measure first and what a realistic engagement looks like.