Core Web Vitals are unusual among search signals in that they are measurable in the field, attributable to specific engineering causes, and still routinely unfixed. The reason is rarely that nobody knows what to do. It is that the fix belongs to a template, a render path or a server, and the person who diagnosed it does not own any of them.
Core Web Vitals sit in an awkward place organisationally. They are reported as a search metric, diagnosed against the render path, and fixed in the front end — three teams, one number. An SEO team can see that a template is failing and cannot change it. A front-end team can change it and has no reason to prioritise it over feature work. So the metric stays red, the reporting stays honest, and nothing moves.
You can see the failing templates in the field data and you have no route to the code. You need an engineering team that will take the metric as a brief.
You have been given a performance target expressed in search terms and need it converted into work with a cause, an owner and a measurable outcome.
The site feels slow and you need to know whether the cause is the front end, the network, the server or the platform — because those are four different budgets.
Performance was improved and has since regressed. You need the regression controlled rather than re-fixed.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The reporting continues and the remediation does not, because the metric is a search concern and the work is a front-end one. Nothing about that arrangement resolves itself with more time.
A synthetic test on a fast connection with a warm cache can be green while the field data for real devices on real networks is not. The users whose experience the metric describes are the ones outside the lab.
A performance improvement that is not monitored is a temporary state. The next feature addition, dependency or template change reverses it, and by the time it is noticed the cause is several releases back.
Slow and unstable pages reduce completion rates on the same pages they harm in search. The page-experience signal is often the smaller of the two costs, and the harder one to attribute.
Each of these is work we carry out, not an area we advise on.
Establishing what real users actually experience: the distribution per metric per page type, segmented by device and connection, from field data rather than a lab run. A distribution is the input — an average is not, because the engineering question is where the mass sits relative to the threshold and how much of it is beyond it.
Identifying which page types produce the failing distribution. On a templated site the fixes are few and the affected pages many, and a per-page list is the wrong shape of output for the same reason.
The render path for the largest element: how the resource is discovered, prioritised, served and painted, including image handling, font loading, critical CSS and server response time where it is the binding constraint.
What blocks the main thread during interaction: script execution and parsing, third-party tags, layout work under interaction and long tasks. INP is usually a JavaScript problem and is frequently a third-party one.
Reserving space for everything that arrives late — images without dimensions, injected content, web fonts, consent surfaces and embedded elements. CLS is the most tractable of the three when the cause is identified, and the hardest to identify from a lab run.
TTFB caps what any front-end work can achieve. Where the constraint is the origin — query cost, caching, application response — it is addressed there, which is an infrastructure engagement rather than a front-end one.
Performance work touches the render path, which is where a regression is most visible to users. Changes are released through the platform's own process with the ability to reverse them, rather than applied as a batch at the end.
Field data re-read after each change, not after the project. Field data lags by weeks, so a single measurement at the end attributes a quarter of work to one number and identifies nothing.
A performance budget expressed as an assertion in the release pipeline, so a regression is caught by the process rather than by the field data two months later. Without this step the project is a one-off.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
The metric under discussion is the experience of real users on real devices. That is a distribution with a tail, and the tail is normally where the problem is. Starting from a lab score produces a fix for the simulated user, who is not the one the metric measures.
Mobile against desktop, new against returning, fast connection against slow, first load against repeat. A metric that is red in aggregate and green on desktop is a different problem from one that is uniformly poor, and the two have different causes.
If TTFB is consuming most of the LCP budget, front-end optimisation cannot reach the threshold no matter how well it is done. Establishing which layer is actually constraining the metric is what stops a project spending its budget in the wrong place.
One change to a template applies to every page it generates. That is the only shape of fix that works on a large site, and it is also the only one whose effect can be measured — because a field-data shift across a page class is attributable, while a shift across individually-edited pages is not.
Field data responds slowly, so changes are made in identifiable steps and each is measured rather than bundled. A single release containing twenty changes produces one number and no explanation.
A budget assertion in the release pipeline, and monitoring that surfaces a regression while the cause is still recent. Performance that is improved and unguarded is a temporary condition, and the second project to restore it costs more than the guard would have.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Server response time, caching and application performance.
Platform reliabilityThe same subject from the engineering side, including budgets and full per-metric diagnosis.
Website performance engineeringThe other half of the technical picture.
Technical SEOCode-level execution, release validation and regression control.
Technical SEO implementationPlatform-specific performance work.
WordPress maintenanceLonger than most people expect, and that shapes how the work is sequenced. Field data is a rolling window of real user measurements, so it responds gradually — often over several weeks — and a single change may be invisible in aggregate for some time. That is why changes are made in identifiable steps and measured individually. Bundling a quarter of work into one release produces one number that cannot be attributed to anything.
They are a confirmed signal and they are a tiebreaker-class one rather than a dominant factor. The honest position is that passing them is worth doing and unlikely on its own to move a competitive ranking. Where we see it matter most is on pages that are otherwise comparable, and in the conversion effect on the same pages — which is usually larger than the search effect and easier to attribute. We will not tell you that fixing LCP will raise your rankings.
The field data. It describes what your actual users experienced on their actual devices and connections, and it is what search infrastructure measures. A green lab score on a fast connection with a warm cache says the page can be fast, not that it is. The usual reasons for the gap are device capability, network conditions, cold caches and third-party scripts that load differently for real visitors than in a test run.
Partially, and we will say which parts. A substantial share of Core Web Vitals problems are front-end and asset-level — image handling, script loading, font strategy, space reservation — and some of those can be addressed at the CDN or the theme layer without touching application code. The rest live in templates and build configuration, and those need code access or a team willing to merge our changes. Establishing which is which is part of the diagnosis rather than a question we can answer before it.
A budget assertion in the release pipeline, which is the only mechanism that has actually held in our experience. Monitoring tells you after the fact; an assertion prevents the release. The practical form is a check on build size, asset weight or a measured metric that fails the pipeline when it exceeds the agreed threshold. Without something of that shape, performance work is a project rather than a state, and the second project costs more than the guard would have.
It is the same subject seen from a different seat, and we would rather say that plainly than imply they are unrelated. That page is written for the engineering team that owns the stack: per-metric diagnosis, budgets, field-data method. This page is written for the search owner who has the metric as a search problem and needs an engineering team to act on it — so it focuses on the handoff, on what is attributable to which layer, and on what has to be in place for the gain to survive. If your reader is an engineer, send them there.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.