Core Web Vitals and user experience: what speed, response and stability mean for your business

Three numbers that describe how a page feels

Every visitor asks a page three silent questions. Has the thing I came for appeared yet? When I tap something, does it answer? Will it stay still long enough for me to read it?

Google's Core Web Vitals put a number on each question. Largest Contentful Paint (LCP) measures loading: how long until the main content shows. Interaction to Next Paint (INP) measures responsiveness: how long the page takes to react when someone clicks, taps or types. Cumulative Layout Shift (CLS) measures visual stability: how much the content jumps about while it is being used.¹

Each metric has a good threshold. LCP should be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less. Google measures each one at the 75th percentile of real page loads, with mobile and desktop counted separately.¹ That last sentence carries more weight than the thresholds themselves, and it gets its own section further down.

The set is not frozen. Google runs the metrics through a lifecycle (experimental, pending, stable), and a stable metric can be retired.¹ That happened in 2024, when INP replaced First Input Delay. If an article, an audit or an agency report still lists First Input Delay as a Core Web Vital, it is out of date.

Worked example: the shop in this article

Shandon Oak is an invented online furniture shop in Cork. Siobhán runs it. It sells solid oak dining tables, sideboards and sofas, with a typical order around €780, from a site at shandonoak.example. Most visitors arrive on a phone.

Siobhán's complaint is the one I hear most often: "The site feels sluggish on my phone, but the agency says the score is grand." Each section below takes her numbers, finds what is wrong and fixes it. The shop and every figure are made up.

Largest Contentful Paint: when the main thing appears

LCP is the time from the moment someone starts loading the page to the moment the largest visible image, text block or video in the first screen finishes rendering.² On a product page that is usually the hero photo. On an article it is often the headline or the first paragraph.

The thresholds are: 2.5 seconds or less is good, above 4.0 seconds is poor, and the space in between needs improvement.²

On its own LCP says the page was slow, not why. Google's guide to improving it splits LCP into four parts that add up to the whole:³

1. Time to first byte: how long the server takes to start sending the page.
2. Resource load delay: the gap between that first byte and the moment the browser starts fetching the LCP image (zero if the largest element is plain text).
3. Resource load duration: how long the image itself takes to download.
4. Element render delay: the time between the image arriving and it actually appearing.

In symbols:

$$\text{LCP} = t_{\text{TTFB}} + t_{\text{delay}} + t_{\text{load}} + t_{\text{render}}$$

Here $t_{\text{TTFB}}$ is the time to first byte, $t_{\text{delay}}$ the resource load delay, $t_{\text{load}}$ the resource load duration and $t_{\text{render}}$ the element render delay, all in seconds. To see where the time goes, divide each part by $\text{LCP}$ and multiply by 100 to get its share as a percentage. Foundations: percentages.

The guide gives a rough target for a page in good shape: about 40% of LCP in time to first byte, about 40% in the download, and under 10% in each of the two delays. The two parts with "delay" in their name are the ones that should be close to zero. The guide is clear that these are guidelines, and that if LCP is consistently within 2.5 seconds the proportions hardly matter.³

Worked example: the oak table page

On the Shandon Oak product page for the bestselling dining table, the LCP element is the hero photo of the table. On mobile, at the 75th percentile, LCP is 4.6 seconds. That is poor.

Measured in the browser tools on a throttled phone profile, the four parts break down like this:

Part	Time	Share of LCP
Time to first byte	0.9 s	19.6%
Resource load delay	1.1 s	23.9%
Resource load duration	2.1 s	45.7%
Element render delay	0.5 s	10.9%
Total	4.6 s	100%

The first share, worked through: $0.9 \div 4.6 = 0.196$, so 19.6%. The others follow the same way.

Two things stand out. The resource load delay is 23.9%, far above the rough 10%. The reason is that the photo sits inside a carousel script, so the browser only discovers the image after the script has run. And the download itself takes 2.1 seconds because the photo is a 2.4 MB file, sized for a large monitor and sent to a phone.

Interaction to Next Paint: when the page answers

INP measures how quickly a page responds to clicks, taps and key presses throughout a visit. Hovering and scrolling are not counted. The value reported is, broadly, the slowest interaction of the visit, with one outlier ignored for every 50 interactions so a single hiccup on a busy page does not dominate.⁴

The thresholds: 200 milliseconds or less is good, above 500 milliseconds is poor.⁴

INP became a Core Web Vital on 12 March 2024 and replaced First Input Delay (FID) on that date.⁵ The reason is worth knowing, because it explains why some sites that looked fine suddenly did not. FID only measured the input delay of the first interaction on a page. INP observes all of them, from the input delay, through the time the code takes to run, to the moment the browser paints the next frame.⁴ Chrome's usage data shows that 90% of a user's time on a page is spent after it has loaded.⁴ A metric that only looked at the first tap was missing most of the visit.

Every interaction has three phases:⁴

1. Input delay: the time before the page can even start handling the tap, usually because the browser is busy running some other script.
2. Processing duration: the time the page's own code takes to handle it.
3. Presentation delay: the time from that code finishing to the screen actually updating.

$$\text{INP}_{\text{interaction}} = t_{\text{input}} + t_{\text{processing}} + t_{\text{presentation}}$$

Here $\text{INP}_{\text{interaction}}$ is the latency of one interaction, $t_{\text{input}}$ the input delay, $t_{\text{processing}}$ the processing duration and $t_{\text{presentation}}$ the presentation delay, all in milliseconds. The same share calculation as for LCP tells you which phase to attack. Foundations: percentages.

Google's guide to improving INP points first at long tasks on the main thread, the single lane of work where the browser runs scripts, works out the layout and paints the screen. While a long script is running, a tap has to wait.⁶

Worked example: choosing a fabric

On Shandon Oak, the slowest common interaction is tapping a fabric swatch on a sofa page. The page swaps the photo and the price. At the 75th percentile on mobile, INP is 380 milliseconds, which needs improvement.

Timed in the browser tools, a typical slow tap breaks down as:

$$210 + 120 + 50 = 380 \text{ ms}$$

Here $t_{\text{input}} = 210$, $t_{\text{processing}} = 120$ and $t_{\text{presentation}} = 50$, all in milliseconds. The input delay is 55% of the total ($210 \div 380 = 0.553$). The page is not slow to handle the tap. It is busy with something else when the tap arrives. In this case, a reviews widget and a chat widget both run large scripts as the visitor starts to scroll and tap.

Cumulative Layout Shift: when the page stays still

CLS measures how much visible content moves unexpectedly while the page is in use.⁷ Google's own explanation names the cost plainly: a sudden shift can make someone tap the wrong thing, and its example is a user confirming a large order they meant to cancel.⁷ On a furniture shop with €780 orders, that is not an abstract worry.

Each unexpected movement gets a layout shift score:

$$s = f_{\text{impact}} \times f_{\text{distance}}$$

Here $s$ is the score of one shift. $f_{\text{impact}}$ is the impact fraction: the share of the screen covered by the moving element, before and after the move combined. $f_{\text{distance}}$ is the distance fraction: how far the element moved, as a share of the screen's longest side. Both are ratios between 0 and 1. Foundations: ratios and rates.

Shifts are grouped into bursts, called session windows: shifts less than one second apart, in a window no longer than five seconds. CLS is the total score of the worst window. Shifts within half a second of a tap, click or key press are treated as expected and do not count, because the visitor caused them.⁷

The thresholds: 0.1 or less is good, above 0.25 is poor.⁷ The most common causes, according to Google's guide, are images without dimensions, ads, embeds and iframes without dimensions, content injected after the page has loaded, and web fonts.⁸

Worked example: the finance banner

On the Shandon Oak product page, a "pay in instalments" banner loads late from a third party script and pushes the price, the photo and the button down.

The moving block covers 60% of the phone screen across the before and after frames, so $f_{\text{impact}} = 0.60$. It moves down by a quarter of the screen height, so $f_{\text{distance}} = 0.25$.

$$s_1 = 0.60 \times 0.25 = 0.15$$

Here $s_1$ is the score of the first shift, $0.60$ its impact fraction and $0.25$ its distance fraction.

Under a second later, the reviews star rating loads above the button and nudges the block again: impact 0.35, distance 0.20.

$$s_2 = 0.35 \times 0.20 = 0.07$$

Here $s_2$ is the score of the second shift.

Both fall in the same session window, so the window scores $0.15 + 0.07 = 0.22$. At the 75th percentile on mobile, the page's CLS is 0.22, which needs improvement and sits close to poor. Nobody tapped anything. The page moved on its own.

Why the 75th percentile and not the average

Google does not grade a page on its average load. It takes all the real page loads, sorts them, and reads the value three quarters of the way up. That is the 75th percentile, often written p75.¹

A percentile is a position in a sorted list. The median is the 50th percentile, the middle value. The 75th percentile is the value that three quarters of loads are at or below. One simple way to find it, the nearest rank method:

$$k = \lceil 0.75 \times n \rceil$$

Here $n$ is the number of page loads, $k$ the rank of the p75 value once the loads are sorted from fastest to slowest, and $\lceil \, \rceil$ means round up to the next whole number. Foundations: distributions and Foundations: median and mode.

Why p75? Google's research paper on the thresholds sets two goals that pull against each other. The value should show that most visits reached the target, and it should not be thrown about by a few extreme outliers. The authors concluded that the 75th percentile strikes a reasonable balance: if it meets the threshold, three of every four visits did at least as well.⁹

The average fails at both. Load times are skewed. Most are bunched together, and a long tail of slow phones on weak signal drags the mean upwards. Then one cached visit from the office laptop drags it back down. A mean can look fine while a quarter of your visitors wait.

A related figure is the share of loads that reached good:

$$\text{good share} = \frac{n_{\text{good}}}{n}$$

Here $n_{\text{good}}$ is the number of page loads at or under the good threshold and $n$ the total number of loads. Foundations: ratios and rates. A page passes a metric when that share is at least 75%, which is the same statement as "p75 is within the threshold".

Worked example: 20 page loads

Siobhán exports 20 real mobile loads of the oak table page, with their LCP in seconds, already sorted:

1.4, 1.6, 1.7, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.6, 2.8, 3.0, 3.1, 3.3, 3.6, 3.9, 4.2, 4.8, 5.5, 7.1

Step one, the rank: $k = \lceil 0.75 \times 20 \rceil = \lceil 15 \rceil = 15$.

Step two, read the 15th value: 3.6 seconds. That is the p75, and it needs improvement.

Step three, the median for comparison: with 20 values it sits between the 10th and 11th, so $(2.6 + 2.8) \div 2 = 2.7$ seconds.

Step four, the good share: nine loads are at or under 2.5 seconds, so $9 \div 20 = 0.45$, or 45%. Well short of 75%.

Step five, the fastest load: 1.4 seconds. That is roughly what Siobhán sees on her own phone on office wifi, and why the site "feels grand" to her. The page is not graded on her phone.

Field data and lab data are different tools

There are two ways to measure all this, and confusing them causes most arguments.

Lab data comes from loading the page in a controlled setting, one device, one network, one location. Lighthouse, the tool behind most "performance scores", is lab data. Field data comes from real visitors on their own devices and connections.¹⁰

Google's main source of field data is the Chrome User Experience Report (CrUX): real world experience data from Chrome users on popular sites.¹¹ Not every Chrome user counts. They need usage statistics reporting on, browsing history sync on and no sync passphrase, on desktop Chrome or Chrome on Android. Chrome on iPhone does not contribute. A page or a site needs enough visitors to be included, and Google does not publish the exact number.¹² The figures are a rolling average over the last 28 days.¹³

Lab and field disagree for good reasons. The lab uses one device and network while your visitors use hundreds. The lab usually starts with an empty cache. And the lab does not scroll, select text or tap, so it cannot see what happens during a real visit. INP in particular cannot be measured in the lab at all, because a lab test cannot predict when a person will interact. Lighthouse reports Total Blocking Time as a stand in, and a page can have good Total Blocking Time and poor INP.¹⁰

Google's guidance is to prioritise field data, because it is what people actually experience, and to use lab data to find the cause.¹⁰ That is exactly how I use them: the field tells me where it hurts, the lab tells me why.

If a site is too small for CrUX, it can collect its own field data by sending the three metrics from real visits as an analytics event. On sites I build, that event only fires after the visitor has accepted analytics, like everything else I measure.

Worked example: the score that said fine

Siobhán's agency runs Lighthouse on a desktop machine and reports a performance score in the 90s and an LCP of 1.8 seconds. CrUX for the same page, on mobile, says LCP 4.6 seconds at p75, INP 380 milliseconds and CLS 0.22.

Both are true. The lab test ran on a fast wired machine, never tapped a swatch and never waited for the finance banner, which loads once a visitor scrolls. The field data describes her customers. The lab score describes the agency's computer.

How much the three numbers weigh in search

Here the old version of this article overstated things, so I will be precise and let Google speak.

Google says that Core Web Vitals "are used by our ranking systems", and recommends that site owners achieve good scores "for success with Search and to ensure a great user experience generally".¹⁴ So they count.

Google is just as clear about the limits. Good results in reports like the Core Web Vitals report in Search Console do not guarantee rankings: getting them "doesn't guarantee that your pages will rank at the top of Google Search results". And on chasing the numbers: "trying to get a perfect score just for SEO reasons may not be the best use of your time".¹⁴

The most useful sentence on the page is this one: "Google Search always seeks to show the most relevant content", even when the page experience is poor. But where many pages answer a query equally well, a great page experience "can contribute to success in Search, in such cases".¹⁴

So page experience is one signal among many, and good content still wins. Speed breaks ties. It does not rescue a page nobody needs. I fix Core Web Vitals for the people who arrive, and take any ranking help as a bonus.

Worked example: the dining table guide

Siobhán has a genuinely useful guide to choosing a dining table size, with a measuring chart. A large retailer has a thin page on the same query that loads in under two seconds. Her guide can outrank it while her LCP is still poor, because it answers the question better. Speed matters against the three other shops with guides about as good as hers. There, it can tip the balance.

What speed does to sales, and what nobody can honestly promise

The old version of this article said faster sites convert better, with nothing behind it. Here is a figure with a test behind it, and its limits.

Vodafone ran an A/B test on a landing page, splitting paid traffic 50/50 between the existing version and one optimised for Web Vitals. The optimised version moved a widget's rendering to the server, rendered the critical HTML on the server and resized and compressed its images. In Vodafone's own result, LCP in the field improved by 31%, and the optimised page had 8% more sales, a 15% better lead to visit rate and an 11% better cart to visit rate.¹⁵

That is a proper test with a control, which is rare, and fair play to Vodafone for publishing it. It is also one company, one landing page, paid traffic, in 2021. It shows the effect can be real, not what your shop will see.

Those figures are percentage changes, not percentage points:

$$\Delta\% = \frac{v_{\text{new}} - v_{\text{old}}}{v_{\text{old}}} \times 100$$

Here $\Delta\%$ is the percentage change, $v_{\text{old}}$ the value before and $v_{\text{new}}$ the value after. A negative result for a time means it got faster. Foundations: percentages.

In the shops I have worked on, the effect has been consistent in direction and inconsistent in size, from clearly visible to lost in the noise. I tell clients that, rather than a number. Anyone who promises a conversion lift from a speed project before measuring your traffic is selling, not measuring.

Speed is also only one source of friction. A page can load in a second and still lose people to a vague headline or a form that asks too much. That side, the copy, the flow and the forms, is the subject of the Clarity Framework for removing friction from conversion, and I will not repeat it here.

Worked example: what Siobhán may and may not say

If Siobhán's LCP goes from 4.6 to 2.2 seconds:

$$\Delta\% = \frac{2.2 - 4.6}{4.6} \times 100 = \frac{-2.4}{4.6} \times 100 = -52.2\%$$

Here $v_{\text{old}} = 4.6$ and $v_{\text{new}} = 2.2$ seconds, so $\Delta\% = -52.2\%$.

LCP is 52.2% faster. What she cannot do is reason "Vodafone saw 8% more sales for 31% faster, so I will see about 13%". Their test was a different business, different traffic and different pages. She can only learn her own number by measuring her own sales, ideally with a test, and if her traffic is too small for a test, by an honest before and after that she reads with care.

Diagnosing a slow page, top to bottom

The process I follow is dull on purpose. Each step narrows the problem before anyone touches code.

The flow reads from the top. The first decision is only about where the numbers come from. The highlighted step matters most: work on the metric furthest from good, one cause at a time. The last step is the one people skip. Because CrUX is a 28 day rolling average,¹³ a fix shipped today only fully shows up in it four weeks later. Your own consented events show it sooner.

Worked example: Siobhán's three fixes

Following the steps on the oak table and sofa pages:

1. Field data exists for the product pages. On mobile at p75: LCP 4.6 s, INP 380 ms, CLS 0.22. All three are outside good.
2. Measured against its threshold, CLS is furthest out (0.22 against 0.1), then INP, then LCP. Siobhán starts with CLS because it is also the fix least likely to break anything.
3. CLS: the finance banner and the star rating get their space reserved in the layout before they load. Nothing below them moves.
4. INP: the reviews and chat widgets now load only when a visitor scrolls to the reviews or taps the chat button. The main thread is free when the swatch is tapped.
5. LCP: the hero photo is taken out of the carousel script and written straight into the page, marked as high priority. It is served at the size of the screen asking for it, around 200 KB on a phone instead of 2.4 MB.
6. She ships each fix in its own release, checks it in the lab, then waits.

The Cork shop, before and after

Twenty eight days after the last fix, the CrUX figures for the product pages on mobile at p75 read: LCP 2.2 seconds, INP 170 milliseconds, CLS 0.05. All three are good.

The three metrics use different units, seconds, milliseconds and a score, so they cannot share an axis as they are. To compare them, I express each value as a share of its good threshold:

$$r = \frac{v}{v_{\text{good}}} \times 100$$

Here $r$ is the value as a percentage of the threshold, $v$ the measured value at p75 and $v_{\text{good}}$ the good threshold for that metric (2.5 seconds, 200 milliseconds or 0.1). Anything at or under 100% is good. Foundations: ratios and rates.

Before: LCP $4.6 \div 2.5 = 184\%$, INP $380 \div 200 = 190\%$, CLS $0.22 \div 0.1 = 220\%$. After: LCP $2.2 \div 2.5 = 88\%$, INP $170 \div 200 = 85\%$, CLS $0.05 \div 0.1 = 50\%$.

The horizontal axis shows each metric twice, before and after the fixes. The vertical axis shows the p75 value as a percentage of its good threshold, so 100% is exactly on the line and anything below it is good. Before, all three bars stand well above 100%, with layout shift worst at more than twice its threshold. After, all three sit below 100%. The takeaway is not that the shop is now fast in some general sense. It is that three out of four mobile visits now get the main photo within 2.5 seconds, a response to a tap within 200 milliseconds, and a page that stays still. Whether that sold more tables is a separate question, and Siobhán answers it from her own sales figures, not from this chart.

Where it usually goes wrong

Chasing a Lighthouse score. It is lab data from one machine. Google itself says a perfect score just for SEO may not be the best use of your time.¹⁴ Improve the field numbers and let the score follow.

Testing on your own phone on office wifi. That is the 1.4 second load at the fast end of the sorted list. The page is graded on the 75th percentile, and that visitor is on a train somewhere outside Mallow.

Reading desktop and calling it done. Mobile and desktop are measured separately,¹ and for most shops mobile is where the trouble is.

Fixing three things at once. When the number moves, you will not know which change did it.

Promising a sales lift. Measure it instead.

Speed is a courtesy you can measure

Core Web Vitals are not a ranking trick. They answer three plain questions every visitor asks: is it there, does it answer, does it stay still. Google counts them modestly. Your visitors count them every time they wait.

Read the field data at the 75th percentile, mobile first. Fix the metric furthest from good, one cause at a time, and measure again four weeks later. Unglamorous work, and some of the most reliably useful on a website.

Footnotes

1. Philip Walton, Web Vitals, web.dev, Google, 2024, https://web.dev/articles/vitals

2. Philip Walton and Barry Pollard, Largest Contentful Paint (LCP), web.dev, Google, 2025, https://web.dev/articles/lcp

3. Philip Walton and Barry Pollard, Optimize Largest Contentful Paint, web.dev, Google, 2025, https://web.dev/articles/optimize-lcp

4. Jeremy Wagner and Barry Pollard, Interaction to Next Paint (INP), web.dev, Google, 2025, https://web.dev/articles/inp

5. Jeremy Wagner and Rick Viscomi, Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev blog, Google, 2024, https://web.dev/blog/inp-cwv-march-12

6. Jeremy Wagner, Philip Walton and Barry Pollard, Optimize Interaction to Next Paint, web.dev, Google, 2025, https://web.dev/articles/optimize-inp

7. Milica Mihajlija and Philip Walton, Cumulative Layout Shift (CLS), web.dev, Google, 2023, https://web.dev/articles/cls

8. Addy Osmani and Barry Pollard, Optimize Cumulative Layout Shift, web.dev, Google, 2025, https://web.dev/articles/optimize-cls

9. Bryan McQuade and Barry Pollard, The research and methodology behind Core Web Vitals thresholds, web.dev, Google, 2025, https://web.dev/articles/defining-core-web-vitals-thresholds

10. Philip Walton, Why lab and field data can be different (and what to do about it), web.dev, Google, 2022, https://web.dev/articles/lab-and-field-data-differences

11. Chrome for Developers, Overview of CrUX, Chrome UX Report documentation, Google, 2024, https://developer.chrome.com/docs/crux

12. Chrome for Developers, CrUX methodology, Chrome UX Report documentation, Google, 2024, https://developer.chrome.com/docs/crux/methodology

13. Chrome for Developers, CrUX API, Chrome UX Report documentation, Google, 2026, https://developer.chrome.com/docs/crux/api

14. Google Search Central, Understanding Google Page Experience, Google for Developers, 2026, https://developers.google.com/search/docs/appearance/page-experience

15. web.dev, Vodafone: A 31% improvement in LCP increased sales by 8%, web.dev case studies, Google, 2021, https://web.dev/case-studies/vodafone