Speed & performance optimisation
measured where revenue is.
Core Web Vitals, bundle size and server response times taken seriously enough to move revenue.
- — Search Console flags Core Web Vitals as needing improvement
- — Mobile conversion is far below desktop
- — The site got slower with every marketing tag added
The work should
change the numbers.
Performance work goes wrong when it chases a Lighthouse score. A synthetic 98 means very little if your actual users are on mid-range Android phones over congested networks, which is what field data usually reveals.
We start with real-user measurement, find the two or three causes responsible for most of the damage, and fix those at the source. Usually it is images, third-party scripts, render-blocking CSS, and a server response time nobody has looked at in two years.
Then we install budgets in CI, because performance is not a project. Without a gate, every optimisation is undone within six months by well-intentioned additions.
What the engagement
actually contains.
Field and lab measurement
Real-user Core Web Vitals segmented by device, country and template, alongside controlled lab runs.
Critical path optimisation
Render-blocking resources removed, critical CSS inlined, fonts loaded without layout shift.
Image and media pipeline
Modern formats, correct sizing, aspect-ratio reservations and lazy loading applied properly.
Third-party script control
Tags audited for actual value, then deferred, proxied or removed — usually the single biggest win.
Server and caching strategy
TTFB improved through caching layers, CDN rules and query tuning rather than more hardware.
Performance budgets in CI
Automated Lighthouse and bundle-size gates that fail a pull request before a regression ships.
- Baseline field and lab performance report
- Prioritised fix list with expected impact
- Implemented optimisations with before/after evidence
- Image and asset pipeline configuration
- CI performance budgets
- Ongoing Core Web Vitals dashboard
- Search Console flags Core Web Vitals as needing improvement
- Mobile conversion is far below desktop
- The site got slower with every marketing tag added
- Speed was fixed last year and has drifted back
What usually went wrong
before we were called.
- 01Optimising for a lab score while field data tells a different story
- 02Adding a tag manager and never auditing what it loads
- 03Lazy-loading the hero image and hurting the very metric you are chasing
- 04Fixing performance once with no budget in CI to hold it
- Field LCP, INP and CLS by device
- Mobile conversion rate
- Total page weight and request count
- Budget failures caught in CI
2–4 weeks for the first measurable pass
What week one
actually looks like.
Field data segmented by device, country and template alongside lab runs, so the fix list is aimed at where the damage actually is rather than at a synthetic score.
- Analytics and Search Console access
- Repository and deployment access
- A decision-maker for third-party script removal
- CDN and hosting credentials
- Redesigning pages, unless scoped
- Rewriting the application architecture
- CDN or hosting upgrade costs
- Ongoing monitoring, unless retained
Scope boundaries stated up front rather than discovered in a change request.
Four stages, visible throughout.
Assess
A baseline across performance, security, accessibility and dependency risk, with findings ranked by consequence.
Stabilise
The urgent items closed first: exposed surfaces, failing checks, missing backups, unpatched dependencies.
Automate
Budgets, scans and alerts moved into CI and monitoring, so regressions are caught by machines rather than customers.
Review
A quarterly session on what changed, what is drifting and what deserves next quarter’s attention.
Where this has paid off.
The website that finally sells the product.
We rebuilt an industrial software marketing site around the way technical buyers actually evaluate.
A storefront built for considered growth.
A Shopify migration and modular commerce build gave a fast-moving team a clearer path from interest to order.
Speed & performance optimisation, answered.
On mobile commerce and lead generation, reliably yes — and the mechanism is simple: fewer people abandon before the page is usable. We baseline conversion by device before starting so the outcome is measured rather than asserted.
Partly. Some tags can be deferred, proxied or moved to a worker with no loss of function. Others genuinely cost what they cost, and the honest conversation is whether that tag earns its weight. We give you the numbers per tag so it is your decision.
As long as the budgets stay in CI. Without a gate, expect regression within two quarters. With one, a failing pull request tells the person who added the regression, at the moment they added it.
Website & app maintenance
Ongoing updates, monitoring and a senior person to reach when something needs deciding.
Hosting & domain management
Infrastructure, DNS and deploy pipelines managed so uptime stops being your problem.
Web development
Custom, WordPress and Shopify builds for teams who need a site that sells, not just one that exists.
QA & testing
Manual and automated coverage that finds the failure before your customers volunteer to.
Make speed & performance optimisation useful.
Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.