What we usually find

The causes are consistent across the sites we assess, and most of them are decisions rather than defects.

  • Third-party scripts – tag managers, chat widgets, marketing tags – dominating the main thread.
  • Large unoptimised images being served at full resolution to phones.
  • Multiple web font families loading render-blocking before any text appears.
  • A JavaScript framework rendering content that could have been static HTML.
  • Layout shift from images without dimensions and content injected after load.
  • Slow server response, which no amount of frontend work can compensate for.
  • A site that was fast at launch and has degraded a little with every release since.

What we do

Performance audits

Lab and field measurement together – synthetic testing to isolate causes, real-user data to establish what visitors actually experience – with findings ordered by impact against effort.

Core Web Vitals remediation

Targeted work on LCP, INP and CLS: identifying and prioritising the LCP element, removing render-blocking resources, breaking up long tasks, and eliminating the sources of layout shift.

Frontend optimisation

Critical rendering path, JavaScript bundle reduction and code splitting, CSS reduction, resource hints, and rendering strategy.

Image and media optimisation

Modern formats, correct responsive sizing, explicit dimensions, lazy loading below the fold, and prioritisation of the image that matters.

Third-party script governance

Measuring what each tag costs in milliseconds, deferring or removing what is not earning its place, and giving you the trade-off explicitly so it is a business decision.

Server and delivery

Response time, caching strategy at every layer, compression, CDN configuration and delivery. Frontend work cannot fix a slow origin.

Performance budgets

Agreed limits enforced in the development process, so performance is maintained by default rather than recovered in an annual project.

Diagram

The three field metrics read against their thresholds at the 75th percentile, segmented by device.

How we work

The current thresholds we design and build against, measured at the 75th percentile of real page loads and segmented by device.

  1. Measure real users, not just lab scores Lab tools isolate causes; field data tells you what your visitors experience on their devices and networks. Optimising a lab score without field improvement is a common and expensive mistake.
  2. Find the cause, not the symptom A poor LCP is a consequence. The cause might be an origin response, a render-blocking font, a lazy-loaded hero or a client-rendered page. The fix differs completely in each case.
  3. Fix the biggest constraint first Performance work has a dominant bottleneck at any given moment. Working the list in order wastes effort; we find the constraint and remove it, then re-measure.
  4. Prevent regression A budget in the build process and monitoring in production. Performance is not a project you finish, it is a property you maintain.

What you receive

  • Performance audit with lab and field data
  • Prioritised findings with expected impact per fix
  • Implemented optimisations
  • Before-and-after Core Web Vitals measurement
  • Third-party script cost analysis
  • Caching and delivery configuration
  • Performance budget and monitoring setup
  • Documentation so your team can maintain it

Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Operate work sits inside that process rather than alongside it.

Read the full process, stage by stage

Common questions

Is a perfect Lighthouse score the goal?

No. Lighthouse is a lab diagnostic, useful for finding causes. The goal is good field metrics for real users on real devices. Sites with excellent lab scores and poor field data are common, and the field data is the one that reflects your business.

Can you make our site fast without rebuilding it?

Usually a substantial improvement, yes. Where the architecture itself is the constraint – a client-rendered site delivering static content, for example – there is a ceiling, and we will tell you where it is rather than charging for work that cannot pass it.

Will removing tracking scripts hurt our marketing?

We do not remove things unilaterally. We measure what each script costs in milliseconds and present the trade-off. Frequently there are tags nobody has used in a year, and those are easy decisions.

Site slower than it should be?

Send us the URL. We will run a real assessment and tell you what is actually causing it before quoting for anything.

Message us on Telegram (opens in a new tab)