Website speed optimisation, measured where your customers are

What website speed optimisation actually means

Website speed optimisation means reducing the time between a visitor requesting your page and being able to use it, measured on the devices and networks your visitors actually have. It is a diagnostic discipline rather than a checklist — the same symptom has half a dozen possible causes and only one of them is yours.

The measurement is the part most work gets wrong. A Lighthouse run on a developer laptop over fibre describes the laptop. Google ranks on field data from real Chrome users at the 75th percentile, which means the quarter of your visitors having the worst experience are the ones deciding your score. Optimising for the lab number while the field number stays flat is the most common way this work is wasted.

Who this is for

• Sites failing Core Web Vitals in Search Console, particularly on mobile
• Businesses running paid traffic, where slow pages waste budget on every click
• E-commerce sites where speed is directly measurable in checkout completion
• WordPress sites that have accumulated plugins and a page builder over several years
• Anyone whose site was fast at launch and is not any more, without an obvious cause

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Sites where the honest answer is a rebuild. Optimising a page builder theme has a low ceiling and I will say so
• Businesses chasing a 100 Lighthouse score as a goal in itself, which routinely trades real performance for a lab number
• Sites with no traffic. Speed is not the reason nobody is visiting, and this would be the wrong purchase
• Anyone unwilling to remove third-party scripts, since those are frequently the whole problem

The problems it solves

Failing Core Web Vitals in Search Console

Each metric is diagnosed to a specific cause and fixed, then re-measured under identical conditions.

Slow first render

Critical CSS inlined, render-blocking resources deferred, and the LCP element preloaded rather than discovered late.

Huge images

AVIF and WebP with correct srcset, sized to the largest display width rather than the original upload.

Sluggish taps and clicks

Interaction to Next Paint work, which nearly always means shipping less JavaScript rather than reordering it.

Content jumping while loading

Dimensions on media, reserved space for embeds, and metric-matched font fallbacks.

Third-party tags nobody audited

Every tag measured for what it costs against what it returns, then presented to you as a decision.

What you get

• Field-data baseline from Chrome UX Report where your traffic supports it, plus throttled lab testing where it does not
• Largest Contentful Paint work: the actual LCP element identified, then preloaded, resized and served in a modern format
• Interaction to Next Paint work, which usually means shipping less JavaScript rather than reordering it
• Cumulative Layout Shift eliminated: dimensions on media, reserved space for embeds, metric-matched font fallbacks
• Render path fixed — critical CSS, deferred non-essential script, and third-party tags audited for what they cost
• Image pipeline: AVIF and WebP with correct srcset, and lazy loading applied below the fold only
• Caching and compression configured at the server, including long-lived immutable assets
• A before-and-after report with the numbers and the method, so you can reproduce it rather than trust it

What is included in the starting price

Everything below is in the $80 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Field-data baseline from Chrome UX Report where traffic supports it, plus throttled lab testing where it does not
• LCP diagnosis: the actual element identified, then preloaded, resized and served in a modern format
• INP work, focused on reducing and deferring JavaScript
• CLS eliminated: dimensions on media, reserved space, metric-matched font fallbacks
• Render path: critical CSS, deferred non-essential script, and a third-party tag audit
• Image pipeline rebuilt with AVIF and WebP, correct srcset, and lazy loading below the fold only
• Server-side caching, compression and long-lived immutable asset headers
• A before-and-after report with numbers, method and what was deliberately left alone

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

CDN configuration

Worth it for international traffic, often pointless for a single-country audience. You get the honest version.

Rebuilding a page builder theme

Where the theme is the ceiling, optimisation is money spent on a losing position. Quoted as a rebuild instead.

Ongoing performance monitoring

Regressions creep back with every content change. A retainer catches it; a one-off cannot.

Database optimisation

For sites where the server response time rather than the front end is the bottleneck.

Image re-authoring at volume

Re-exporting several hundred product images is real time and quoted on count.

How the work runs

1. Measure. Field data first. Lab numbers are a diagnostic tool, not the goal, and optimising for the tool instead of the visitor is the classic failure here.
2. Diagnose. Trace the specific cause. "The site is slow" is a symptom; "the LCP element is a 900KB hero PNG loaded after two blocking stylesheets" is something that can be fixed.
3. Fix in priority order. Biggest measured win first. Most sites get the majority of their improvement from two or three changes, and the rest is diminishing returns you should know about before paying for.
4. Verify. Re-measure under identical conditions. A comparison run on a different network at a different time of day is not a comparison.
5. Report. Before, after, what changed and what was deliberately left alone, with the reasoning for each.

Day by day

4 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Measurement

Chrome UX Report field data, PageSpeed Insights, and throttled Lighthouse runs for diagnosis only

Images

AVIF and WebP with fallbacks, generated at build time rather than resized in the browser

CSS

Purged and minified, critical path inlined where it measurably helps

JavaScript

Deferred, split, or deleted. Deletion is usually the highest-value option available

Server

Brotli or gzip compression, HTTP caching headers, immutable hashed asset filenames

What it integrates with

• Google Search Console Core Web Vitals reporting
• Chrome UX Report, for real-user field data at the 75th percentile
• Lighthouse in CI as a regression guard rather than a target
• Your tag manager, audited rather than assumed
• Any CDN you already pay for, configured properly instead of merely switched on

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• Access to the site, its hosting and its server configuration
• Search Console and analytics access for the field baseline
• Authority to remove third-party scripts, or a named person who can decide
• A list of tags and tools you believe are on the site, which is rarely the same as what is actually there
• Realistic constraints — a brand font or a required chat widget is a constraint, and it is better stated than discovered

Content and photography

Most speed problems are content problems wearing a technical costume. A 4MB hero photograph, an autoplaying video nobody asked for, and six tracking scripts added by four departments will defeat any amount of code optimisation.

The most useful preparation is an honest inventory of what is on the page and who wanted it there. Roughly half the third-party tags on a typical business site are for a tool nobody uses any more, and removing those is faster, cheaper and more effective than any technique in the rest of this page.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

The theme is the ceiling

Discovered during measurement and reported before the work continues rather than after you have paid for it.

Field data takes weeks to reflect the fix

CrUX is a 28-day rolling window. Lab numbers move immediately; the score you care about lags.

A required third-party script is the main cost

You get the number it costs and the decision stays yours. Some tags are worth their weight.

Regressions after the next content update

Unmonitored sites drift back. A retainer prevents it; a one-off engagement cannot.