Frame-budget audits, animation-jank surgery, and Lighthouse rescues for sites that look right but feel wrong. I find where the milliseconds go — main-thread stalls, layout thrash, unoptimized assets, shader compiles — and fix them without a redesign.
Make the site you already have feel expensive.

A steady frame graph is the whole deliverable: no spikes, no dropped frames, nothing to explain away.
By the numbers
The targets I hold a build to before I call it done.
Core Web Vitals, in the green
Where a rescued site lands against Google's thresholds. The dial fills toward the budget ceiling — less is better on all three.
How it runs
Four stages, in order. Open any one to see what actually happens in it.
Lab and field data first: Lighthouse, a DevTools performance trace, and WebPageTest from a throttled connection. Optimising without a baseline is guessing, and guessing is how teams spend a month making a site 2% faster.
Main-thread stalls, layout thrash, unoptimised assets, shader compiles, render-blocking third parties. Each finding gets written up with its measured cost and the effort to fix it, so you can decide what's worth doing.
Cheapest wins with the largest measured impact go first. Animation and scroll jank get surgery rather than a rewrite — in most cases the redesign you were quoted isn't necessary to make the site feel expensive.
A before/after report your whole team can read, plus the budgets and checks needed to stop the regression creeping back in on the next feature branch.
What you get
- Full performance audit with a prioritized, costed fix list
- Animation and scroll-jank fixes: consistent 60fps on real devices
- Asset optimization: images, fonts, 3D models, and code splitting
- Core Web Vitals brought into the green and kept there
- A before/after report your whole team can read
Let's scope it
Tell me what you're building and roughly when you need it — you'll get an honest answer about fit, timeline, and a fixed proposal. No meter running, no surprise invoices.
Start a conversation →