Website Speed & Core Web Vitals Optimisation
We fix the three numbers Google actually measures on real visitors — LCP, INP and CLS — and we tell you honestly how much of your traffic problem they were. Most sites we audit are failing one of the three and guessing about the other two.
Which engagement you need
Three ways to buy this, plus one case where you should not buy it at all. Pick by the problem you can describe, not by budget — most sites need the first one before they can price the second.
We measure your field data, split LCP into its four parts, and tell you which fixes are worth the money. Sometimes the answer is that speed is not your problem and your conversion rate is.
Diagnosis and the actual fixes, on your site, by us. Template surgery, image and font pipeline, script triage, caching and CDN. Field data takes another 28 days to catch up.
Speed regresses every time somebody installs a plugin or adds a tracking tag. We watch the field data monthly and catch the regression before your rankings notice.
Performance is far cheaper to design in than to bolt on. If a redesign or a new WordPress build is already on the table, budget the speed work there instead.
What actually breaks, and why the usual fixes miss it
Five things we find on nearly every site that comes to us after somebody else has already “optimised” it.
Your PageSpeed score is not the number Google uses
The 0–100 figure at the top of PageSpeed Insights is a Lighthouse lab test: one simulated load, one throttled connection, one device profile. Google's Core Web Vitals assessment uses field data instead — real Chrome users on your real pages, aggregated in the Chrome User Experience Report, and judged at the 75th percentile of those visits, split between mobile and desktop.
That gap is why a site can show 98 in the lab and still fail in Search Console. The lab machine is not on a three-year-old Android phone on a patchy connection; a quarter of your visitors are. We work from the field panel first and treat the lab score as a debugging tool, which is what it was built to be.
The trap: chasing the green 90+ badge. It is the easiest number to move and the one least connected to what Google records against your domain.
LCP is four problems wearing one number
Largest Contentful Paint has to land within 2.5 seconds, and web.dev breaks it into four parts with a target share for each: time to first byte at roughly 40%, resource load delay under 10%, resource load duration at roughly 40%, and element render delay under 10%. Until you know which part is eating your budget, you are guessing.
In practice the split tells you who owns the fix. A bloated TTFB is a hosting, database and caching problem. A long load delay usually means the hero image is not discoverable in the initial HTML — it is being injected by a slider or a lazy-load script that fires too late. A long render delay is render-blocking CSS or a synchronous script. Those are three different invoices, and buying the wrong one is how agencies waste a client's budget honestly.
The trap: optimising one subpart in isolation. web.dev is explicit that improvements have to address all four, because shrinking one often just shifts the delay into another.
INP is where WordPress sites quietly fail
Interaction to Next Paint replaced First Input Delay as a Core Web Vital on 12 March 2024. FID measured only the delay before the first interaction's handler ran, which flattered almost everybody. INP measures the full latency of interactions across the whole visit — clicks, taps and key presses — through to the next painted frame, and the ceiling for a good rating is 200ms.
That change moved the goalposts for plugin-heavy sites. A WordPress install carrying a page builder, a popup plugin, a chat widget, a consent banner and four tracking tags has a main thread that is busy long after the page looks finished. The visitor taps the menu; nothing happens for 400ms. HTTP Archive's Core Web Vitals Technology Report put WordPress origins passing all three vitals at roughly 49% in April 2026, well behind hosted platforms like Shopify and Wix — and responsiveness is a large part of that gap.
The trap: a caching plugin. Caching improves TTFB and does almost nothing for INP, because the JavaScript still has to parse and execute on the visitor's device either way.
CLS is usually an ads, fonts and embeds problem
Cumulative Layout Shift has to stay at or below 0.1. Unlike the other two, it is rarely about code quality — it is about things that arrive late and push the page around. Images and video embeds without width and height attributes. A web font swapping in and re-flowing a heading. An ad slot or a cookie banner that reserves no space until it loads.
It is also the vital that costs you money most directly, because the shift usually happens under the reader's thumb at the moment they go to tap. The Economic Times reported CLS moving from 0.25 to 0.09 as part of a wider vitals programme that cut bounce rate 43% across a domain serving over 45 million monthly users.
The trap: testing CLS on desktop only. Most layout shift is a mobile problem, and most of it happens below the fold where a quick visual check never looks.
Speed is a conversion lever before it is a ranking lever
We will not tell you that passing Core Web Vitals lifts rankings, because Google does not say that. Google's own page experience documentation states plainly that “there is no single signal”, that Search “always seeks to show the most relevant content, even if the page experience is sub-par”, and that good scores in these reports do not guarantee a top position. Page experience is a tie-breaker among pages of comparable relevance, not a substitute for relevance.
The revenue case is stronger and better evidenced than the ranking case. Vodafone ran a proper 50/50 A/B test on a landing page — roughly 100,000 clicks a day to each arm, versions identical except for the vitals work — and measured a 31% better LCP producing an 8% increase in total sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate. That is the argument we make for this service. If you want the ranking argument, spend the money on content and SEO instead and come back to speed afterwards.
The trap: buying speed work as an SEO product. Buy it as a conversion product with an SEO side effect, and the business case holds up even in the months the rankings do not move.
What each engagement includes
Same measurement discipline in all three. The difference is who does the fixing and for how long.
| Vitals Audit | Speed Fix Sprint | Performance Retainer | |
|---|---|---|---|
| Typical duration | 5 working days | 3–4 weeks | Monthly, 3-month min. |
| Field data analysis (CrUX) | Included | Included | Monthly |
| LCP subpart breakdown | All four parts | All four parts | Tracked |
| INP interaction profiling | Top 5 templates | Top 5 templates | Ongoing |
| Prioritised fix list with effort estimates | Included | Included | Rolling |
| We implement the fixes | — | Yes | Within scope |
| Image and font pipeline rebuild | — | Yes | If needed |
| Third-party script triage | Recommendations | Implemented | Ongoing |
| Hosting and CDN review | Recommendations | Implemented | Ongoing |
| Regression alerting on new releases | — | — | Included |
| Monthly field-data report | — | One follow-up at day 28 | Every month |
| Investment | Fixed quote | Fixed quote | Monthly retainer |
All pricing is quoted after a free scoping call, because the work scales with your template count and plugin load, not with a package tier. Verified 14 September 2026.
Core Web Vitals Audit
Find out what is actually slow, and what fixing it is worth, before committing a budget.
We pull your Chrome User Experience Report field data, segment it by mobile and desktop, and identify which of your templates are dragging the origin-level assessment down. Then we break LCP into its four subparts on each of those templates, profile the interactions that are costing you INP, and trace every layout shift to the element that caused it.
You get a written report with a prioritised fix list — each item carrying our estimate of implementation effort and expected impact — plus the raw measurement data so any developer, ours or yours, can act on it. We also tell you plainly which items are not worth doing.
What you get
Field-data assessment against the current thresholds, per-template LCP subpart breakdown, INP profiling on your five highest-traffic templates, CLS attribution, a ranked fix list with effort and impact estimates, and a walkthrough call.
What it is not
No code is changed. This is a diagnosis, not a treatment. If your site has fewer than roughly 1,000 monthly visits per template, CrUX may not hold enough data to report on you at all — we will tell you that on the scoping call rather than after invoicing.
Best for: sites where Search Console is flagging a vitals problem but nobody can say which change caused it, and for getting a defensible number in front of whoever signs off the budget.
Speed Fix Sprint
The audit, then the implementation, on your site, inside one month.
Week one is the audit. Weeks two and three are the work: making the LCP element discoverable in the initial HTML and giving it fetch priority, rebuilding the image pipeline onto modern formats at correct dimensions, taking the font loading off the critical path, removing render-blocking CSS from above-the-fold rendering, breaking up or deferring the long JavaScript tasks that are costing you INP, reserving space for every late-arriving element, and correcting caching and CDN configuration.
Third-party scripts get the hardest look. On most sites we audit, a measurable share of the main-thread cost belongs to tags nobody has reviewed in two years. We produce the list, quantify each one, and you decide what stays — we do not silently remove marketing infrastructure.
Everything is done on a staging copy first and verified before it goes near production. For e-commerce we test the full cart and checkout path, because that is where speed work most often breaks something expensive. If you are on Shopify or BigCommerce we work within platform limits and say so — see our Shopify and BigCommerce pages for what those constraints look like in practice.
What you get
Everything in the audit, plus implementation on staging and production, before-and-after lab measurement on every affected template, a written change log, and one follow-up report at day 28 when the field data has refreshed.
What it is not
Not a rebuild. If your theme or page builder is the root cause — and sometimes it is — we can only work around it, and we will say so rather than bill a month against a ceiling we cannot lift. That conversation belongs with a redesign.
Best for: sites with a known speed problem, a working development process, and a template architecture worth keeping.
Performance Retainer
Because the next plugin, campaign tag or theme update will undo some of it.
Site speed is not a project that finishes. Every plugin update, every new tracking pixel for a campaign, every hero video a marketer adds to a landing page moves the numbers. Because field data is a 28-day rolling window, a regression introduced today does not show up in Search Console for weeks — by which time three more changes have landed and nobody can tell which one did it.
The retainer closes that gap. We monitor field data monthly against your baseline, flag regressions with the release that caused them, and fix what falls inside the agreed scope. You get a plain-English monthly report that says what moved, what caused it and what we did — the same reporting discipline we apply across our digital marketing retainers.
What you get
Monthly field-data review against baseline, regression alerting tied to your release cycle, in-scope fixes implemented, pre-launch performance review on new templates and campaign pages, and a monthly report written for a business owner rather than a developer.
What it is not
Not unlimited development. Major new work — a new template family, a platform migration, a full image pipeline rebuild — is scoped and quoted separately. We would rather define that boundary in the contract than argue about it in month four.
Best for: sites that ship changes regularly, run paid traffic to landing pages, or have already paid for speed work once and watched it decay.
The sequence, and why it is in this order
The order matters more than the individual fixes. Most wasted speed budgets come from doing step four before step two.
- Establish the field baseline. Before anything changes, we record what CrUX currently reports for your origin and your key templates, on mobile and desktop separately. Without a baseline you cannot prove the work did anything, and at day 28 you will want that proof.
- Find which templates are responsible. The origin-level score is an average of everything. Usually two or three templates are dragging it down while the rest pass comfortably. Fixing the passing ones is the most common way to spend a budget and see no movement.
- Split each metric into its causes. LCP into its four subparts, INP into input delay, processing duration and presentation delay, CLS back to the specific elements shifting. This is the step that decides what the work actually is.
- Fix the critical path first. TTFB, the LCP resource's discoverability and priority, and render-blocking resources — in that order. These are usually the cheapest fixes with the largest measured effect.
- Then attack the main thread. Script triage, code splitting, deferring what can be deferred, breaking up long tasks and yielding between them. This is where INP is won, and it is slower and more careful work than the load-time fixes.
- Reserve space for everything that arrives late. Explicit dimensions on media, space held for ads, banners and embeds, font loading that does not re-flow the page. CLS is usually the quickest of the three to fix once you know what is moving.
- Re-measure in the lab, then wait for the field. Lab results confirm the same day; field data needs the full 28-day window to refresh. We book the follow-up review for day 28 and resist drawing conclusions before it.
What we measure, and what we will not promise
The parts of this service most agencies leave off the page.
- We report field data, not lab scores. Lighthouse numbers appear in our reports as debugging evidence. The result we are accountable for is what the Chrome User Experience Report says at the 75th percentile of your real visits.
- We will not promise a ranking improvement. Google states there is no single page experience signal and that relevance outranks page experience. Anyone guaranteeing you positions from vitals work is selling something Google has publicly contradicted.
- We will not promise a specific conversion lift. The Vodafone and Economic Times results on this page are theirs, measured on their traffic and their funnels. They are evidence that the lever exists, not a forecast for your site.
- Low-traffic sites may not be measurable. CrUX needs a minimum volume of visits before it reports on an origin or URL. If you are below it, we can only work from lab data, and we will tell you that before you buy rather than after.
- Some ceilings we cannot lift. A page builder that emits 400KB of render-blocking CSS, or a platform that will not let us control script loading, sets a floor on what is achievable. We say so in the audit instead of billing against it.
What we verified for this page, and what we could not
| Claim | Status | Source |
|---|---|---|
| LCP 2.5s, INP 200ms, CLS 0.1 at the 75th percentile | Verified 14 Sep 2026 | web.dev, Core Web Vitals |
| INP replaced FID on 12 March 2024 | Verified 14 Sep 2026 | web.dev announcement |
| LCP subpart target shares (40/10/40/10) | Verified 14 Sep 2026 | web.dev, Optimize LCP |
| No single page experience ranking signal | Verified 14 Sep 2026 | Google Search Central |
| Vodafone 31% LCP → 8% sales, 50/50 A/B test | Verified 14 Sep 2026 | web.dev case study |
| Economic Times CLS 0.25→0.09, bounce rate −43% | Verified, but dated 2021 | web.dev case study |
| ~49% of WordPress origins passing all three vitals | Secondary source only | Search Engine Journal reading HTTP Archive, April 2026 |
| No three vitals added or retired since INP | Verified 14 Sep 2026 | CrUX release notes to Aug 2026 |
The WordPress pass-rate figure is the one number on this page we could not read directly from the primary dataset — HTTP Archive's Core Web Vitals Technology Report API did not respond to us on 14 September 2026, so we are citing a publication that read it. Treat it as approximate. The Economic Times figures predate INP and are quoted for the CLS and bounce-rate result, not as current responsiveness benchmarks.
Frequently asked
How long before I see the improvement in Search Console?
Lab measurements confirm the change the same day, but Google's Core Web Vitals assessment uses a 28-day rolling window of real user data from the Chrome User Experience Report. That means Search Console will keep showing a blend of your old and new performance for roughly four weeks after the fixes ship, and the full effect is only visible once the window has turned over completely. We schedule the follow-up review at day 28 for exactly this reason, and we would treat any agency reporting a field-data win in week one as either measuring lab data or misreading the report.
Will passing Core Web Vitals improve my Google rankings?
Possibly, but not reliably, and not on its own. Google's page experience documentation is unusually direct about this: there is no single page experience signal, Search still shows the most relevant content even when the experience is sub-par, and good scores in these reports do not guarantee a top position. Where page experience does help is as a differentiator between pages of similar relevance, which is common in competitive commercial queries. Our honest position is that you should buy speed work for its measured effect on conversion and bounce rate, and treat any ranking benefit as an upside rather than the business case. If rankings are the goal, content and SEO is where the budget belongs first.
My PageSpeed Insights score is 95. Why is Search Console saying my URLs are poor?
Because they are measuring different things. The 0–100 score is Lighthouse, a lab test running one simulated load on a standardised device and connection profile. Search Console reports field data: actual Chrome users on actual devices and networks, judged at the 75th percentile, which means a quarter of your visitors can have a worse experience than the threshold before you fail. A fast test machine on a fast connection will comfortably produce a 95 for a site that a mid-range Android phone on a congested mobile network struggles with. The field data is the number Google records against your site, so that is the one we work to.
Can a caching plugin do most of this for me?
It can do part of it, and it is usually worth having. Caching mainly improves time to first byte, which is one of the four LCP subparts and typically the one with the largest single share. What caching cannot touch is INP, because the JavaScript on your page still has to be downloaded, parsed and executed on the visitor's device no matter how quickly the HTML arrived. It also does nothing for layout shift. On plugin-heavy WordPress sites, responsiveness and layout stability are commonly where the failure actually sits, which is why caching alone so often produces a better lab score and an unchanged Search Console report.
Do you work on Shopify and other hosted platforms, or only WordPress?
Both, with an honest caveat about the difference. On WordPress we can change essentially anything: theme templates, the script loading order, the image pipeline, server and CDN configuration. On hosted platforms like Shopify and BigCommerce, parts of the stack are outside your control — the checkout, some platform scripts, certain aspects of asset delivery. There is still meaningful work available in theme code, app audits, image handling and third-party script discipline, and apps are frequently the largest single cost on a Shopify storefront. We will tell you on the scoping call which parts of your problem we can reach on your platform and which we cannot.
My site gets very little traffic. Is this service worth buying?
Probably not yet, and we would rather say so. The Chrome User Experience Report needs a minimum volume of visits before it will report on a URL or an origin, so a low-traffic site often has no field data at all — which means no Core Web Vitals assessment against it, and no way for us to prove a result. At that stage your growth is limited by demand rather than by page speed. Basic hygiene is still worth doing as part of a build or a redesign, where it costs very little extra. Come back to a dedicated speed engagement once there is enough traffic to measure.
What does it cost?
We quote a fixed price after a free scoping call rather than publishing package tiers, because the work scales with things a price list cannot see: how many distinct templates you run, how much third-party script is loaded, whether the platform permits the fixes, and whether there is a staging environment to work in. A five-template WordPress brochure site and a 200-SKU store with twelve apps are different jobs at the same headline description. The scoping call is genuinely free and genuinely non-obligatory, and if we think the answer is that your budget belongs elsewhere, we will say that on the call.
Will the improvement last?
Not without maintenance. Performance regresses through ordinary business activity: a plugin update, a new tracking tag for a campaign, a video added to a landing page, a theme update that re-enables something you had disabled. Because field data moves on a 28-day window, a regression introduced this week will not appear in Search Console until several other changes have also shipped, making attribution difficult. That is what the retainer is for. If you would rather handle it internally, the audit gives your team the baseline and the method, and we are happy for you to run it yourselves.
Find out whether speed is actually your problem
A free scoping call, no obligation. If your field data says the bottleneck is somewhere else, we will tell you that instead of selling you an audit.
Book a free consultationSources
- Web Vitals: the thresholds and the 75th percentile rule — web.dev
- Interaction to Next Paint (INP): thresholds and what counts as an interaction — web.dev
- INP becomes a Core Web Vital on March 12, 2024 — web.dev
- Optimize Largest Contentful Paint: the four subparts and their target shares — web.dev
- Optimize Interaction to Next Paint: input delay, processing duration, presentation delay — web.dev
- Understanding page experience in Google Search results — Google Search Central
- Vodafone: a 31% LCP improvement producing an 8% sales increase — web.dev case study
- The Economic Times: 43% bounce rate reduction after Core Web Vitals work — web.dev case study
- Chrome UX Report release notes, to August 2026 — Chrome for Developers
- Core Web Vitals pass rates by platform, April 2026, reading HTTP Archive's Technology Report — Search Engine Journal