Will you get me a green 90+ score?

No, and anyone who promises one before looking at your site is guessing. The score is a lab simulation of one page load on one simulated device; Google ranks on field data from your real visitors. We commit to fixing the causes we find and to showing you the before-and-after field numbers. Sometimes that lands at 90. Sometimes the honest answer is that your hosting is the ceiling.

How is this different from installing a caching plugin?

A caching plugin fixes one cause out of six. It does nothing about a 2 MB hero image, a chat widget that loads 400 KB of JavaScript before anything is painted, or a font that arrives late and shifts the whole page. Those are the ones that usually dominate, and they need looking at rather than switching on.

My PageSpeed report has forty items on it. Are you fixing all of them?

No. Three to five of them will produce most of the improvement and the rest are noise that costs time and risks breaking something. Part of the work is telling you which is which, including the items we are deliberately leaving alone and why.

Do you need access to my hosting?

For most of it, yes — caching, compression and image handling live at the server or CDN level. If you cannot give access, we can still do the front-end work and hand you an exact list for whoever can. We will say up front which part of the improvement is out of reach that way.

What if the site is fast for me already?

Then you are probably testing on a desktop, on fast broadband, with the page already cached. Field data is collected from real visitors, a large share of them on mobile networks and mid-range Android phones. The gap between "fast for me" and "fast for them" is the whole reason this service exists.

Will this break anything?

It can, which is why every change is made one at a time and measured after. Aggressive minification and lazy-loading are the two that most often break a layout or a script. Anything risky is flagged before it is applied, and the site is backed up first.

Web Development & Engineering

Speed and Core Web Vitals optimisation

Your site's LCP, CLS and INP brought inside Google's thresholds — measured on real visitors, not on a lab score.

From: $300–$1,500
Typical time: 3–10 days
Usually bought by: Any site owner

What this actually solves

Two things bring people to this page, and they are not the same problem.

The first is a warning in Google Search Console saying a set of URLs need improvement, and the fear that rankings are about to slide. The second is simpler and more expensive: the owner opened their own site on mobile data, waited four seconds, and understood why people are leaving. On a shop, that second one is money. Every additional second of load time costs conversions, and it costs them quietly — nobody fills in a form to tell you they gave up waiting.

Core Web Vitals are Google's three measurements of that experience. LCP is how long until the main thing on the screen has actually appeared. CLS is how much the page jumps around while it settles. INP is how long the page takes to respond when someone taps or clicks. They exist because "the site is slow" meant something different to every person who said it, and a shared number was needed.

The important part, and the one a green test result can hide: Google ranks on field data — what real visitors actually experienced — not on the score you get from running the test yourself. A lab score is one simulated load on one simulated device. It is useful for diagnosis and useless as a promise.

What we do, and in what order

The order matters more than the individual fixes. Changing six things at once and then re-testing tells you the total but never which change earned it — and when something breaks, you have six suspects.

Measure, and keep the evidence. PageSpeed Insights first, and the field data at the top of that report before the lab score below it. Screenshots of every number, dated. This is what the before-and-after is compared against later, and it is why we can tell you honestly whether the work paid for itself. Half a day.
Find the causes, in order of size. They are almost always drawn from the same short list: images shipped far larger than they are displayed, too much JavaScript, third-party scripts (chat widgets, ad pixels, analytics, review embeds), fonts that arrive late and shove the layout, slow hosting, and no caching. We rank them by how much each is actually costing, not by how easy each is to fix. Half a day to a day.
Fix them one at a time, re-measuring after each. Images resized and re-encoded, render-blocking JavaScript deferred, third-party scripts delayed until after first paint or removed where they earn nothing, fonts preloaded with a matched fallback so nothing shifts, caching and compression turned on at the server or CDN. Each change is measured before the next one starts. One to five days, depending on how much of it there is.
Re-measure and write it down. The same tests, the same conditions, the same screenshots, and a short report with the before and after side by side — including anything we could not move and the reason. Field data takes up to 28 days to catch up with the change, so the report says which numbers are immediate and which will arrive later. Half a day.

Tools used, so you know what you are getting rather than a black box: PageSpeed Insights and Chrome's Lighthouse and Network panel for measurement, WebPageTest when something needs a closer look than Lighthouse gives, Squoosh or TinyPNG for images, Cloudflare for caching and CDN, and on WordPress, WP Rocket or Perfmatters.

What moves the price

The range is $300–$1,500 and it is set almost entirely by three things.

The platform. WordPress is usually straightforward — the causes are familiar and the tooling is mature. An older custom build with no asset pipeline can take three times as long for the same improvement, because every fix has to be made by hand and tested by hand.

How many third-party scripts are loaded. A site with one analytics tag is a different job from a site carrying a chat widget, two ad pixels, a review embed, a heatmap tool and a cookie banner that loads before all of them. Each one has to be assessed for what it earns against what it costs, and some of those are commercial decisions that are yours, not ours.

Whether hosting is the ceiling. Sometimes the server's response time is the largest single number in the report, and no amount of front-end work fixes it. When that is the case we say so early, because the honest answer may be that a $12/month host is the problem and the optimisation is the wrong purchase until that changes.

What usually goes wrong

Someone promises a score. This is the big one, and it is why we never do it. "I'll get you to 90" is a promise about a lab simulation on hardware nobody in your audience owns, made before anyone has looked at your hosting. When the number lands at 74 with a genuinely faster site behind it, the project is judged a failure for the wrong reason. What we commit to is fixing real causes and showing real numbers.

The whole report gets "fixed". A PageSpeed report can list forty items. Three to five of them matter; the rest are a way to spend a week and risk breaking a working site for no measurable gain. Deferring every script sounds thorough and is how a checkout stops working.

The measurement is taken on the wrong thing. Testing the homepage on desktop broadband with a warm cache, and reporting that as the result, while the field data that Google actually uses is dominated by mobile visitors on mid-range Android phones hitting a product page cold. If the before-and-after does not compare like with like, it is not evidence.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will you get me a green 90+ score?: No, and anyone who promises one before looking at your site is guessing. The score is a lab simulation of one page load on one simulated device; Google ranks on field data from your real visitors. We commit to fixing the causes we find and to showing you the before-and-after field numbers. Sometimes that lands at 90. Sometimes the honest answer is that your hosting is the ceiling.
How is this different from installing a caching plugin?: A caching plugin fixes one cause out of six. It does nothing about a 2 MB hero image, a chat widget that loads 400 KB of JavaScript before anything is painted, or a font that arrives late and shifts the whole page. Those are the ones that usually dominate, and they need looking at rather than switching on.
My PageSpeed report has forty items on it. Are you fixing all of them?: No. Three to five of them will produce most of the improvement and the rest are noise that costs time and risks breaking something. Part of the work is telling you which is which, including the items we are deliberately leaving alone and why.
Do you need access to my hosting?: For most of it, yes — caching, compression and image handling live at the server or CDN level. If you cannot give access, we can still do the front-end work and hand you an exact list for whoever can. We will say up front which part of the improvement is out of reach that way.
What if the site is fast for me already?: Then you are probably testing on a desktop, on fast broadband, with the page already cached. Field data is collected from real visitors, a large share of them on mobile networks and mid-range Android phones. The gap between "fast for me" and "fast for them" is the whole reason this service exists.
Will this break anything?: It can, which is why every change is made one at a time and measured after. Aggressive minification and lazy-loading are the two that most often break a layout or a script. Anything risky is flagged before it is applied, and the site is backed up first.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Speed & Core Web Vitals optimisation All Web Development & Engineering services