Profiling on real conditions
Measured with production-shaped data on throttled devices — a flame chart from a fast laptop on fibre proves nothing about your users.
Performance tuning
Make it fast on real data, not just on your laptop
A prototype is fast because it holds twelve rows. We profile the paths your users actually take, then fix the ones that fall over at scale.
In short
Performance tuning is the work of measuring where an app spends its time — network, database, render, and JavaScript bundle — and removing the largest cost at each layer. In AI-built apps that usually means adding caching and pagination, splitting a bundle that ships every page on first load, and moving work to the server. Gen2Prod tunes against production-shaped data on throttled devices and reports the before and after in Core Web Vitals: LCP, INP and CLS.
- Typical timeline
- About 1 week
- Measured in
- LCP, INP, CLS, TTFB and bundle size
- Tested on
- Throttled 4G and mid-range Android, not just fibre
- Best for
- Apps that feel fine in a demo and crawl in production
You probably need this if…
- The dashboard takes five seconds to show anything.
- It's fast for you and slow for everyone else.
- Lighthouse is red and you're not sure which number matters.
- The first load ships every page's JavaScript at once.
- It got slower every week and nobody knows which change did it.
What performance tuning covers
Caching where it counts
HTTP caching, request memoisation and CDN rules, so repeat work stops reaching your origin and your database.
Bundle & code-splitting
Route-level splitting, deferred third-party scripts, and an analysis that names the megabyte you didn't know you were shipping.
Render-path fixes
Server-render what can be, stream the rest, and remove the layout shifts that make a fast page feel broken.
Images & fonts
Correct formats, sizes and preloads — usually the cheapest LCP win available, and usually the one AI builders skip.
A performance budget
Thresholds enforced in CI, so the regression gets caught in the pull request instead of in your inbox.
How we run it
- 1
Measure first
A baseline from real traffic and lab runs, so every claim afterwards has a before and an after behind it.
- 2
Fix in cost order
The one query, script or image that owns half your load time comes first. Micro-optimisations come last, if at all.
- 3
Lock the win in
Budgets in CI and a short note on what to watch, so the improvement survives the next ten features.
What you get back
- A before/after report in Core Web Vitals, with the traces behind it
- Caching and code-splitting shipped, not merely recommended
- A performance budget enforced in CI
- A ranked list of the remaining wins with effort estimates
Tools we reach for
- Chrome DevTools
- Lighthouse & WebPageTest
- Core Web Vitals (LCP/INP/CLS)
- Next.js App Router
- CDN & edge caching
- Bundle analyzer
- React Profiler
Performance tuning — questions we get asked
How fast can my app realistically get?
Most AI-built apps have one or two dominant costs — an unpaginated query, a blocking third-party script, an unoptimised hero image — and removing them moves load time far more than a hundred micro-optimisations. We give you the realistic ceiling after the audit, with the trace that supports it.
Do I have to rewrite anything to get faster?
Rarely. Most of the wins are caching, configuration, and moving work to the right place. If rewriting one screen is genuinely the only fix, we scope that separately so the decision stays yours.
Will you break things making it fast?
The critical paths get test coverage before we touch them, and every change ships behind a preview deploy you can click through yourself.
Is this the same as improving Core Web Vitals for SEO?
Yes — LCP, INP and CLS are what Google measures for page experience, so tuning them is both a user-facing and a ranking-facing win. We report the field data from real users, not just the lab score.
Often paired with
All servicesDatabase & queries
AI tools write queries that work. They don't write queries that work at a million rows. We find the ones that will melt first and fix them at the source.
Learn moreSecurity hardening
An API key in the browser bundle. Authorisation checked only in the UI. It's the same short list nearly every time, and every item on it is exploitable in an afternoon.
Learn moreDeploy & CI/CD
Deploys should be boring: push, watch it go green, roll back in one click if it isn't. We set that up once and you stop thinking about it.
Learn more