Definition
Core Web Vitals (CWV) are three metrics from Google that capture how real visitors experience a web page: Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) responsiveness to input and Cumulative Layout Shift (CLS) visual stability. Good means at most 2.5 seconds, 200 milliseconds and 0.1 for three out of four page views.
Key takeaways
- LCP measures loading, INP responsiveness to input and CLS how much content shifts. Good means at most 2.5 s, 200 ms and 0.1.
- Google uses Core Web Vitals as one of many ranking signals. Relevant content comes first, and good scores don’t guarantee a ranking.
- Google Search uses field data from real Chrome visits in the Chrome UX Report. Lighthouse measures in the lab and helps you find problems.
- Field data comes only from Chrome. It leaves out iPhones, which made up about 28% of mobile page views in Germany in October 2026.
- Fewer websites have good LCP than good INP or CLS. What helps: early-loading images, fast servers, reserved space and little JavaScript.
What do LCP, INP and CLS measure?
LCP measures when the largest image, text block or video visible on screen appears. INP measures how quickly a page visibly responds after a click, tap or key press. CLS measures how much content shifts unexpectedly. For each metric, the value that counts is the one that three out of four page views meet or beat.
Google based the thresholds on research into human perception and on data from real websites (web.dev on the thresholds (external site)). They’re the same for phones and desktops, but each device type is assessed separately. A page passes the assessment only when all three metrics are good (web.dev on Web Vitals (external site)).
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | loading: when the largest visible element renders | up to 2.5 s | over 2.5 s, up to 4.0 s | over 4.0 s |
| Interaction to Next Paint (INP) | responsiveness to clicks, taps and key presses | up to 200 ms | over 200 ms, up to 500 ms | over 500 ms |
| Cumulative Layout Shift (CLS) | visual stability: content shifting unexpectedly | up to 0.1 | over 0.1, up to 0.25 | over 0.25 |
- LCP counts from the moment a visitor navigates to the page, so redirects and the server’s response time are included. Images, videos, background images and blocks of text can all qualify. Chromium-based browsers such as Chrome and Edge treat elements that fill the whole viewport as background and ignore them (web.dev on LCP (external site)).
- INP observes every click, tap and key press during a visit and reports the slowest one. On pages with many interactions, the slowest one in every 50 is dropped as an outlier. Scrolling, zooming and hovering don’t count. Each interaction has three phases: the input delay before the page’s code starts responding, the processing duration while that code runs and the presentation delay until the next frame appears on screen. According to Chrome data, users spend 90% of their time on a page after it has loaded (web.dev on INP (external site)).
- CLS groups layout shifts into bursts: less than one second apart and no more than five seconds in total. The burst with the highest total score counts. Shifts within 500 milliseconds of user input are excluded, because users expect them (web.dev on CLS (external site)).
Our guide to technical SEO explains how the three metrics fit in with indexing, crawling and the other technical basics.
How much do Core Web Vitals matter for Google rankings?
Google uses Core Web Vitals in its ranking systems as one of many signals. It still shows the most relevant page even if that page offers a weaker experience. When many helpful pages exist for a search, good scores can contribute to success. They don’t guarantee a ranking.
These points come from Google’s documentation on page experience (external site), last updated September 22, 2026. It also says there’s no single page experience signal. Google’s core ranking systems generally evaluate content page by page, though Google mentions some site-wide assessments too. Good results in the Core Web Vitals report of Google Search Console or in third-party tools don’t guarantee a top ranking. Google adds that trying to get a perfect score just for SEO may not be the best use of your time.
The basis is field data. Google Search uses measurements from real Chrome visits, collected in the Chrome UX Report (CrUX), for its page experience ranking factor (Chrome for Developers on CrUX (external site)). Google announced this ranking factor in May 2020 and rolled it out between June and the end of August 2021 (Google Search Central Blog (external site)).
Google and Microsoft don’t back up these common claims:
- A fixed share of rankings. Figures on what percentage Core Web Vitals account for don’t come from Google. Google doesn’t state a weight.
- More points, better rankings. The 0–100 score in PageSpeed Insights comes from a Lighthouse lab test. Google doesn’t say that a score of 100 ranks better than 90.
- A separate effect on AI answers. For AI Overviews and AI Mode, Google lists a great page experience among the SEO fundamentals that remain worthwhile. It names no thresholds (Google on AI features (external site)). Bing’s guidelines, which cover Microsoft Copilot as well, mention neither Core Web Vitals nor load times (Bing Webmaster Guidelines (external site), as of November 8, 2026). Our article AI Overviews and AI Mode explains how Google picks the sources for these answers.
What does this mean for a small business?
If your website doesn’t show up on Google at all, better scores alone won’t help. Indexing comes first. Our how-to Why isn’t my website showing up on Google? walks you through the checks in order.
If your website is indexed, look at the mobile scores first. In Germany, about 60% of all page views came from smartphones in October 2026.
Source: StatCounter, · monthly figure, October 2026, Mobile category: 60.21%
If your website gets few visits, there may be no field data for it. Google’s documentation doesn’t say how Google assesses such pages. In our view, good lab scores are then the best guide you have.
What’s the difference between lab data and field data?
Field data comes from real visits on real devices and shows what your customers experience. Lab data comes from a test with a fixed device and network, for example in Lighthouse. It helps you find causes and test changes before you publish them. If you have both, set your priorities based on the field data.
At Google, field data comes from the Chrome UX Report. It collects measurements from Chrome users on desktop computers and Android who send usage statistics and sync their browsing history. Chrome on iOS, Android apps that use WebView and other Chromium browsers such as Microsoft Edge don’t contribute any data (CrUX methodology (external site)). CrUX only includes public pages that return HTTP status 200, aren’t set to noindex and have enough visitors. Google doesn’t disclose the minimum. PageSpeed Insights shows the values for the previous 28 days (About PageSpeed Insights (external site)).
Lab data comes from Lighthouse, which also runs inside PageSpeed Insights. For mobile tests, Lighthouse slows down the test machine’s processor by a factor of four to emulate a mid-tier phone. It also simulates a slow mobile connection with 150 milliseconds of latency and a download speed of 1.6 megabits per second (Lighthouse docs on throttling (external site)). A standard page-load test has no user input, so Lighthouse can’t measure INP there. Instead, it measures Total Blocking Time (TBT): the time after the first content appears during which long tasks keep the browser from responding to input (web.dev on TBT (external site)).
Lighthouse 13.6.0 calculates its 0–100 performance score from five lab metrics: TBT counts for 30%, LCP and CLS for 25% each, and First Contentful Paint (FCP) and Speed Index for 10% each (Lighthouse 13.6.0 configuration (external site)). A score of 90 or more counts as good (Chrome for Developers on performance scoring (external site)). According to Google, good lab data doesn’t necessarily mean that real visitors have a good experience too. Because the score varies from run to run, use the median of five runs. The Lighthouse team says it’s twice as stable as a single run (Lighthouse docs on variability (external site)).
A lab test runs on one device, on one network, from one location. In the field, some files are already cached, and visitors scroll down to lazy-loaded images without dimensions that a lab test never reaches. That’s why CLS, for example, can be higher or lower in the field than in the lab (web.dev on lab and field data (external site)).
How do you measure your website’s Core Web Vitals?
To check a single page, use PageSpeed Insights. It shows the field data for the previous 28 days plus a Lighthouse lab test. For your whole website, use the Core Web Vitals report in Google Search Console. Without field data, you’re left with lab tests and your own measurement in your visitors’ browsers.
| Tool | Data | Use it to | Limitations |
|---|---|---|---|
| PageSpeed Insights | field data from CrUX plus a Lighthouse lab test | check one URL; it shows whether the page passes the assessment | without enough visits, only site-wide values or no field data at all |
| Google Search Console, Core Web Vitals report | field data from CrUX, grouped by similar pages | find problems across the whole website and track your fixes | indexed pages only; a group is rated by its weakest metric |
| CrUX Vis | weekly field data over several months | follow the trend after a change | only pages and websites with enough Chrome visits |
| Chrome DevTools, Performance panel | live values in your own browser, INP as you click, comparison with field data | find the cause of a problem | your own device and network |
| Lighthouse, in the browser or in a test pipeline | lab test | test changes before you publish them | no INP in a page-load test; scores vary, so use the median of five runs |
| Your own measurement (real user monitoring, RUM) | field data from every visit; LCP and INP also from Safari 26.2 or later and Firefox | find causes per page and interaction | needs a script on your website; CLS only from Chromium browsers |
The details come from the PageSpeed Insights documentation (external site), Google’s help page on the Core Web Vitals report (external site), the documentation for CrUX Vis (external site) and the CrUX History API (external site), and Chrome’s guide to the DevTools Performance panel (external site). MDN’s browser compatibility data (external site), version 8.1.8 of November 2, 2026, shows which browsers can measure Core Web Vitals.
Here’s how to go about it:
- Test your most important page in PageSpeed Insights (external site) for mobile. Read the field data first: the page passes if all three metrics are good at the 75th percentile. If there isn’t enough data for INP, good LCP and CLS values are enough.
- Open the Core Web Vitals report in Search Console. Fix everything labeled “Poor” first, then the groups with the most URLs or your most important URLs.
- Look for the cause in the lab, with Lighthouse or in the Performance panel of Chrome DevTools.
- Once a problem is fixed, click “Start Tracking” in the report. Search Console then monitors the field data for four weeks.
Our guide to measuring page speed walks through a PageSpeed Insights report and shows how to get comparable Lighthouse results.
How do you improve LCP, INP and CLS?
Start with the metric that does worst in your field data. For LCP, the server has to respond quickly and the largest element has to start loading early. For INP, as little JavaScript as possible should block the browser. For CLS, images, embeds and banners need their space from the start.
LCP is the metric with the fewest good scores. In the Chrome UX Report for September 2026, 68.3% of the websites it covers had good LCP, 81.7% good CLS and 85.4% good INP. The release notes don’t say which device these figures refer to.
Source: Chrome UX Report (Google) (external site), · September 2026 dataset, 18,376,044 websites
For LCP, the image’s file size is rarely the bottleneck. Most websites with poor LCP spend less than 10% of their LCP time downloading the image. More time often passes before the browser even requests it (web.dev on the most effective fixes (external site)). If you only shrink the image, the time you save sometimes just shifts to another part of the load (web.dev on optimizing LCP (external site)).
The table shows where to start to make your website faster and more stable. It’s based on the Chrome team’s recommendations and the guides to optimizing LCP (external site), INP (external site) and CLS (external site).
| Metric | Cause | What helps |
|---|---|---|
| LCP | The largest image is found late, for example because a script loads it or loading="lazy" delays it | put the image in the HTML as an img element with src, add fetchpriority="high", remove loading="lazy" |
| LCP | The server responds slowly, or visitors arrive through redirects | serve and cache pages through a content delivery network (CDN), avoid redirects |
| LCP | Render-blocking CSS and JavaScript hold up rendering | keep CSS small or inline it, defer scripts, render pages on the server |
| INP | Too much JavaScript: tasks longer than 50 milliseconds block the browser | remove unneeded scripts and old tags in your tag manager, break up long tasks |
| INP | A consent banner loads many scripts at once when someone clicks “Accept” | ask the provider whether it can split up the work after the click |
| CLS | Images and videos without dimensions | set width and height, or reserve the space with aspect-ratio |
| CLS | Ads, maps, videos and banners take up space after loading | reserve space with min-height, place banners over the content instead of pushing it down |
| CLS | A web font runs wider or narrower than the fallback font | match the fallback font with size-adjust, preload the most important font |
| LCP and CLS | The page cannot be restored from the back/forward cache, for example because of Cache-Control: no-store | remove such blockers, and the page appears instantly when visitors go back |
Images without dimensions are common: in July 2025, 62% of mobile pages had at least one.
Source: HTTP Archive, Web Almanac 2025 (external site), , updated · data from July 2025
If you don’t write code yourself, Google offers two rules of thumb: keep a page and all its resources under 500 KB, and on mobile, load no more than 50 resources (Search Console Help (external site)).
Will Core Web Vitals change in 2027?
For now, the three metrics stay the same. Since October 13, 2026, Chrome has also been publishing experimental versions that capture page changes inside single-page applications. Chrome aims to end the experimental stage in May 2027, depending on feedback, and Search Console will then use the new data. For classic websites, the Chrome team expects no change.
Single-page applications don’t load a new page from the server when you click a link. They swap the content and the URL using JavaScript. Such a change is called a soft navigation. In the stable metrics, the Chrome UX Report attributes all interactions and layout shifts of such a session to the first page. Around 70% of websites in CrUX have little to no soft navigation (web.dev on soft navigations (external site)). If your website loads a new page with every click, the Chrome team doesn’t expect your scores to change.
Google announces major changes in advance, and stable metrics change at most once a year (web.dev on Web Vitals (external site)). The last time Google swapped a metric was on March 12, 2024, when INP replaced First Input Delay (FID) (web.dev on the switch to INP (external site)).
How do Core Web Vitals differ from Lighthouse and page experience?
Core Web Vitals are three metrics based on field data from real visits. The Lighthouse performance score ranges from 0 to 100 and comes from a lab test. Page experience is the umbrella term: besides Core Web Vitals, it covers aspects such as HTTPS, displaying well on mobile devices and avoiding intrusive interstitials.
The numbers in the “Sources” column refer to the source list at the end of this article.
| Term | What it is | Data | Role in Google Search | Sources |
|---|---|---|---|---|
| Core Web Vitals (LCP, INP, CLS) | three metrics for loading, responsiveness and stability | field data, 75th percentile | used by the ranking systems | 1, 6, 7 |
| Other Web Vitals, such as Time to First Byte (TTFB) and First Contentful Paint (FCP) | supporting metrics for narrowing down LCP problems | field and lab | not singled out by Google | 1, 13 |
| Lighthouse performance score | score from five weighted lab metrics, including TBT as a stand-in for INP | lab | according to Google, a tool for finding improvements | 6, 16, 17 |
| Page experience | umbrella term: Core Web Vitals, HTTPS, mobile display, no excessive ads, no intrusive interstitials, main content that’s easy to identify | depends on the aspect | no single signal; according to Google, aspects other than Core Web Vitals don’t directly help rankings | 6 |
| First Input Delay (FID) | former metric for the first input only | field data | replaced by INP on Mar 12, 2024 | 4, 33 |
What’s different about Core Web Vitals in Germany and the EU?
When viewed from Germany, websites pass the Core Web Vitals assessment more often than the global average, but almost a third still fail on mobile. At the same time, the field data misses a large share of visits in Germany: iPhones send no data to the Chrome UX Report, and on desktop, only Chrome does.
How websites perform in Germany: Of the websites that Chrome users in Germany visited often enough in September 2026, 69.2% passed all three metrics on mobile and 73.0% on desktop. Worldwide, the figures were 52.8% and 60.8%. CrUX infers the country from users’ IP addresses (Chrome for Developers on countries in CrUX (external site)). The figures therefore also include international websites that people visit from Germany. Our comparison of static sites and WordPress shows how they perform with real visitors.
| Device and region | Good on all three metrics |
|---|---|
| Mobile, Germany | 69.2% (406,207 of 586,975) |
| Mobile, worldwide | 52.8% (4,522,203 of 8,569,446) |
| Desktop, Germany | 73.0% (147,692 of 202,380) |
| Desktop, worldwide | 60.8% (3,280,280 of 5,391,031) |
Source: HTTP Archive, Core Web Vitals Technology Report (external site), · 586,975 websites on mobile, 202,380 on desktop
Who’s missing from the field data: In October 2026, 27.7% of mobile page views in Germany came from iPhones (iOS). On desktop, Chrome had a share of 42.2%, Edge 19.0%, Firefox 17.1% and Safari 11.9%. Of these browsers, only Chrome sends data to CrUX.
Source: StatCounter (external site), · monthly figure, October 2026, mobile operating systems
Source: StatCounter, · monthly figure, October 2026, desktop browsers
If many of your customers use iPhones, the field data shows only part of the picture. Your own measurement can now capture LCP and INP in Safari 26.2 or later and in Firefox 144 or later as well. CLS, however, is only available in Chromium browsers such as Chrome and Edge (MDN, version 8.1.8 (external site)).
Consent banners: According to web.dev, cookie consent banners are a very common cause of layout shifts, especially at the top of the page. On phones, a banner with a lot of text can even become the LCP element. If your website shows such a banner, display it as a sticky footer or a dialog over the content instead of pushing the content down (web.dev on cookie notices (external site)). This is a technical assessment. If you’re unsure whether your website needs a banner at all, ask a lawyer.
If you work with a German team: In German, Google keeps the English term Core Web Vitals, for example in the name of the Search Console report. Its German documentation calls page experience “Nutzerfreundlichkeit von Seiten” (Google Search Central, in German (external site)). Search Console in German shows the statuses as “Gut,” “Optimierung erforderlich” and “Langsam” for Good, Need improvement and Poor (Search Console Help, in German (external site)).
From our work: how we built datafalke.de for LCP, INP and CLS
We’ll publish this website’s regular measurements in our measurement log. There isn’t one yet. But you can already check what we built for each metric on the live pages. The table is current as of November 8, 2026. We checked it on our home page, our website development page, our methodology page and our guide to generative engine optimization (GEO).
| Metric | What we built | How to check it |
|---|---|---|
| LCP | The pages we checked load no image files or background images. Icons and pictograms are embedded in the HTML as SVG. The largest element is text. One font file is preloaded. Browsers may cache CSS and fonts for a year. | page source; Cache-Control header of a CSS file: max-age=31536000, immutable |
| INP | No page loads JavaScript. The Content-Security-Policy header blocks scripts (script-src ‘none’). A program on the server handles the contact form. | response headers of the page in the Network panel of DevTools |
| CLS | There are no embeds, ads or consent banners: the website sets no cookies and loads nothing from third parties. The fallback font, Arial, is matched to the metrics of our web font with size-adjust and other descriptors, so text shifts as little as possible when the web font loads. | @font-face rules in the page source; Network panel: requests to datafalke.de only |
In the lab, our test pipeline runs Lighthouse five times on a fixed set of pages and uses the median. It reports an error if any of these limits is exceeded. The check also fails if Lighthouse reports an image as the LCP element.
"numberOfRuns": 5
"largest-contentful-paint": [
"error",
{ "maxNumericValue": 2000, "aggregationMethod": "median" }
],
"cumulative-layout-shift": [
"error",
{ "maxNumericValue": 0.05, "aggregationMethod": "median" }
],
"total-blocking-time": ["error", { "maxNumericValue": 100, "aggregationMethod": "median" }],
"resource-summary:script:size": ["error", { "maxNumericValue": 0 }],
"resource-summary:third-party:count": ["error", { "maxNumericValue": 0 }],For real visits, we’ve set ourselves stricter targets than the thresholds Google gives for good values: at most 2.0 s for LCP, 150 ms for INP and 0.05 for CLS at the 75th percentile. Only field data will show whether we meet them. We’ll publish it in our measurement log as soon as the Chrome UX Report has values for datafalke.de. Our colophon describes the technology behind this website.
To apply this to your own website, use PageSpeed Insights or DevTools to find out which element is your LCP element. If it’s an image, check that it’s in the HTML itself and loads without delay. Then count the requests to other servers in the Network panel and decide for each one whether you need it. According to web.dev, third-party code generally weighs more heavily on performance than your own (web.dev on cookie notices (external site)).
See the measurement log