Short answer
Core Web Vitals measure loading, responsiveness and visual stability from real users. They influence search modestly, but the direct business impact is larger: slow or unstable pages lose visitors during the moments where intent is highest.
Key takeaways
- LCP, INP and CLS map to three distinct engineering problems with different fixes.
- Field data beats lab scores — optimise for what real users experience.
- Most performance debt is third-party scripts nobody has audited in two years.
- Set a budget and enforce it in CI, or the wins quietly erode.
Performance work is easy to defer because it never looks like a feature. It becomes urgent when someone finally connects the mobile bounce rate to the four-second hero image.
The three metrics, plainly
LCP — Largest Contentful Paint
How long until the main thing appears. Usually a hero image, a heading or a video poster. Slow LCP is normally a server response time problem, an unoptimised image, or a render-blocking resource sitting in front of it.
INP — Interaction to Next Paint
How quickly the page responds when someone taps or types. Poor INP means the main thread is busy — typically too much JavaScript executing at the wrong moment. This is the metric most sites now fail.
CLS — Cumulative Layout Shift
How much the page moves while loading. Every mistapped button caused by a late-arriving banner is a CLS problem, and it is nearly always preventable by reserving space.
Where the time actually goes
- Images shipped at desktop dimensions to phones, in formats a decade out of date.
- Web fonts loading without a fallback strategy, so text is invisible or reflows late.
- Third-party tags — chat widgets, heat maps, ad pixels, abandoned A/B tools — each adding main-thread work.
- Client-side rendering of content that could have been rendered on the server.
- Animation libraries loaded on every page to power one effect on the homepage.
A performance budget that survives
Optimisation without a budget is temporary. Someone adds a tag, a hero video, another font weight, and six months later you are back where you started. The fix is procedural, not technical.
- 01Agree targets per template — for example LCP under 2.5s and INP under 200ms on a mid-range mobile device.
- 02Measure in CI on every pull request, and fail the build when a budget is breached.
- 03Require a named owner and an expiry date for every third-party script.
- 04Review field data monthly alongside conversion data, not in a separate performance meeting.
Making the case internally
Do not lead with metric names. Lead with the funnel: how many people leave before the page becomes usable, what those sessions were worth, and what a one-second improvement is plausibly worth against that. Speed sells when it is framed as recovered revenue rather than as a score.
Related questions
- How much do Core Web Vitals affect rankings?
- They are one signal among many and rarely decisive against clearly better content. Treat them as a tiebreaker for search and as a direct driver of user behaviour, which is the bigger effect.
- Is a perfect score necessary?
- No. Passing the thresholds for real users on real devices is the goal. Chasing a synthetic 100 usually costs more than it returns.
- What is the fastest single improvement for most sites?
- Auditing and removing unused third-party scripts, followed by serving correctly sized modern-format images. Together they resolve a large share of LCP and INP failures.
Sources
Want this applied to your business?
We'll look at where you stand today and what the highest-impact next move actually is.
