Sites that load fast and convert
Custom builds and integrations
Bounded, auditable, human-approved
Being found, staying fast, staying safe
Core Web Vitals put numbers on three things a visitor actually feels: how long before the main content appears, how long the page takes to respond when they tap something, and whether the layout jumps around while they are trying to read it.
Those numbers matter to search rankings, mildly. They matter to whether people stay and buy, considerably more. We work on the second and treat the first as a useful side effect, which also means we optimise the pages your visitors land on rather than the ones that score badly.
Drag across the filmstrip ↓The three numbers
Three metrics, each with published thresholds, each describing a different kind of frustration. A page passes only when seventy-five per cent of real visits clear the "good" bar on all three.
How long until the biggest thing on screen — usually the hero image or headline — has finished drawing. It is the closest proxy for "the page has loaded" as a person experiences it.
How long after a tap or click before the page visibly responds. This replaced First Input Delay in 2024 and is much harsher, because it measures every interaction rather than only the first.
How much the page moves around while loading. It is the reason you tap the wrong button when an ad or image arrives late and shoves everything down the screen.
Interactive
A typical unoptimised page, short of the pass mark on all three metrics. Switch fixes on and watch the waterfall shorten and the numbers move into the green.
Two things to notice. The image work does most of the heavy lifting for LCP, and it is usually the cheapest item on the list. And the chat widget alone accounts for a meaningful share of all three numbers — which is an awkward conversation, because somebody in marketing chose it deliberately.
Interactive
Layout shift is the hardest of the three to picture, so here is one running. Press replay and watch the buttons move just as you would be reaching for them.
The fix is not clever engineering. It is telling the browser how much space to leave — dimensions on images, a reserved slot for the banner, fonts that do not swap to a different size on arrival. Switch to "space reserved" and run it again.
Coverage
Performance plugins help and they are not the work. Most of the real gains come from images, the server, the JavaScript bundle and whatever third parties were added over the years.
Measurement
Delivery & caching
Frameworks tuned
Platforms optimised
Causes
In rough order of how often they turn out to be the main culprit. The first is nearly always in the top two.
A four-megabyte image scaled down by the browser to six hundred pixels wide. The visitor downloads all four megabytes and sees none of the benefit.
Cheapest fix, largest single gain
Chat widget, two analytics tools, a heatmap recorder, three ad pixels and a review badge. Each was a reasonable decision; collectively they are the page.
Needs a business decision, not just a technical one
If the server takes a second to send the first byte, every other optimisation begins a second late. Usually cheap hosting, an uncached database query, or a plugin doing work on every request.
Invisible in most audits
A bundle containing every component on the site delivered to a visitor who wanted one page. The main thread is busy parsing it when they try to tap something.
Most common on single-page applications
Images without dimensions, banners inserted at the top, fonts that swap to a different size on arrival. The page assembles itself while the visitor is trying to use it.
Usually a day of work
Thirty stylesheets, a dozen scripts, and a slider nobody uses on every single page. Sometimes tunable, sometimes genuinely the reason a site cannot be made fast.
Where we sometimes recommend a rebuild
Honesty
This field runs on a vanity number, and the number is not the thing you care about.
A perfect Lighthouse score is a lab simulation on one page on a simulated connection. Real visitors on real devices are what the field data measures, and the two frequently disagree.
Speed is a genuine ranking signal and a weak one. A fast page with poor content will not outrank a slow page that answers the question better. The real return is conversion.
The single biggest gain is often removing a marketing tool. That is not a technical call, and we will present the cost rather than making it for you.
Core Web Vitals reporting uses a rolling twenty-eight day window, so improvements deployed today will not show fully for about a month. Nothing is wrong; it is just slow.
Caching and optimisation plugins help at the margin and occasionally break things. They do not fix oversized images, a slow server or a heavy theme.
On a few sites the theme or page builder makes real performance unreachable. We will say so plainly rather than billing for months of incremental tuning.
Scope
Field data first, because it tells you which pages and which devices actually have the problem.
What real visitors experience, split by page type and by device, so effort goes where the traffic and the failures overlap.
Traces of the pages that matter, identifying what specifically delays the largest paint and what blocks the main thread.
Resizing, modern formats, correct lazy-loading, and a process so new uploads are handled automatically rather than manually.
Every external script listed with its measured cost, so the keep-or-cut conversation happens with numbers attached.
Time to first byte, cache configuration at each layer, and a CDN where it genuinely helps rather than by default.
Splitting bundles, deferring what is not needed immediately, and reducing the main-thread work that drives poor INP.
Dimensions, reserved slots and font loading, so nothing moves after the visitor has started reading.
Before and after on both lab and field, with the field figures revisited a month later once the rolling window has caught up.
A performance budget and monitoring, so the next theme update or marketing tag is caught rather than discovered next year.
Questions
Possibly bad, possibly misleading. That score is a lab test of one page on a simulated slow device, and it is deliberately harsh.
The number that matters is field data from real visitors, in Search Console under Core Web Vitals. We look at that first, and sometimes it is considerably healthier than the lab score suggests.
A little, honestly. Speed is a real but modest ranking signal, and it matters most when competing pages are otherwise similar.
The larger return is that fewer people abandon the page before it loads. That shows up in conversions rather than positions, which is the harder thing to attribute and the more valuable one.
Lab measurements change the moment the work is deployed. Field data uses a rolling twenty-eight day window, so it improves gradually over about a month.
That gap causes a lot of unnecessary worry, so it is worth knowing before you start refreshing the report.
We often will, because it helps. It will not fix four-megabyte images, a slow server or six third-party scripts, which are usually where the time actually goes.
Plugins are a component, not a strategy, and a badly configured one causes its own problems.
No — but you should see what it costs. Chat widgets, heatmap recorders and tag managers are frequently among the heaviest things on a page.
We measure each one and present the trade-off. Loading it after the page is interactive often keeps the tool and most of the speed.
Interaction to Next Paint replaced First Input Delay in March 2024. The old metric only measured the delay before the first interaction was handled; INP measures responsiveness across the whole visit.
It is a fairer measure and a harsher one, and a number of sites that comfortably passed the old metric now fail this one.
Mobile is the priority. Field data is reported separately for mobile and desktop, and mobile is almost always the weaker of the two.
It is also where most local and commercial traffic arrives, so it is where the work is aimed.
Usually not. Most sites have a great deal of recoverable performance sitting in images, third-party scripts and server configuration.
Occasionally a theme or page builder puts a hard ceiling on what is achievable. We will tell you when that is the case instead of billing indefinitely against it.
Call back
Leave a number and a good time. We will call you back to talk about what you are trying to build — no charge for the conversation.
Or call us directly +1 (647) 385-5532