Core Web Vitals: LCP, INP and CLS explained
Core Web Vitals are the three field metrics Google defines to measure the user experience of a page: loading (LCP), interaction (INP) and visual stability (CLS). This guide gives the definition of each, the published thresholds, the difference between field and lab data, and the order in which they should be fixed — with sources.
What are Core Web Vitals, in one paragraph?
Core Web Vitals are three field metrics: LCP measures loading, INP measures interaction, CLS measures visual stability. Google's good thresholds are LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less. Each is assessed at the 75th percentile of real user data. Lab measurement gives direction; the decision is made on field data.
This page is reference material, not sales material. Every numeric claim on it carries its source and access date on the line below it; a number without a source is not published on this site. For the commercial equivalent of this work, see Core Web Vitals and performance engineering.
What are Core Web Vitals?
Core Web Vitals are the three field metrics Google defines to measure the user experience of a page: LCP measures loading speed, INP measures interaction responsiveness, CLS measures visual stability. The values are collected from the visits of real Chrome users rather than from synthetic tests, and are assessed at the 75th percentile of page views. A page that is not in the good range on all three does not pass.
Calling these metrics “core” does not mean they are the only things measured. TTFB (time to first byte), FCP (first contentful paint) and TBT (total blocking time) are diagnostic metrics: they carry no threshold of their own, but they explain why one of the three core metrics is failing. In practice the work is measured with the core metrics and executed with the diagnostic ones.
The three metrics defined
LCP — Largest Contentful Paint
LCP measures the moment the largest text block or image inside the viewport is painted, counted from the start of page load. It is the measurement closest to the point at which a user would say the page has opened.
Why it matters: on corporate sites the LCP element is usually a product image or a heading block. A catalogue page that stays blank for two seconds is abandoned before supplier evaluation has even begun.
INP — Interaction to Next Paint
INP measures the responsiveness of click, tap and keyboard interactions across the whole visit, and generally reports the slowest one. The duration covers everything from the interaction until the screen is next updated.
Why it matters: submitting a form, applying a filter and adding to a basket all sit inside this metric. A slow response makes the user believe the page is broken and makes them click a second time.
CLS — Cumulative Layout Shift
CLS measures the visual instability caused by page elements moving without any user action. It is a unitless score, based on the largest burst of shifts recorded during the visit rather than on a running total.
Why it matters: a button that moves produces a mis-click. On a request-for-quote form that means a completed form is lost, and it appears in analytics as an abandonment rather than as an error.
Published threshold values
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading | 2.5 s or less | 2.5–4.0 s | Over 4.0 s |
| INP | Interaction | 200 ms or less | 200–500 ms | Over 500 ms |
| CLS | Visual stability | 0.1 or less | 0.1–0.25 | Over 0.25 |
Source: Google web.dev — Web Vitals (opens in a new tab) · Accessed: 29.07.2026
What is LCP and why does it get slow?
LCP is the moment the largest content element in the viewport is painted, and its good threshold is 2.5 seconds. What makes it slow is usually not the size of the image but when the image is discovered: if the browser only learns about that resource after CSS or JavaScript has run, the download starts late and the duration grows from there.
LCP splits into four sub-parts. Any improvement made without knowing which part dominates is guesswork:
| Sub-part | What happens | Typical remedy |
|---|---|---|
| Time to first byte (TTFB) | Time until the first byte of the document arrives | Caching, edge delivery, cutting query and template cost |
| Resource load delay | The browser cannot see the LCP resource in the HTML and learns of it later | Move the resource into the HTML, use preload and fetchpriority |
| Resource load duration | The file itself takes a long time to come over the network | Modern format, correct dimensions, compression, removing unused variants |
| Element render delay | The resource arrived but the main thread was too busy to paint it | Removing render-blocking CSS and JavaScript, inlining critical CSS |
Source: Google web.dev — Optimize LCP (opens in a new tab) · Accessed: 29.07.2026
On corporate sites we see the same three patterns again and again: the LCP image declared as a CSS background, the first frame of a carousel generated by JavaScript, and an above-the-fold heading that stays invisible until the web font arrives. In all three cases the file size is reasonable and the duration is long. The absence of an image in the hero of this site is not an accident but a design decision taken against those three patterns: the LCP element here is text.
What is INP and how does it differ from FID?
INP measures the response time of every click, tap and keypress across a visit and generally reports the slowest one; its good threshold is 200 milliseconds. FID only measured the input delay of the first interaction, not the completion of the work. INP replaced FID as a Core Web Vital on 12 March 2024.
| Criterion | FID (retired) | INP (current) |
|---|---|---|
| Interactions covered | The first interaction only | Every interaction across the visit |
| Duration measured | The delay before processing begins | The entire time from the interaction to the next paint |
| Good threshold | 100 ms or less | 200 ms or less |
| Practical consequence | Looked good on most sites and hid the problem | Makes heavy interactions such as filters, forms and baskets visible |
Source: Google web.dev — INP is officially a Core Web Vital (opens in a new tab) and Chrome ends support for First Input Delay (opens in a new tab) · Accessed: 29.07.2026
The transition timetable is documented as well: FID was removed from Search Console on 12 March 2024, and other Google tools were given a transition period that ran until 9 September 2024. If a dashboard in your organisation still reports on FID today, it is reporting on a metric that has been retired for two years.
What breaks INP is rarely a single defect; it is accumulation. Tracking scripts added through a tag manager, a chat widget, a campaign countdown and a filter component all share one main thread. Measured individually each looks innocent; running together they cross 500 milliseconds.
What is CLS and how do you get it to zero?
CLS is the unitless score for visual instability produced when page elements move without any user action; its good threshold is 0.1. You do not get it to zero by measuring but by reserving space: giving every image its dimensions, reserving room for embedded content and matching fallback font metrics to the real font prevents the shift from occurring at all.
CLS has four classic sources: images published without dimension attributes, advertising and embed slots with no space reserved, announcement bars and consent banners injected above existing content after load, and line-height changes as the page swaps from the fallback font to the web font. All four can be checked before release; none of them requires waiting for user data.
Two subtleties matter when measuring. First, CLS is not limited to the first screen; shifts that happen as the user scrolls are counted too. Second, the score is not a total but the largest burst of shifts within the visit. That is why work which only fixes the first screen fails to deliver the expected improvement in field data.
Source: Google web.dev — Cumulative Layout Shift (opens in a new tab) · Accessed: 29.07.2026
Why do field data and lab data disagree?
Lab data is a synthetic measurement produced on one device, one fixed network and a single load; because it is repeatable it suits debugging. Field data carries the real variety of user devices, networks and cache states, and is published as a 28-day rolling window. That is why the decision is made on field data.
| Criterion | Field data (CrUX, real user monitoring) | Lab data (Lighthouse, DevTools) |
|---|---|---|
| Source | Real, eligible Chrome users | One device with emulated network and CPU |
| Time window | 28-day rolling window | A single run, instantaneous |
| Can INP be measured? | Yes, from genuine interactions | No; diagnostic metrics such as TBT are used instead |
| What it is used for | Diagnosis, prioritisation, acceptance decision | Root cause analysis, fast feedback while fixing |
| When the result appears | After release, once the data window fills | The same minute |
Source: Chrome for Developers — CrUX API (opens in a new tab) · Accessed: 29.07.2026
The practical consequence is this: a screenshot of a hundred-point score taken on release day is not proof. You cannot declare an improvement before field data has accumulated, because the measurement window still contains the days before the fix. If that waiting period is not written into the plan at the start, the outcome of the work becomes a matter of argument at the end.
Which measurement tool is used for what?
Field tools establish the state; lab tools explain the cause. The Chrome User Experience Report and real user monitoring give the real picture; Search Console prioritises the same data by URL group; PageSpeed Insights puts both side by side; Lighthouse and the DevTools performance panel find the root cause. Work run with a single tool stays incomplete.
| Tool | Data type | What it is used for |
|---|---|---|
| Chrome User Experience Report (CrUX) | Field | Establishing the real state; 28-day distribution by origin and URL |
| Real user monitoring (your own) | Field | Breakdown by template, device, country and release; pages absent from CrUX |
| Search Console — Core Web Vitals report | Field | Prioritising URL groups by similar page patterns |
| PageSpeed Insights | Field + lab | Reading both data types side by side for one address |
| Lighthouse | Lab | Pre-release checks and fast verification after a fix |
| Chrome DevTools performance panel | Lab | Finding long tasks, critical request chains and shift sources |
The order is: see the problem in field data, find the cause in the lab, fix it, verify in the lab, confirm in the field. Reverse that loop — raise the lab score and stop there — and the page stays good in the tool and poor for the user.
How does speed affect business outcomes?
There is no single valid formula for the effect of speed on business outcomes; sector, funnel and device mix all change the result. What exists is the measurements individual companies have published for their own sites. All four findings below are sourced and most were produced through A/B testing; none of them transfers directly to your page.
The total sales increase Vodafone measured after improving its LCP by 31%. In the same test, visit-to-lead conversion rose 15% and visit-to-basket conversion rose 11%.
Source: Google web.dev — Vodafone case study (opens in a new tab) · Accessed: 29.07.2026
The increase in revenue per visitor Rakuten 24 measured after a Core Web Vitals optimisation programme. In the same work, conversion rate rose 33.13% and average order value rose 15.20%.
Source: Google web.dev — Rakuten 24 case study (opens in a new tab) · Accessed: 29.07.2026
The rise in page views per session Yahoo! JAPAN News measured after bringing CLS down from roughly 0.2 to 0. Session duration lengthened by 13.3% and bounce rate fell by 1.72 points.
Source: Google web.dev — Yahoo! JAPAN News case study (opens in a new tab) · Accessed: 29.07.2026
The effect of a 0.1-second mobile speed improvement on retail conversion; average order value rose 9.2% in the same study. Conducted by Deloitte across more than 30 million sessions from 37 European and American brands.
Source: Google web.dev — Milliseconds make millions (Deloitte) (opens in a new tab) · Accessed: 29.07.2026
What do these numbers say about your page?
They do not give you a forecast. What they say is that four independent measurements all point the same way, and that the size of the effect grows on the pages where the user is closest to a decision. That is why we start this work at the enquiry form, the product detail page and the category listing — not at the home page.
On rankings we make no inflated promise. Google states that page experience signals are used in its ranking systems, but that a good experience does not push irrelevant content forward. In practice, speed is a differentiator between pages of similar relevance. Our commitment is a measurable metric target, not a ranking position.
We publish our own site's measured values under the same rule: with the tool name, the measurement profile and the measurement date, on the Proof page. No line that cannot be measured is published on this site.
In what order should LCP, INP and CLS be fixed?
The order starts with measurement, not with assumptions. First a template-level distribution is derived from field data, then the three highest-value templates are chosen. LCP is split into its four sub-parts, CLS is closed at source, long tasks are broken up for INP, third-party scripts are inventoried, and the budget is wired into the release pipeline.
-
01
Start in the field, not in the lab
Collect real user data first: CrUX and, where possible, your own real user monitoring. Produce a distribution by page template and device class, not a single score. Lab measurement is used to explain that distribution; it does not stand in for it.
-
02
Pick the template, not the page
On corporate sites the problem sits in the template, not in a single page. Choose the three templates with the most traffic and the shortest distance to conversion: product or service detail, category listing, form. A template fix moves hundreds of pages together; a single-page fix stays too small to measure.
-
03
Identify the LCP element and split it into four
First establish which element actually is the LCP element; this is where most assumptions turn out wrong. Then split the duration into four parts: time to first byte, load delay, load duration and render delay. Whichever part is largest is where the work begins.
-
04
Close CLS at source
Do not repair shifts after the fact, prevent them: give every image and video a width and height or an aspect ratio, reserve space for advertising and embeds in advance, and tune fallback font metrics against the real font. CLS is the only metric you can close before release without waiting for user data.
-
05
Break up long tasks for INP
Measure and break up tasks that hold the main thread for more than 50 milliseconds. Do not run heavy work inside event handlers, do not make the user wait for visual feedback, and defer the computation. Because INP only exists where real interaction exists, you work in the lab with diagnostic metrics such as TBT and verify in the field.
-
06
Inventory every third-party script
List tag managers, chat widgets, heat maps and advertising scripts one by one. Measure the main-thread time each one costs and write down its owner and its business justification. A script without a justification is removed; a necessary one is deferred or moved behind consent. This step usually produces the largest INP gain.
-
07
Wire the budget into the release pipeline
Write the numeric limits the page may not exceed and attach them to an automated pre-release check: a change that breaks the budget does not ship. Then monitor field data on a schedule. Skip this step and the gain is reversed within a few releases; performance does not stay put on its own.
How do you set a performance budget?
A performance budget is a set of numeric limits a page may not exceed, and it comes in three kinds: metric limits, resource weight limits and request count limits. A budget is not a document but an automated check running in the release pipeline. A change that breaks a limit does not ship; without that mechanism, optimisation is reversed within a few releases.
The table below is the budget enforced in this site's own release pipeline. It was not written as an illustration: the build step checks these limits on every release and stops the build when one is exceeded.
| Item | Limit | Limit type |
|---|---|---|
| LCP (mobile) | < 1.8 s | Metric |
| CLS | < 0.05 | Metric |
| INP | < 200 ms | Metric |
| Inline critical CSS | ≤ 9 KB gzip | Resource weight |
| Total CSS | ≤ 30 KB gzip | Resource weight |
| Total JavaScript | ≤ 12 KB gzip | Resource weight |
| Web fonts | 2 files · ≤ 60 KB | Resource weight |
| Above-the-fold images | 0 | Request count |
| Third-party requests (before consent) | 0 | Request count |
Three rules help when writing a budget: set the limit slightly below today's value (an unreachable budget is ignored), name a measurement tool for every limit, and decide in advance what happens when a change breaks one. For the commercial equivalent of this work: Core Web Vitals and performance engineering.
What are the seven most common mistakes?
The most common mistake is treating a lab score as field data. It is followed by reading averages, misidentifying the LCP element, measuring CLS only on the first screen, looking for INP in the lab, trying to solve everything with image compression, and optimising without a budget. All seven share a common root: they are measurement errors, not coding errors.
- Treating a lab score as field data. A high Lighthouse score taken on release day does not describe the experience real users are having; the decision belongs to field data.
- Reading the average. Thresholds are assessed at the 75th percentile. The average can look good while a quarter of users sit in the poor band — and that is exactly where the loss occurs.
- Misidentifying the LCP element. Most teams assume it is the hero image; measurement frequently points to a heading block or the second frame of a carousel. Improving the wrong element changes nothing.
- Measuring CLS only on the first screen. Shifts also occur as the user scrolls, and the score comes from the largest burst within the visit. Fixing the first screen is usually not enough.
- Looking for INP in the lab. INP only occurs through genuine interaction. In the lab you work with diagnostic metrics such as TBT; concluding “there is no INP in the lab, so there is no problem” is wrong.
- Trying to solve everything with image compression. On most corporate sites, shrinking images touches the smallest sub-part of LCP; the real time sits in the server response and in late resource discovery.
- Optimising without a budget. An improvement that is not wired into the release pipeline is undone by the first tag or component added afterwards. Durability comes from a mechanism, not from discipline.
An 18-item pre-release checklist
These eighteen items are what needs checking before a page can be considered ready for release on Core Web Vitals: six for LCP, four for CLS, four for INP and four for measurement and budget discipline. The box at the end of the list lets you copy the whole thing into your own release checklist.
LCP · 6 items
- The LCP element has been identified and recorded in writing for every main template.
- The LCP resource is discoverable in the HTML; it is not a CSS background and is not injected later by JavaScript.
- The LCP image is marked
fetchpriority="high"and is not markedloading="lazy". - Render-blocking CSS and JavaScript have been removed; the CSS needed above the fold is inlined.
- Server response time has been measured and the caching policy has been written down and verified.
- Web fonts are self-hosted, preloaded, and a
font-displaystrategy has been decided.
CLS · 4 items
- Every image and video element declares a width and height or an aspect ratio.
- Space is reserved in advance for advertising, maps and embedded content.
- Fallback font metrics are tuned to the real font; the font swap produces no shift.
- No announcement, bar or banner is pushed above existing content after load.
INP · 4 items
- Tasks longer than 50 milliseconds have been measured and broken up.
- Event handlers do no heavy work; computation is deferred until after the next paint.
- Every third-party script is in the inventory with its owner, justification and main-thread cost.
- Visual feedback for a user interaction is given before the heavy work completes.
Measurement and budget · 4 items
- Measurement uses both field and lab data; the acceptance decision is made on field data.
- Values are read at the 75th percentile, with mobile and desktop read separately.
- The performance budget is written down and checked automatically in the release pipeline.
- Field data is monitored on a schedule after release, and any regression is reported to a named owner.
CORE WEB VITALS · PRE-RELEASE CHECKLIST (18) # LCP - [ ] 01 LCP element identified and documented per template - [ ] 02 LCP resource discoverable in the HTML - [ ] 03 fetchpriority="high" set, loading="lazy" not set - [ ] 04 Render-blocking CSS/JS removed, critical CSS inlined - [ ] 05 Server response time measured, caching policy written - [ ] 06 Fonts self-hosted, preloaded, font-display decided # CLS - [ ] 07 width+height or aspect-ratio on every image/video - [ ] 08 Space reserved for ads, maps and embeds - [ ] 09 Fallback font metrics matched to the real font - [ ] 10 No post-load banner pushing content down # INP - [ ] 11 Tasks over 50 ms measured and broken up - [ ] 12 Event handlers light, computation deferred - [ ] 13 Third-party inventory: owner, justification, cost - [ ] 14 Visual feedback given before heavy work completes # MEASUREMENT AND BUDGET - [ ] 15 Field + lab together; decision made on field data - [ ] 16 Values read at the 75th percentile, mobile and desktop apart - [ ] 17 Performance budget written and automated in the pipeline - [ ] 18 Field data monitored after release, regressions reported
What do the terms used in this guide mean?
Thirteen technical terms appear in this guide. Each one has a short, self-contained definition in our digital visibility glossary, with its own anchor. The list below summarises those definitions; for the full wording, related terms and usage examples, follow the glossary entries.
- Core Web Vitals — the collective name for the three field metrics LCP, INP and CLS.
- LCP — the paint time of the largest content element in the viewport.
- INP — the time from an interaction to the next screen update.
- FID — the retired metric INP replaced, which measured first input delay.
- CLS — the unitless score for layout shifts not caused by the user.
- TTFB — time to first byte; the first sub-part of LCP.
- TBT — total blocking time of the main thread, measured in the lab.
- CrUX — the Chrome User Experience Report; field data on a 28-day rolling window.
- Field data — measurement collected from real user visits.
- Lab data — synthetic measurement produced under fixed conditions.
- Lighthouse — the open-source auditing tool that produces lab measurements.
- Performance budget — the set of numeric limits a page may not exceed.
- Critical rendering path — the chain of resources required before the first paint.
Continue: the digital visibility glossary · The other two axes of search visibility: what is AEO and what is GEO · Machine readability: the Schema.org and JSON-LD guide.
Frequently asked questions about Core Web Vitals
Six questions, answered directly. Every numeric claim carries its source and access date inside the answer.
What are Core Web Vitals?
Core Web Vitals is the collective name for the three field metrics Google defines to measure the user experience of a page. LCP measures loading speed, INP measures interaction responsiveness and CLS measures visual stability. The data does not come from synthetic tests but from the visits of real, eligible Chrome users, and it is assessed at the 75th percentile of page views. If any one of the three metrics falls outside its threshold, the page does not pass the assessment.
What counts as good LCP, INP and CLS?
According to Google's published thresholds, the good range is: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. The needs-improvement bands are 2.5–4.0 seconds, 200–500 milliseconds and 0.1–0.25 respectively; anything above those bands is poor. Thresholds are read separately for mobile and desktop, at the 75th percentile of page views. Source: Google web.dev, accessed 29 July 2026.
How does INP differ from FID?
FID measured only the input delay of the first interaction and did not include the time the browser spent producing a response, which is why most sites looked good on it. INP measures every click, tap and keypress across the visit and counts the whole duration from the interaction until the next paint. INP replaced FID as a Core Web Vital on 12 March 2024; FID was removed from Search Console the same day and was retired from other Google tools after a transition period that ran until 9 September 2024.
Why do field data and lab data disagree?
Lab data is produced synthetically on one device, one emulated network and a single load; because it is repeatable it is well suited to debugging. Field data carries the real variety of user devices, networks, cache states and interactions. The Chrome User Experience Report publishes that data as a 28-day rolling window. INP only occurs through genuine interaction, so it has no exact lab equivalent. The decision is made on field data; lab data explains the cause.
Which measurement tool is used for what?
The Chrome User Experience Report and your own real user monitoring provide field data; they determine the actual state. The Core Web Vitals report in Search Console groups the same field data by URL pattern and is used for prioritisation. PageSpeed Insights puts field and lab data side by side for a single address. Lighthouse and the Chrome DevTools performance panel produce lab data and are used for root cause analysis and for verifying a fix. A programme run with a single tool will always be incomplete.
How do you set a performance budget?
A performance budget is a set of numeric limits a page may not exceed. Three kinds of limit are written: metric limits (for example mobile LCP 1.8 seconds, CLS 0.05), resource limits (the JavaScript and CSS weight shipped on first load, the number of font files) and request limits (third-party requests before consent). A budget is not a document but an automated check running in the release pipeline: a change that breaks the limit does not ship. Optimisation without a budget is reversed within a few releases.
See the measured state of your website within five working days.
The audit is free and creates no obligation to work with us. The report itemises findings on AEO answerability, AI crawler access, lab-measured Core Web Vitals, structured data validity and accessibility (automated scan).
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.