Performance work stalls for a predictable reason: the metrics are owned by engineering, the budget is owned by product, and neither side can translate "LCP 4.2s" into a business argument. This guide is aimed at that gap — what the three metrics mean, what usually causes a bad score, and how to decide whether fixing it is worth a sprint.
The three metrics
LCP — Largest Contentful Paint. How long until the biggest visible element (usually a hero image or headline) finishes rendering. This is the user's sense of "the page loaded."
- Good: ≤ 2.5s · Needs improvement: 2.5–4.0s · Poor: > 4.0s
INP — Interaction to Next Paint. How long the page takes to visually respond to a user interaction, measured across the whole visit rather than just the first click. This is the user's sense of "the page is responsive." INP replaced FID because first-input latency flattered pages that were fast to accept the first tap and sluggish thereafter.
- Good: ≤ 200ms · Needs improvement: 200–500ms · Poor: > 500ms
CLS — Cumulative Layout Shift. How much content moves around unexpectedly while loading. This is the user's sense of "I tapped the wrong thing."
- Good: ≤ 0.1 · Needs improvement: 0.1–0.25 · Poor: > 0.25
Assessment uses the 75th percentile of real users, so optimising your own laptop experience proves nothing. If a quarter of your users are on a mid-range Android over LTE, they set the number.
Lab vs field data — the distinction that ends most arguments
Lab data (Lighthouse, PageSpeed Insights' lab section) is a simulated run on one page in a controlled environment. It is reproducible and diagnostic, and it tells you what to fix.
Field data (Chrome UX Report, Search Console's Core Web Vitals report, your own RUM) is what real users experienced over the last 28 days. It is what gets assessed, and it is what to report.
When engineering says "Lighthouse scores 95" and support says "the site is slow", both are usually right. Lighthouse ran on a fast connection against a warm cache; the complaints come from the 75th percentile. Report field data to stakeholders; use lab data to find the cause.
What actually causes each failure
LCP is slow because of:
- Slow server response (TTFB). Everything else waits on this. Anything over ~600ms deserves attention before image work.
- An unoptimised hero image — the single most common cause. Modern format, correct dimensions,
priorityloading. - Render-blocking CSS and fonts in the
<head>. - The LCP element being lazy-loaded, which delays the very thing being measured.
- Client-side rendering: if the hero only exists after hydration, LCP includes the whole JavaScript pipeline. See JavaScript rendering and crawlability, which is the same root cause viewed from the SEO side.
INP is poor because of:
- Long JavaScript tasks blocking the main thread — usually third-party tags, analytics, chat widgets and A/B testing scripts.
- Heavy event handlers doing layout work synchronously.
- Large React re-renders triggered by a small state change.
- Too many third-party scripts, full stop. Audit what is actually loaded; most sites carry at least one tag nobody can justify.
CLS is poor because of:
- Images and iframes without width/height or
aspect-ratio. - Ads and embeds injected into un-reserved space.
- Web fonts swapping and reflowing text.
- Banners, cookie notices and promo bars inserted above existing content after load.
CLS is usually the cheapest of the three to fix and the most visible to users.
Prioritising against the rest of the backlog
Performance competes with features, and "it's a ranking factor" is a weak argument on its own — Core Web Vitals is a real but small ranking signal. The stronger arguments:
- Conversion. Slow pages lose sessions before they can convert. Measure it on your own site: segment your analytics by LCP bucket and compare conversion rates. A two-fold difference is common, and it is a number a stakeholder can act on.
- Crawl efficiency. Faster responses raise the crawl rate limit, which matters on large sites (crawl budget optimization).
- Cost. Smaller payloads mean lower bandwidth and CDN spend, which is a line item somebody already owns.
A pragmatic sequence:
- Sprint 1 — Measure. Instrument RUM, pull the Search Console report, and segment by template: home, category, detail, checkout. Fix the worst template, not the site average.
- Sprint 2 — CLS. Cheapest fixes, immediately visible, low regression risk.
- Sprint 3 — LCP on the highest-traffic template. Usually image optimisation plus TTFB.
- Ongoing — INP. This is architectural and rarely fits in one sprint; treat it as a budget you defend rather than a project you finish.
Setting a budget that holds
Agree numbers before the work starts, and enforce them in CI:
| Metric | Budget | Enforcement |
|---|---|---|
| LCP (p75, field) | ≤ 2.5s | Monthly review |
| INP (p75, field) | ≤ 200ms | Monthly review |
| CLS (p75, field) | ≤ 0.1 | Monthly review |
| JS bundle (initial) | ≤ 200KB gzipped | CI check, blocks merge |
| Hero image | ≤ 150KB | Build lint |
| Third-party scripts | ≤ 5 | Quarterly review with owners named |
The CI checks are what keep the gains. Without them, performance regresses one small addition at a time and you rerun the whole project in eighteen months.
FAQ
How much do Core Web Vitals affect rankings?
They are a confirmed but lightweight signal, and they act as a tiebreaker between comparable pages rather than as a substitute for relevance. Better content on a slower page usually still wins. Optimise for users and conversion; treat the ranking effect as a bonus.
Why does my Lighthouse score disagree with Search Console?
Lighthouse is a single simulated run (lab); Search Console reports 28 days of real users at the 75th percentile (field). They measure different things and will not match. Trust field data for assessment.
Is a Lighthouse score of 100 the goal?
No. The score is a weighted composite of lab metrics on one run. Passing the three field thresholds for real users is the goal; a perfect lab score with failing field data helps nobody.
How long after a fix does field data update?
Chrome UX Report data is a rolling 28-day window, so a fix deployed today is fully reflected in about four weeks. Watch RUM for immediate confirmation that the change landed.
What is the fastest single win?
Usually the hero image: correct dimensions, modern format, eager loading with high priority, and a preload hint. On most sites that alone moves LCP by a second or more.