Step 01
Measure
Baseline from real user field data, not a single lab score.
Faster sites rank better and sell more.
Core Web Vitals and page speed work for sites that load slowly - image and font delivery, script weight, render blocking and layout shift, measured against real user data rather than lab scores.
A slow site costs money twice: visitors leave before it loads, and Google measures the experience as a ranking input. Both are fixable, and the fixes are usually the same handful of problems appearing in different combinations.
I work against field data from real Chrome users rather than a single lab score, because a site can test well on a fast desktop connection and still be painful on a mid-range phone, which is where most traffic actually is.
In almost every audit the same offenders appear: uncompressed images several times larger than their display size, icon webfonts loaded in full to draw a handful of glyphs, third-party tags nobody remembers adding, and render-blocking stylesheets.
On this site I replaced a 262KB icon stylesheet and a 416KB webfont with inline SVGs, because six icons were being drawn at the cost of most of a megabyte. That kind of trade is common and almost always worth making.
Largest Contentful Paint is usually an image or font problem. Interaction to Next Paint is usually JavaScript blocking the main thread. Cumulative Layout Shift is usually missing dimensions on images and ads, or fonts swapping late.
Each has a distinct cause and a distinct fix, which is why a generic "make it faster" engagement tends to underdeliver. Measuring first tells you which of the three you actually have.
Serving a 1MB photograph into a 700px slot is the single most common performance fault on the web. Correct sizing, modern formats, responsive srcsets and lazy loading below the fold routinely cut page weight by more than half.
It is also the least risky change available: nothing about the design or the markup needs to alter, so there is no visual regression to argue about.
A measurement baseline from field data, a prioritised list of what is costing you most, the fixes implemented, and a re-measurement afterwards so the improvement is demonstrated rather than asserted.
If a site is slow for structural reasons that patching cannot fix - a page builder emitting enormous markup, for instance - I will say so rather than bill for incremental work that cannot reach the target.
Usually oversized images, webfonts loaded in full for a few characters, third-party scripts, and render-blocking CSS. A measurement will tell you which combination applies to your site, and they are almost always fixable without a redesign.
Yes. Core Web Vitals are a confirmed ranking signal measured from real Chrome users. The effect is smaller than relevance, but speed also affects conversion directly, so the commercial case is usually stronger than the ranking case.
Yes, both. WordPress usually means plugin and page-builder bloat plus image delivery; Shopify usually means app script weight. The diagnosis differs by platform but the method is the same.
Aim for passing Core Web Vitals on real user data rather than a particular lab number. A perfect lab score on a site that fails field data has optimised for the test instead of for visitors.
How a website speed optimisation engagement actually runs, start to finish.
Baseline from real user field data, not a single lab score.
Identify which vital is failing and what specifically causes it.
Implement the changes in priority order, biggest win first.
Re-measure and show the difference against the baseline.
Full Time Contract Available. Tell me about your project, your timeline and your budget, and I’ll reply with an approach and a rate.
Start a project
