Engineering

Website performance, measured on real users

Performance is the one engineering property every visitor experiences directly. We work from field data rather than synthetic scores, fix the dominant cost rather than the textbook one, and enforce a budget so the gains survive the next release.

The problem

Synthetic scores and real experience are not the same number

A lab score tells you what a page can do on a fast machine with a warm cache. Field data tells you what your users actually experienced on their devices and connections — which is both what they judge you on and what search infrastructure measures. Optimising to the former while the latter stays poor is a common and expensive mistake.

A good lab score and failing Core Web Vitals in field data
Content that visibly shifts as it loads
Pages that respond slowly to the first interaction
High Time to First Byte setting a floor under everything else
Fast desktop experience and slow mobile experience
Performance improvements that regress within a release or two

Who this is for

The people who usually bring us this problem

CTO / VP Engineering

You need performance treated as an engineering property with a budget and tests, rather than an aspiration that decays.

Head of SEO

Core Web Vitals are failing and the remedy sits in the front end or the server, not in content.

CMO / Head of Product

You suspect page experience is costing conversions and need to know which specific metric to fix first.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

Layout instability is worse on mobile than slowness

Content that moves while a user is reaching for it produces mistaps and abandonment, not merely delay. On mobile it is the most directly damaging of the Core Web Vitals.

Server response time caps every other optimisation

No front-end work can produce a fast page if the server is slow to begin responding. TTFB is a floor, and fixing the ceiling before the floor wastes the effort.

Unbudgeted performance regresses by default

Without enforcement, performance decays with each release. Most platforms do not fail to improve; they improve and then quietly return to where they were.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Field-data diagnosis

Working from real-user metrics segmented by device, connection and geography, so the fix targets the users who are actually suffering rather than the average.

Largest Contentful Paint

Identifying what the largest element actually is on each key template, then reducing the work required to render it — server response, resource priority, or the element itself.

Interaction to Next Paint

Main-thread work, hydration cost and long tasks. INP is usually the metric most damaged by accumulated JavaScript and the least visible in a lab score.

Cumulative Layout Shift

Reserving space for asynchronously loaded content at template level, so the fix applies across the estate rather than to individual pages.

Time to First Byte

Server, database, caching and edge work — the infrastructure half of performance, and frequently the half with the greatest effect.

Critical-path and asset optimisation

What must load before the page can render, what can wait, and what need not load at all. Image formats, font strategy and render-blocking resource removal.

Performance budgets

Enforceable limits in the build pipeline, so a regression fails continuous integration instead of reaching users.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Field data first, lab data second
Lab data is useful for reproducing and diagnosing; field data is the objective. We start and finish with what users experienced.
Fix the floor before the ceiling
Server and network work precedes front-end work, because a TTFB problem makes every subsequent metric look bad in a way that front-end optimisation cannot fix.
Segment by real experience
A single aggregate figure hides the distribution. Mobile users on slow connections are typically a minority of traffic and a majority of the poor experience, and they are the ones with the lowest tolerance.
Change the template, not the page
Performance faults are usually systemic. Fixing them in the template or the build pipeline applies the fix everywhere and, more importantly, keeps it applied.
Budget to prevent regression
The final deliverable is an enforced budget, because without one the work is temporary.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Assessment

Field CWV analysis segmented by device and connection
Critical-path and resource-cost breakdown
TTFB decomposition across server, database and network
Template-level fault identification

Remediation

Server and caching work for TTFB
Template-level layout stability
Render-blocking resource removal
Image, font and asset optimisation
Main-thread and hydration cost reduction

Protection

Performance budget in the build pipeline
CI enforcement on key routes
Ongoing field monitoring and alerting

Under the hood

Architecture and technology

Measured

Largest Contentful Paint
Interaction to Next Paint
Cumulative Layout Shift
Time to First Byte
Segmented by device, connection and geography

Changed

Rendering and hydration strategy
Asset formats, sizing and loading priority
Font loading strategy
Cache policy and edge configuration
Template layout stability

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

Online communities

Arrse.co.uk

An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.

4%increase in organic clicks

Online communities & specialist publishing

GuzziTech & RideMalibu

Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.

Since 2021managed infrastructure, performance and SEO

Education technology

Educativ.net

A platform that had previously ranked well had declined through a combination of technical and on-page problems: nearly ninety percent of the site failed Google's Core Web Vitals assessment, server response times were high, and metadata and content signals needed work. The engagement addressed those constraints together.

21%increase in search traffic

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

Field data is poor but the page itself looks fine

The constraint is probably upstream. See Infrastructure Engineering.

Performance degrades specifically under traffic

That is a concurrency problem rather than a page-weight problem. See High-Traffic Website Engineering.

Questions

Frequently asked

Which Core Web Vital should we fix first?

Whichever is furthest from passing in field data for your most commercially important template — with one qualification: if TTFB is poor, fix that first regardless, because it constrains every other metric and any front-end work done before it is measured against a floor that has not moved.

Is Core Web Vitals a ranking factor?

It is a real but modest signal, and it is not the main reason to do this work. The direct user experience effect on conversion and engagement is usually the larger commercial argument, and it is not subject to the ambiguity that claims about ranking factors are.

How do you stop performance regressing?

By enforcing a budget in continuous integration. Performance that is not enforced decays — this is the single most reliable pattern in the field. Without a budget, the work produces a temporary improvement and a future version of the same engagement.

Can you improve performance without changing the design?

Usually yes, and that is the normal case. Most performance cost lives in how resources are fetched, prioritised and rendered rather than in how the page looks. Where the design itself is the cause we will say so, and quantify what it costs.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work