Core Web Vitals What LCP, INP and CLS measure, which thresholds apply and in which order large websites improve them
The Core Web Vitals are three metrics based on the behavior of real visitors. They answer three separate questions: when is the main content there, how quickly does the page respond to input, and does the layout stay stable. This page explains the metrics, their thresholds and their origin, and it sets out the order in which working on them pays off. The original figures on this page come from a study of 46,394 checked domains in the DACH region (Germany, Austria, Switzerland), data as of August 2026.
Thresholds as defined by GoogleOwn figures: as of August 2026, version 2026-Q3
LCP, INP and CLS: thresholds apply to three out of four page views
All three values are assessed at the 75th percentile: three out of four page views must be below the threshold. A page only passes if this holds for all three at the same time, and this is exactly where most websites fail whose individual values look decent on their own.
Largest Contentful Paint: main content load time, good up to 2.5 seconds
It measures when the largest visible element in the viewport has finished rendering, usually a hero image or a heading. Good is 2.5 seconds, poor is anything above 4 seconds. In our own study, 80.5 percent of Adobe Experience Manager websites and 77.7 percent of Magnolia websites are in the green range here; the median is 1,874 and 1,754 milliseconds respectively.
Interaction to Next Paint: response time to input, good up to 200 milliseconds
It measures the time between an input and the next visible response, across the entire visit, so for every interaction and not only the first click. Good is 200 milliseconds, poor is anything above 500. This metric replaced First Input Delay in March 2024 and is stricter, because it assesses every interaction instead of only the delay until processing starts.
Cumulative Layout Shift: visual stability, good below 0.1
It measures how much visible elements shift without any action by the user. Good is a value below 0.1, poor is anything above 0.25. The metric has no unit: it multiplies the share of the affected area by the distance the content moves.
Time to First Byte: not a Core Web Vital but the root, good up to 800 milliseconds
Server response time is not one of the Core Web Vitals, but it is the first segment of every Largest Contentful Paint. Google names 800 milliseconds as a guideline. It determines whether a frontend optimization can have any effect at all.
Web Vitals and Core Web Vitals: three metrics count for the assessment, the others serve diagnosis
Web Vitals is the umbrella term Google has used since 2020 for metrics on user experience in the browser. The Core Web Vitals are the subset Google includes in the assessment of pages: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. The other Web Vitals are not assessed, but they explain why an assessed value is poor.
- First Contentful Paint measures when any content appears at all, such as text or a logo. Google names 1.8 seconds as the limit for "good". The value always comes before Largest Contentful Paint and is slowed down by the same causes: a late server response and render-blocking stylesheets or fonts.
- Time to First Byte measures server response time and is the first segment of every load time.
- Total Blocking Time is a lab metric for main thread blocking and the best lab indicator of a poor Interaction to Next Paint value.
To improve First Contentful Paint, you therefore work on the same areas as for Largest Contentful Paint: first on server response time, then on everything that blocks the initial render.
Core Web Vitals data sources: field data decides, not lab data
What gets assessed is what real visitors have experienced. Google collects these measurements in the Chrome User Experience Report (CrUX) per origin over a rolling 28-day window. Lab tools such as Lighthouse or PageSpeed Insights, by contrast, measure a single simulated session without a tag manager, without a consent banner and with a fixed network profile. Both sources have their purpose: the lab shows causes, the field decides the assessment.
Which tools use which source and when which number applies is covered on the page Measuring Core Web Vitals.
LCP makes most websites fail, not INP or CLS
In our own study, 55.9 percent of the failing AEM websites miss the main content load time; for Magnolia it is 62.3 percent. Response time to input, by contrast, is rarely the reason: 83.4 percent of AEM websites and 91.0 percent of Magnolia websites are in the green range there.
This results in a clear order. First server response time, because it is part of every load time value. Then the loading order in the browser, meaning which image, which stylesheet and which script comes first. Then reserved dimensions for everything that loads later. Last, input responsiveness, which almost always depends on the tag manager, the consent banner and third-party scripts.
Core Web Vitals on mobile and desktop: two different results
The assessment is separate per device type, and the values differ. In our own study, 62.0 percent of AEM websites pass on desktop, but 65.1 percent on mobile devices; the median load time is 1,874 milliseconds on mobile compared with 1,446 milliseconds on desktop. Looking only at desktop shows the better result and the wrong problem area.
Core Web Vitals on large websites: one target value per page type instead of one value for the domain
On a platform with a hundred thousand pages, there is not one value but one per page type. Home pages carry the most campaign components and therefore the highest risk of layout shifts. Listing pages have the most expensive queries and the most images. Detail pages are usually uncritical and are therefore often cited as proof that the platform is fast. Form flows carry the most interaction and therefore the strictest requirement for response time to input.
This is why a performance budget is set per page type, not as an average across everything. The way there is described under Website Performance Optimization, the system-specific questions on the pages on Adobe Experience Manager Performance and Magnolia CMS Performance.
Core Web Vitals Benchmark: documented figures from the DACH region instead of rules of thumb
How many websites actually meet the thresholds is shown in the Core Web Vitals Benchmark: two studies in the DACH region with open datasets from which every figure on this page can be recalculated, the AEM Core Web Vitals Benchmark and the Magnolia CMS Core Web Vitals Benchmark. How these figures are translated into target values for a specific platform is the subject of Web Performance Consulting.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, regardless of whether we work together.
Frequently asked questions about the Core Web Vitals
What is the difference between Web Vitals and Core Web Vitals?
Web Vitals is the umbrella term for Google's user experience metrics, including First Contentful Paint, Time to First Byte and Total Blocking Time. The Core Web Vitals are the three of them that count for the assessment: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. The other metrics serve diagnosis.
What are the Core Web Vitals?
Three metrics Google uses to measure the user experience of a page: Largest Contentful Paint for the load time of the largest visible content, Interaction to Next Paint for the response time to input and Cumulative Layout Shift for visual stability. The values come from the behavior of real visitors, not from a simulation.
Which thresholds apply?
Good means 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift. The 75th percentile of page views is assessed: three out of four visits must be below the threshold. A page only passes if all three values are in the green range at the same time.
Are the Core Web Vitals a ranking factor?
They are among the signals Google groups under page experience, and they carry less weight than relevance and content. The effect shows mainly where several results are equivalent in content. The bigger lever lies with users anyway: abandonment before the first visible content costs revenue regardless of any ranking question.
Why do pages with a good score still fail the Core Web Vitals?
Because the PageSpeed Insights score is a lab measurement on simulated hardware, without a tag manager, without a consent banner and with a fixed network profile. What gets assessed, by contrast, is what real visitors experienced over the last 28 days. The two numbers can be far apart without either of them being wrong.
In which order do you work on the three values?
First server response time, because it is part of every Largest Contentful Paint. In our own study, 80.3 percent of the websites that are too slow already have a server time above the limit; frontend work has no effect there. Then the loading order in the browser, then layout stability, and last the response time to input, which usually depends on tags and consent logic.
How long does it take for an improvement to become visible?
Google calculates the values from a rolling 28-day window. A change is therefore fully visible no earlier than four weeks after go-live. Real user monitoring shows the effect the next day and bridges this period.