Your Lighthouse score is not your ranking signal. Google grades your site on real visitor data, at the 75th percentile, over a rolling 28 days. We optimise for that number, because that is the one that counts.
You run PageSpeed Insights, get a red score, install a caching plugin, and the number goes green. Nothing happens to your rankings. This is the single most common pattern we see.
One simulated test, on one simulated device, at one moment. Useful for debugging. Not used by Google’s ranking systems.
Measurements from real people on real phones and real connections, collected by Chrome. This is what feeds ranking, and what Search Console reports.
A page is judged at the 75th percentile, so three quarters of your visitors must hit the threshold. Being fast on average is not enough. You have to be fast for the slow tail.
That is also why fixes appear to do nothing for weeks. The field data window rolls over 28 days, so a change you shipped on Monday will not show in Search Console for the better part of a month.
A perfect Lighthouse score and a failing Core Web Vitals assessment can coexist on the same page. If your agency reports the first and not the second, they are reporting the wrong number.
Google’s thresholds are unchanged for 2026. Each is judged at the 75th percentile of real page views. Anything you read claiming the LCP bar moved this year is wrong.
Largest Contentful Paint
How long until the biggest thing in the viewport actually appears. Usually a hero image or headline. On more than 70% of pages the LCP element is an image, which is why image handling and server response time matter more here than anything else.
Interaction to Next Paint
How quickly the page visibly responds when someone taps, clicks or types. INP replaced First Input Delay in March 2024, and unlike FID it looks across the whole page lifecycle rather than the first interaction only. Any guide still discussing FID is out of date.
Cumulative Layout Shift
How much the page jumps around while loading. The classic failure is tapping a button that moves at the last moment. Almost always caused by images without dimensions, late-loading fonts, or embeds with no reserved space.
You do not get partial credit. Two green metrics and one amber is an overall fail. The weakest metric decides the grade, and mobile is nearly always the harder bar.
These thresholds are not arbitrary. Google tested candidate values against what well-optimised sites could actually sustain, and found 2.5 seconds was consistently achievable while 1.5 and 2 seconds were not. Demanding but reachable, deliberately.
Source: Google web.dev, Core Web Vitals documentation and threshold methodology.
WordPress powers a huge share of the web and lags most of its competitors on Core Web Vitals. Fewer than half of WordPress sites pass all three on mobile. Shopify and Wix both sit meaningfully ahead.
This is not because WordPress is slow. WordPress core is lean. The problem is what gets stacked on top of it.
The revealing detail
WordPress passes INP at around 86%, which is a strong number. The platform handles responsiveness well. What it fails is loading, which means LCP. That points at four causes, and none of them are JavaScript.
Slow server response time poisons LCP before a single byte of your design is involved. Nothing you do in the browser fixes a slow time to first byte.
Convenience has a weight cost, and it is paid on every single page load.
Twenty plugins each politely adding one stylesheet and one script is not twenty small problems. It is one large one.
Uploaded at full camera resolution, served unresized, in the wrong format, with no dimensions set.
Most WordPress speed work is therefore not clever. It is disciplined removal.
PHP version, time to first byte, object caching, database bloat and autoloaded options. If your server takes 800ms to think, your LCP budget is spent before anything renders. We measure this first because everything downstream depends on it.
Identifying the actual LCP element rather than guessing, then preloading it, setting fetch priority, resizing and converting images, self-hosting fonts, and stripping render-blocking CSS from the critical path.
Breaking up long JavaScript tasks, deferring and delaying non-critical scripts, and removing third-party tags nobody can justify. Chat widgets, heat maps and abandoned tracking pixels are frequent offenders.
Explicit width and height on every image, video and iframe. Reserved space for anything that loads late. Font loading configured so text does not reflow. Usually the cheapest of the three to fix.
Working out what each plugin actually loads, on which pages, and whether it earns its place. Conditional loading so a form script does not load on pages with no form.
Page caching, browser caching, compression and a CDN configured properly rather than switched on and hoped for. Caching is the last step, not the first. Caching a bloated page just serves the bloat faster.
We track field data over the 28-day window, not a screenshot of a lab score taken on the day we finished. You get to see whether the fix held.
We build on Elementor, so we will be straight about it. A page builder adds weight. Elementor typically adds a few hundred kilobytes of frontend assets over a plain build. That is a real cost and no amount of marketing changes it.
What it is not is a death sentence. Most Elementor performance problems are configuration problems, and they are fixable without rebuilding your site.
Elementor ships performance features that are off by default on older installs. Optimized DOM Output strips unnecessary wrapper divs. Improved Asset Loading stops unused JavaScript loading. Improved CSS Loading cuts unused styles. Inline Font Icons removes the Font Awesome request entirely, which alone is worth 70 to 100 milliseconds of render-blocking time.
Containers produce roughly 40% less HTML than the old sections and columns model. Nested containers wrapping single widgets, spacer widgets doing a padding job, and separate heading widgets where one block would do all inflate the DOM. We consolidate rather than decorate.
From experience
Elementor’s Element Caching genuinely speeds up rendering, and it has a trade-off nobody mentions. Cached elements are served from a stored copy with a time-to-live, so changes you make can sit invisible on the front end until that cache expires. We have run into this on live builds. If your site is under active development, you need to know this behaviour exists before it costs you an afternoon.
We start with Search Console and CrUX data, not a Lighthouse run. We establish which metric is actually failing, on which templates, on which device class. Most sites have one real problem, not thirty.
Time to first byte, PHP version, database health. If the foundation is the bottleneck, front-end work is wasted effort and we will tell you so before you spend money on it.
We do not optimise metrics that are already green. Effort goes to whichever vital is in the poor band, then to the next weakest.
We re-measure on field data. Because the window rolls over 28 days, we tell you upfront that confirmation takes weeks rather than hours.
You get a written record of what changed and why, so the next person who touches the site does not undo it.
We could get you one. It would involve stripping features you need and it would not reliably improve your rankings, because Google does not rank on that number. Anyone selling a guaranteed score is selling a screenshot.
Core Web Vitals are one signal among many. They act more like a tiebreaker between pages of similar quality than a lever that lifts weak content. Speed will not rescue a page that does not deserve to rank.
Sometimes the honest fix is to move host, and no optimisation work will substitute for it. We would rather say that than bill you for months of front-end tuning that cannot succeed.
On some sites the theme and plugin stack is so heavy that optimising it costs more than replacing it. We have built enough sites to have a reasonable sense of which situation you are in.
The evidence here is unusually good, because some of it comes from controlled tests rather than correlation.
better LCP produced 8% more sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate
Vodafone A/B test, published by Google
fall in bounce rate alongside a 13% rise in conversions, measured across roughly 10 million visits
Renault, published by Google
Vodafone ran their test on two landing pages that were visually and functionally identical. The only difference was that one had been optimised for Web Vitals. Both are published Google case studies rather than agency estimates, and the pattern is consistent: loading performance moves commercial outcomes, and it does so independently of any ranking benefit.
Pricing
Speed work is priced by what we find, not by package tier. A site failing CLS because of missing image dimensions is an afternoon. A site failing LCP because of a slow host and a heavy theme is a different conversation. That is why we audit before we quote. You get the findings, a fixed price for the work, and a clear statement of what we cannot fix within it.
Speed audit
Find out what is actually failing
Free
No obligation
Fix and retest
A site failing one or two metrics
Quote
One off, plus VAT
Rebuild for speed
A site too heavy to rescue
Quote
One off, plus VAT
Why we audit before quoting
Quoting speed work blind is guesswork, and guesswork gets corrected upward later. The audit costs you nothing and tells us whether this is an afternoon or a rebuild before either of us commits to a figure.
What we will not promise
A perfect score. Scores are a diagnostic, not the goal, and chasing one can make a site worse for real visitors. What we aim at is passing the thresholds Google actually uses on real visitor data.
A fast site slows down again as plugins update. Looking after it starts at £25 a month.
See care plansBecause they measure different things. PageSpeed’s headline score is a lab simulation. Search Console reports field data from real visitors at the 75th percentile. Field data is what feeds ranking.
Technical changes take effect immediately. Confirmation does not. Core Web Vitals are assessed over a rolling 28-day window, so allow four to six weeks before judging whether a fix worked.
Sometimes, partly. Caching helps repeat delivery but cannot fix a slow server, oversized images, layout shift or heavy JavaScript. No plugin fixes slow hosting.
No. It makes it harder and it makes configuration matter more. Properly configured Elementor sites pass regularly. Badly configured ones do not, and neither do badly configured sites on any other stack.
Yes, as part of Google’s page experience signals. It is best understood as a tiebreaker rather than a primary lever. Content relevance still outranks it.
Usually yes, for server-level work. If you would rather not grant it, we can still do front-end optimisation and will be clear about what that leaves on the table.
Then we tell you and you keep your money. We would rather have the referral.
We will run a free speed audit using your real visitor data. You get the failing metric identified, the cause traced, and an honest answer on whether it is worth paying anyone to fix.
No obligation. No sales sequence.